Blog · 2026-06-01

"connector: true" is a full OAuth stack in one flag

How one line in denkops.json gives your MCP server discovery, dynamic client registration, a consent screen, and an access list.

OAuth is the reason most MCP servers never become connectors. The protocol side of MCP is a pleasant afternoon; standing up an authorization server with discovery metadata, dynamic client registration, token issuance, and a consent screen is not. On DenkOps you skip all of it with one line in denkops.json:

{ "name": "my-tools", "slug": "my-tools", "runtime": "bun", "connector": true }

Deploy that, and your MCP server at https://my-tools.denkops.host/mcp is installable in any assistant that supports remote MCP servers with OAuth.

What actually happens when an assistant connects?

When someone adds your URL in Claude or ChatGPT, the client walks a standard flow, and DenkOps answers every step of it for you:

  1. The client fetches OAuth discovery metadata from your connector's domain and learns where to register and authorize.
  2. It registers itself via dynamic client registration. No manual "create an OAuth app" step, no client secrets to email around.
  3. The user lands on a hosted login and consent screen, signs in, and approves access.
  4. The client gets a token and starts calling your tools over /mcp.

Your application code sees none of this. You write tool handlers; the platform proves who is calling.

Who is allowed to connect?

Auth without access control is theatre, so every connector has an owner-controlled policy. In the project's Access tab you choose:

  • Public: anyone who completes the OAuth flow can use the connector.
  • Allowed emails: only listed people get past the consent screen. Everyone else is refused at login, before a single tool call happens.

Grants and changes show up in your workspace audit log, so "who can reach this thing" has an answer you can actually produce.

Why not just use an API key?

API keys work for machine-to-machine calls, and DenkOps apps keep auth by default with a per-app key for exactly that. But keys are wrong for connectors: you would be pasting a shared secret into every assistant, with no per-user identity, no consent step, and no way to revoke one person. OAuth gives each user their own grant, and gives you a revoke button.

Try it

The MCP starter is a complete connector in under thirty lines. Add "connector": true, deploy, paste the URL into Claude or ChatGPT, and watch the consent screen appear, an OAuth stack you never wrote.

FAQ

Do I need to register an OAuth client for Claude or ChatGPT manually?

No. DenkOps connectors support dynamic client registration, so MCP clients register themselves during setup. There is no developer console step and no client secret to manage.

Can I restrict my connector to specific people?

Yes. Each connector project has an access policy: public, or an allowed-email list managed in the dashboard's Access tab. Refusals happen at the login step, before any tool call reaches your code.

Does my app code have to validate OAuth tokens?

No. The platform enforces the OAuth flow in front of your app, and your tool handlers only run for authorized sessions. You write business logic, not token plumbing.

Ship it yourself: bunx denkops deploy or say "deploy on DenkOps" from your coding agent.

Start on DenkOps →

← Secrets your agent can use but never see · Add your MCP connector to Claude →