Límite de solicitudes
El servidor MCP comparte los mismos buckets que la API REST, aplicados por persona dentro de la organización (los claims sub y org del JWT, juntos) — nunca por token, así que un token nuevo no reinicia el presupuesto. Una llamada a una tool nunca es más barata que el endpoint al que despacha: la solicitud se cuenta una vez, en la capa MCP, y el handler despachado no la vuelve a contar.
| Plan | Lecturas/min | Escrituras/min | Burst |
|---|---|---|---|
| Estándar | 600 | 60 | 100 |
| Premium | 3000 | 300 | 500 |
Cada respuesta lleva:
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 587
X-RateLimit-Reset: 1715961240
| Header | Significado |
|---|---|
X-RateLimit-Limit | Solicitudes permitidas en la ventana actual. |
X-RateLimit-Remaining | Solicitudes restantes en la ventana actual. |
X-RateLimit-Reset | Timestamp Unix en que la ventana se reinicia. |
Al excederlo, el servidor responde HTTP 429 con rate_limited y un header Retry-After en segundos — el mensaje JSON-RPC ni siquiera se procesa.
Los intentos con un token inválido se limitan por IP del cliente, no por token — un token que no se verifica no puede tener un bucket propio — y se rechazan con el mismo 429 al superar el límite. Una solicitud sin ningún token, el primer paso de todo cliente antes del flujo OAuth, no cuenta como intento.
Un agente que lista en bucle quema el mismo presupuesto que tu backend. Pide el limit más pequeño que sirva y sigue meta.next_cursor solo mientras necesites más — ver Paginación.