Límite de solicitudes
El servidor MCP aplica dos buckets, ambos contados por persona en la organización — el sub y el org del token, nunca el token en sí:
| Bucket | Qué cuenta | Límite |
|---|---|---|
| El del propio MCP | Todo mensaje: initialize, tools/list, cada tools/call… | 600 por minuto |
| El del endpoint despachado | Cada tools/call gasta además el bucket del endpoint de la API al que despacha, con la misma clave | 600 por minuto |
Una llamada de tool nunca es más barata que el endpoint que refleja. Es deliberado: un agente que recorre listados en bucle no debería poder esquivar el límite que ese mismo recorrido pagaría por REST.
Cambiar de token no reinicia el presupuesto: un token nuevo — de una nueva autorización OAuth o un nuevo token personal — de la misma persona en la misma organización cae en el mismo bucket. La misma persona en otra organización tiene presupuesto propio.
Los intentos con token rechazado se estrangulan por IP, no por token: 60 por minuto; después, 429. Un token que no se verifica no puede tener bucket propio.
Cuando se alcanza el límite
El servidor responde 429 — el mensaje JSON-RPC ni siquiera se procesa:
HTTP/1.1 429 Too Many Requests
Retry-After: 37
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1753272060
Content-Type: application/json
{ "error": { "code": "RATE_LIMITED", "message": "Rate limit exceeded" } }
| Cabecera | Significado |
|---|---|
Retry-After | Segundos hasta poder reintentar |
X-RateLimit-Limit | Límite de la ventana |
X-RateLimit-Remaining | Solicitudes restantes en la ventana |
X-RateLimit-Reset | Unix time (segundos) en que la ventana se reinicia |
Espera los segundos de Retry-After antes de la próxima solicitud. Los límites de la API REST están en la página de rate limiting de la API.
:::tip Gastando menos
Filtra antes de paginar y usa per_page hasta 100: dunning_charges_list con status: "overdue" y due_date_to cuesta una solicitud; recorrer todos los cobros para filtrar en el modelo cuesta decenas. Ve Listado y paginación.
:::