MCP rate limits

ProductAtlas applies separate fixed-window policies to anonymous public calls, authenticated Management MCP calls, and dynamic client registration. These are committed application defaults, not proof of the effective hosted edge limits.

Current application defaults

Surface	Default	Partition	Queue
Anonymous public /mcp	60 requests per 60 seconds	Directly observed remote IP address	None
Authenticated /mcp/manage	60 requests per minute	Validated OAuth client_id plus subject	None
Dynamic registration /.well-known/oauth-register	10 registrations per 60 seconds	Directly observed remote IP address	None

The public and dynamic-registration values can be changed by deployment configuration. Production edge controls such as Cloudflare can apply additional or stricter limits. The Management MCP request policy is committed at 60 per minute; it still does not prove the hosted edge's effective policy.

The IP-partitioned policies intentionally do not trust forwarded IP headers until the production proxy chain is explicitly configured. This prevents callers from choosing their own partition through a spoofed header. Management calls instead use validated token claims so two authorized users or clients do not share a partition merely because they use one network address.

Limited response

When the anonymous public application limit is exceeded, the HTTP response uses status 429 Too Many Requests, includes Retry-After when the limiter supplies it, and returns:

{
  "code": "rate_limited",
  "message": "The anonymous MCP request limit was exceeded. Retry later."
}

Management and registration requests also use HTTP 429 when their policy is exhausted. Clients must treat the status and Retry-After as authoritative; do not assume that every limiter returns the public endpoint's JSON body.

Client behavior

1. Honor Retry-After; do not retry immediately in a tight loop.
2. If the header is absent, wait until a later fixed window and use bounded exponential backoff with jitter.
3. Avoid repeating identical searches. Retain compact results and the exact resolved release identity within the current task when appropriate.
4. Retrieve summary first and request selected sections rather than repeatedly fetching complete detail.
5. Follow nextCursor sequentially and stop when it is null.

Search pages default to 20 results and clamp the requested size to a maximum of 50. Larger limit values do not bypass response bounds.