The partner MCP server

Why two servers

The public MCP server is deliberately open — it publishes figures an agent may need with no credential. But an agent acting on behalf of a partner — reading applications, checking a decision — needs authentication and scope, so those capabilities live on a separate token-gated server at /partner/v1/mcp. The protocol is identical; the difference is the Authorization: Bearer header and the OAuth-protected-resource metadata.

Discovery and auth

The partner MCP server advertises its auth requirements through the standard /.well-known/oauth-protected-resource document, which points MCP clients at the token endpoint and the authorization-server metadata. An MCP client that understands OAuth can therefore configure itself: fetch the protected-resource doc, obtain a token with the right scopes, and call POST /partner/v1/mcp.

When to use which

Use the public server for anything a prospective customer or comparison agent needs — products, quotes, eligibility. Use the partner server when the agent is authenticated as a partner and needs to touch partner resources. Many production assistants use both: public tools for discovery, partner tools once the user is in a partner-authenticated context.

Frequently asked questions

Is the partner MCP protocol different from the public one?

No. Both speak MCP Streamable HTTP over JSON-RPC 2.0 with the same method set. The only difference is that the partner server requires an OAuth bearer token and exposes authenticated tools.

How does an MCP client discover the partner server's auth?

Through the /.well-known/oauth-protected-resource document, which advertises the token endpoint and authorization-server metadata. OAuth-aware MCP clients read it and configure the bearer flow automatically.