Skip to main content
The MCP server and the Arbol API are separate OAuth resources. A token issued for one audience must not be accepted by the other. The MCP OAuth resource identifier and token audience are exactly:
OAuth clients must send that same value in the resource parameter. https://mcp.getarbol.com/ identifies a different resource and is not interchangeable with the MCP endpoint.

​
Request flow

  1. The client discovers the MCP protected resource and authorization server.
  2. Dynamic client registration creates an approved OAuth client.
  3. A person authorizes the MCP client in the context of their organization.
  4. The client sends the resulting MCP-audience bearer token to the MCP endpoint.
  5. MCP verifies issuer, audience, signature, expiry, organization context, and the MCP access scope.
  6. MCP exchanges that verified token for an API-audience token on the person’s behalf.
  7. MCP calls the generated REST operation with the exchanged token.
  8. The API independently verifies organization and operation permissions.
Every Arbol organization can authorize MCP. The connection grants no additional API authority: each call remains limited to the person’s verified organization membership, roles, scopes, and the permissions declared for that operation.

​
Required metadata

The deployment must expose and verify:
  • MCP protected-resource metadata under https://mcp.getarbol.com/.well-known/oauth-protected-resource;
  • authorization-server metadata from the configured Auth0 custom domain;
  • a dynamic-client-registration endpoint; and
  • the downstream API protected-resource metadata at https://api.getarbol.com/.well-known/oauth-protected-resource.

​
Security invariants

  • MCP never forwards the incoming MCP token directly to the API.
  • The incoming token’s audience must equal https://mcp.getarbol.com/mcp.
  • The exchanged token’s audience is the API, and its scopes are bounded by the delegated user authority.
  • Organization identity comes from verified token claims, never tool arguments.
  • Tool execution still receives 401 or 403 from the API when delegated authority is invalid or insufficient.
  • Token exchange credentials remain server-side and are never returned through MCP content.
This flow is a deployment prerequisite, not a statement that dynamic registration and token exchange are already enabled in production.
See Auth0’s MCP on-behalf-of guide and on-behalf-of token exchange documentation for the identity-provider requirements.