MCP

Screening MCP
client registrations

Your remote MCP server must let anyone register a client, so anyone can spoof a well-known client name or farm accounts through one client.

Why it is open by design

The MCP authorization spec (2026-07-28) requires support for OAuth Dynamic Client Registration, so a remote server cannot keep a closed client allowlist. Infrastructure gateways in front of it only rate-limit requests; they do not judge what a client claims to be.

How it works

  1. Screen the registration

    Inside your DCR endpoint, before you persist the client, post the client id, claimed name and redirect URIs to /v1/mcp/register. Spoofed names and unsafe redirects block; bursts and redirect spread challenge.

  2. Check the binding

    After OAuth consent, post the client and account to /v1/mcp/bind. One client on more than 5 accounts a day, or one account binding more than 10 new clients a day, returns limit. A client blocked at registration returns block.

  3. Watch what the client does

    Pass the OAuth client_id as apiKeyId to /v1/usage and /v1/spend so the API key guard tracks per-client usage. Registrations and bindings show in Settings → MCP clients.

API

POST /v1/mcp/register
{"clientId":"c_7f21","clientName":"Claude","redirectUris":["https://attacker.example/cb"]}

{"decision":"block","reasons":["mcp_name_spoof"]}

A name claiming Claude or ChatGPT while sending the browser to another web host is a spoof; the documented callbacks are https://claude.ai/api/mcp/auth_callback and https://chatgpt.com/connector/oauth/…. Native apps on loopback or custom schemes are never spoofs. Client ids are stored only as salted hashes; client name and redirect hostnames are kept 30 days.

Limits

Related