Skip to main content
/mcp accepts the same bearers as the REST API, plus an OAuth token where the deployment brokers one. Anonymous calls count against the MCP client’s IP. Each client gets its own anonymous bucket. Token handling on /mcp:
  • Missing or unknown token: 401 with WWW-Authenticate: Bearer. Where OAuth is enabled, the challenge also carries resource_metadata, which is how a client starts the flow.
  • Key lookup fails: 503 with no challenge. Retry. The key is not rejected.
  • Self-hosted, no identity provider: /mcp runs without a token check.

​
OAuth

Where the deployment enables it, /mcp is an OAuth 2.0 authorization server. Login goes through Clerk. Bearer tokens still work. A connector directory uses this mode, and the client registers itself instead of receiving a token out of band. The issuer is https://gateway.vlm.run/mcp, with /mcp/authorize, /mcp/token, and /mcp/register under it. It implements Dynamic Client Registration (RFC 7591) and Client ID Metadata Documents, and it requires PKCE (S256). A client registers at connect time.
  • Scopes: openid, email, and profile.
  • Refresh token: Also request offline_access. Without it, the client sends the user back to sign in when the access token expires.
  • Persistence: Registrations and sign-ins are shared by every replica and survive a restart, so a client does not register again after a deploy.
Discovery is at the origin’s root, per RFC 8414 and RFC 9728, not under /mcp: An unauthenticated call returns a transport-level 401 with WWW-Authenticate: Bearer resource_metadata="…". That challenge is what makes a client show a connect prompt. The resource URL has to match the client URL character for character: https://gateway.vlm.run/mcp.