RATE LIMITS

THE MODEL

Each MCP listing carries two per-consumer caps, set by the publisher:

• Per minute — how many calls a single consumer can make to this listing in any 60-second window. Default 30.
• Per day — rolling 24-hour ceiling. Default 1,000.

Counters are keyed by (mcp_id, consumer_id) — one consumer's traffic on one listing has no effect on either's traffic on another listing. Both counters live in Redis with sliding windows.

WHEN YOU HIT THE LIMIT

Either ceiling tripping returns:

HTTP/1.1 429 Too Many Requests
Retry-After: 7
X-Mcpmeter-Request-Id: …

{
  "jsonrpc": "2.0",
  "error": {
    "code":    -32429,
    "message": "Rate limit exceeded",
    "data": {
      "reason":      "rate_limited",
      "limit":       60,
      "window":      "per_minute",
      "retry_after": 7
    }
  }
}

BACKOFF PATTERN

Honour Retry-After. The proxy is honest about how long until the counter has space:

while attempt < max_attempts:
    res = call_mcp(...)
    if res.status == 429:
        wait = int(res.headers["Retry-After"])
        sleep(wait + jitter(0..1))
        attempt += 1
        continue
    return res

Add a small random jitter so multiple agents don't synchronise their retries.

DEFAULTS

Most listings ship with platform defaults:

Publishers can tune both ceilings per listing — see publishing.

SPENDING CAPS VS RATE LIMITS

Don't confuse the two. They protect different things and trigger different status codes:

ABUSE PROTECTION

On top of per-listing limits, the proxy enforces a global per-key burst limit (200 req/s sustained, 500 req/s burst) to protect the proxy itself. You will not hit it under normal agent use; misconfigured loops sometimes do.