Skip to main content

MCP Authentication

Vocci MCP uses OAuth. Users authorize a compatible client through a browser sign-in flow instead of copying credentials into configuration files.

note

Authorization can expire or be revoked. If a client receives 401 or 403, reconnect the user through OAuth instead of asking them to paste tokens.

OAuth Flow

OAuth-capable clients should:

  1. Connect to https://mcp.vocci.ai/mcp.
  2. Discover protected-resource metadata from the Vocci MCP server.
  3. Discover authorization-server metadata from the issuer the protected-resource metadata advertises.
  4. Send the user through authorization and consent.
  5. Store the resulting authorization in the client's secure storage.
  6. Call MCP tools on behalf of the authorized user.
  7. Refresh or reconnect when authorization expires or access is revoked.

Hosted clients should not ask users to paste credentials manually. If a hosted client cannot complete OAuth, reconnect with a tested setup path.

What The Client Sends

After OAuth completes, the client handles request authorization automatically. Users should not copy browser session values, OAuth codes, or authorization headers into configuration.

Access Model

Vocci MCP authorization is user-scoped and read-only.

AreaExpected behavior
User dataOnly data the authorized account can access.
Tool permissionsRead-only tools only.
Browser sessionsNot accepted as MCP credentials.
Revoked accessRejected on the next request.
Missing permissionsTools should fail without returning private system details.
Audio exportAvailable on an OAuth connection; returns short-lived download URLs, never inlined bytes.

Discovery Routes

The server advertises standard metadata for OAuth-capable clients. The host comes from the Vocci MCP server URL:

https://mcp.vocci.ai/.well-known/oauth-protected-resource
https://mcp.vocci.ai/.well-known/oauth-protected-resource/mcp
https://mcp.vocci.ai/.well-known/oauth-authorization-server
https://mcp.vocci.ai/.well-known/openid-configuration

The protected-resource metadata names Clerk as the authorization server, so clients discover Clerk's own metadata and complete the OAuth grant there:

authorization_servers: ["https://clerk.vocci.ai"]

Clerk advertises Dynamic Client Registration:

registration_endpoint: https://clerk.vocci.ai/oauth/register

OAuth-capable clients should read that value from the authorization-server metadata the protected-resource document points at, instead of hard-coding a host or asking for a pasted OAuth client ID. If the field is absent in a non-production environment, Dynamic Client Registration is not advertised for that environment.

The scopes this resource requires stay in the protected-resource document's scopes_supported and in the WWW-Authenticate challenge — read them there rather than from the authorization server, which advertises everything Clerk supports.

The MCP server also still serves oauth-authorization-server and openid-configuration documents naming itself as issuer. Those are legacy, kept only for clients that discovered them before this changed, and will be withdrawn. Do not build against them.

Some clients discover these routes automatically after receiving the MCP server URL:

/.well-known/oauth-protected-resource
/.well-known/oauth-protected-resource/mcp
/.well-known/oauth-authorization-server
/.well-known/openid-configuration