Límite de Peticiones

El servidor MCP acepta 600 solicitudes por minuto por persona y organización — el sub y el org del token, no el token en sí.

Cambiar de token no reinicia el presupuesto: un token nuevo, sea 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.

Una llamada de tool nunca es más barata que la ruta que refleja: la solicitud se cuenta una vez en el bucket del propio MCP y, cuando es un tools/call, otra vez en el bucket de la API v1 (600 por minuto), con la misma clave de persona y organización. Las rutas con límite propio también lo aplican: kadu_executions_search tiene 30 más por minuto, como GET /v1/executions/search. Es deliberado — un agente que recorre listados en bucle no debe poder esquivar el límite que el mismo recorrido pagaría por la API.

Los intentos con token rechazado se limitan por IP, no por token: un token que no se verifica no puede tener bucket propio. Una solicitud sin ningún token — el primer paso de todo cliente, antes del OAuth — no cuenta como intento.

Cuando se alcanza el límite

Agotado el bucket del MCP, el servidor responde 429 — el mensaje JSON-RPC no llega a procesarse:

HTTP/1.1 429 Too Many Requests
Retry-After: 37
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1793280037
Cache-Control: no-store
Content-Type: application/json

{ "error": { "code": "TOO_MANY_REQUESTS", "message": "Rate limit exceeded." } }

Espera los segundos de Retry-After antes de la siguiente solicitud. X-RateLimit-Limit y X-RateLimit-Remaining dicen el tamaño del bucket y lo que queda; X-RateLimit-Reset es cuándo se renueva, en segundos desde la época Unix.

Agotado el bucket de la ruta, la solicitud HTTP es 200 y el resultado de la tool vuelve isError con el error de la API, RATE_LIMITED — mira Errores. Espera unos segundos antes de llamar de nuevo. Los límites de la API están en Límites de solicitudes.

Gastar menos

Un agente consume presupuesto como tu backend, y además paga contexto por cada fila que trae. Tres hábitos resuelven casi todo:

• Filtra antes de paginar. kadu_executions_list { status: "failed", started_at_gte: "2026-10-01" } cuesta una solicitud; recorrer todas las ejecuciones para filtrar en el modelo cuesta decenas.
• Lee solo lo nuevo. Para seguir una ejecución en curso, pasa after_sequence a kadu_executions_events_list y after_id a kadu_executions_logs_list, en lugar de releer todo en cada vuelta.
• No consultes en bucle. Una aprobación por enlace se consulta cuando la persona dice que decidió, no cada pocos segundos.