/mcp endpoint lets a Claude client call tools on the orchestrator over the Model Context Protocol (MCP). It serves:
- Diagnostic tools, answered by the orchestrator itself — its health, its projects, its running jobs, and why an issue is or isn’t being dispatched
- Knowledge-graph tools, answered by the knowledge graph bundled into the orchestrator
The environment variables this page names are described together under Admin sign-in and MCP server in the variable reference.
Signing in
The endpoint uses OAuth, with no pre-shared secret. A client that reaches/mcp without a token is pointed to the orchestrator’s resource-metadata document, finds the orchestrator’s authorization server there, registers itself, and sends the person to their browser to sign in.
The orchestrator is that authorization server, and it hands the sign-in itself to your admin sign-in providers. Every sign-in therefore returns through two callbacks — one from the provider to the orchestrator, then one from the orchestrator to the client. Each has to be registered, and which ones you need depends on the providers and clients you use:
Each provider’s MCP callback is registered alongside its admin sign-in one, not instead of it.
Any other web-based client works the same way as claude.ai: its callback must use HTTPS, and its origin must be listed. To connect claude.ai itself, follow Add the orchestrator as a project connector.
Signing in needs all of these on the orchestrator:
- a knowledge graph — required even though the diagnostic tools never use it
- at least one sign-in provider — the same providers admin sign-in uses
OAUTH_REDIRECT_BASE_URL— the orchestrator’s public base URL
access_denied in their client, and the orchestrator’s log records the reason.
Staying signed in
Access tokens last an hour by default, set in seconds byMCP_ACCESS_TOKEN_TTL, and a client refreshes them without sending the person back to sign in.
Each refresh also issues a new refresh token that lasts thirty days from that moment. A client in regular use therefore stays signed in indefinitely, and a person signs in again only after thirty days without using it.
Access can also end sooner in the following ways:
- When the person is removed from the allowlist. It takes effect at their next refresh — within one access-token lifetime.
- When a refresh token is presented twice. That is treated as theft: the whole chain the token belongs to is revoked, and the person must sign in again.