How does my own MCP server trust CMD+K?

One question: who does your MCP trust?

Every way of connecting an MCP to your assistant is really an answer to a single question — who is allowed to make calls, and how does your server know it's really them. There are four answers. Two are live today for servers you run, one is for APIs you'd rather we host, and one is on the standards roadmap.

• Mode 1 · CMD+K hosts your MCP. You have an API, not a server. Zero-click identity, nothing to build. Available today.
• Mode 2 · Per-user OAuth (the classic flow). Your users connect their own accounts with one click. Works with any spec-compliant MCP — no code changes. Available today.
• Mode 3 · Your MCP verifies the widget JWT (recommended, zero-click). Your server trusts a token you already sign. One-page change, no Connect click ever. Available today.
• Mode 4 · jwt-bearer / Enterprise-Managed Auth. Fully standards-based zero-click token exchange. Roadmap — ask us.

The classic flow — per-user OAuth

Your MCP stays exactly as it is. The first time a visitor asks for something that needs their account, the assistant shows a one-time Connect card in the chat. The click opens your OAuth screen — they're usually already signed in, so it's a single Allow — the conversation resumes automatically, and future sessions need no clicks. Tokens are stored per user, encrypted, with automatic refresh. This is exactly how Claude.ai and ChatGPT connect to servers they don't own.

• Requirement: your MCP publishes OAuth metadata (RFC 9728 / 8414). With dynamic client registration (RFC 7591) setup is fully automatic; without it, paste a client ID once in the connector's identity settings.
• Friction floor: mark the Command+K OAuth client as a trusted first-party app in your authorization server and the consent screen is skipped — the popup opens and closes in about a second. (Browsers require one user gesture to open a popup, so the floor is one click, ever.)
• Boundary: anonymous visitors can't hold a personal connection — public widgets keep working with knowledge and read-only tools.
• In the dashboard: add the server from Tool library → Add tool, choose My users, and leave the zero-click checkbox off — the connector is saved as an End-user tool. Marketplace entries arrive with the MCP URL, OAuth endpoints and scopes pre-filled, but not with an OAuth app: there is no shared platform OAuth client today, so you paste your own client ID and secret, or add the server by URL and let dynamic client registration set it up where the provider supports it. A custom server must publish its own OAuth flow — or verify the widget JWT (Mode 3). The per-provider detail is in End-user tools: OAuth model.

Pick this when you want the fastest start with zero development, or when you can't change the server. It's the most compatible option and the right default.

The recommended flow — your MCP verifies the widget JWT

The widget JWT is your token: you sign it so we can greet your user (see End-user authentication (JWT)). Your MCP trusting your own signature is architecturally sound and gives true zero-click identity — no Connect card, no popup. There is no separate "JWT forwarding" switch: it's a connection mode you pick when adding the tool.

How to turn it on in the dashboard

1. Tool library → Add tool, enter your MCP server URL, and under Who is this tool for? choose My users.
2. Open Prefer zero clicks for your visitors? and tick "Zero-click — my server accepts the widget JWT I already sign."
3. Save. The connector is stored in Your backend mode (end-user identity required, token format passthrough) and shows as Your backend in the Tool library. From then on every tool call carries the visitor's widget JWT — the exact token from data-cmdk-token — as the bearer token. Anonymous visitors have no token, so those calls are refused before they reach your server.

The same My users choice on a Command+K-hosted MCP (Mode 1) uses a short-lived token we mint and verify ourselves instead — that's the audience + signing secret shown on the connector's backend-identity panel. For a server you run, only the passthrough form applies: we never mint a token your server would have to trust.

What your server must do

On each request, verify the bearer token and reject anything that fails with a 401:

1. Verify the signature — HS256 with your shared secret, or RS256 against your JWKS.
2. Check exp — reject expired tokens.
3. Check the aud — it must be the audience you put in the widget JWT you sign; use a dedicated value for this server, not a generic one.
4. Map sub to your user and scope every query to them.
5. Apply the scopes claim — grant only what the token allows.

Security ladder

• HS256 (shared secret) — fine for getting started. Trade-off: the secret also lives at CMD+K, so in principle CMD+K could mint a token for any sub. Mitigate with a dedicated aud, short TTLs, and narrow scopes.
• RS256 + your JWKS (recommended for production) — you sign with a private key only you hold and publish the public key at a JWKS URL. Both CMD+K and your MCP verify, and nobody but you can mint identity.

Pick this when you want the Connect click gone and can ship a small change — usually about an afternoon of work to verify a token you already produce.

On the roadmap — jwt-bearer / EMA

The MCP ecosystem standardized zero-click trusted identity in 2026 (token exchange, RFC 8693 + jwt-bearer, RFC 7523). When your authorization server supports the grant, we'll exchange the signed identity for one of your access tokens with no consent redirect — fully standards-based, no first-party-JWT arrangement needed. Customer demand schedules the client-side work, so tell us if you need it.

Which one should I pick?

• I have an API, not a server → Mode 1: let us host it. See Convert your API into an MCP.
• I run my own MCP and want the fastest start → Mode 2: per-user OAuth.
• I run my own MCP and want zero clicks → Mode 3: verify the widget JWT.
• I need the pure-standards path → Mode 4: ask us.