Keystone Developers
Open Keystone
Guides

MCP

Connecting an MCP client

The Keystone MCP server speaks standard Streamable HTTP and OAuth 2.1. Anything that can connect to an MCP server can connect to it.

Reviewed Oct 10, 2026

The server is not built for one assistant. It implements the Model Context Protocol over Streamable HTTP, authenticates with OAuth 2.1 the way the protocol specifies, and publishes the discovery documents a client needs to find the authorization server on its own. Claude, Cursor, ChatGPT, the MCP Inspector, and anything you write against an MCP SDK connect the same way. The Keystone Claude Connector page covers the one client with a packaged setup.

What a client needs

Server URLhttps://mcp.keystone.app/mcp
TransportStreamable HTTP (the 2026-07-28 protocol; 2025-era clients are served too)
AuthenticationOAuth 2.1 with PKCE; bearer token in the Authorization header
Scopeedits
Discovery/.well-known/oauth-protected-resource (RFC 9728) on the server's host; the authorization server's metadata is mirrored at /.well-known/oauth-authorization-server for older clients

The sign-in

  1. The client calls the server without a token and receives 401 with a WWW-Authenticate header pointing at the protected-resource metadata.
  2. From that document it learns the authorization server (the Keystone Auth service) and the edits scope, and starts an authorization-code flow with PKCE.
  3. The user signs in to Keystone and approves the request. The Auth service issues an MCP access token bound to this server as its audience.
  4. The client sends the token on every call. The server verifies the signature, issuer, audience, and token type, then forwards the call to the Edits API with that token and its own service key.

Who may connect

Two things are registered on the Keystone side, not by the client:

  • The redirect URI. The Auth service only redirects to URIs it knows. Claude's and Cursor's are registered; for another client, or your own, send its callback URI to developer support.
  • The user. MCP access is granted per Keystone user. A sign-in from a user who has not been granted it fails at the Auth service with a reason.

Everything after sign-in is governed by SOR, exactly as in the console: who may edit which business, the claim, the launch state, and compare-and-swap on every field.

Cards

The server ships an MCP App (the card the user reviews changes on). A client that renders MCP Apps shows it; a client that does not still gets every tool's text result and structuredContent, and the four card-only tools stay out of the model's reach either way. Cards and card tokens explains why.