Saltar al contenido principal

Límite de Peticiones

El servidor MCP comparte los mismos límites de la API REST, contados 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, ya 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 el endpoint que refleja: la petición se cuenta una vez en el bucket del propio MCP y, cuando es un tools/call, otra vez por el bucket del endpoint al que despacha. 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.

Los intentos con token inválido se estrangulan por IP, no por token, igual que en el edge REST: un token que no se verifica no puede tener bucket propio. Una petición sin ningún token — el primer paso de todo cliente, antes del OAuth — no cuenta como intento.

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
Content-Type: application/json

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

Espera los segundos de Retry-After antes de la próxima petición. Los límites por cuenta y por tipo de petición están en la página de límites de la API — son los mismos.

Gastando menos​

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

  • Filtra antes de paginar. dashboards_portal_users_list { status: "suspended" } cuesta una petición; recorrer todos los usuarios del portal para filtrar en el modelo cuesta decenas.
  • Pide solo las columnas que importan. fields: ["email", "status", "last_login_at"] no reduce el número de peticiones, pero reduce mucho el contexto gastado — ve Listado, orden y campos.