Una solicitud MCP está limitada por frecuencia

Inspecciona tanto el código de error como el estado HTTP. El HTTP 429 puede significar una cuota por minuto o un límite temporal de admisión:

Los errores de cuota y de cola pueden aparecer dentro de la respuesta de una herramienta. Comprueba isError y los datos de error devueltos incluso cuando el estado HTTP sea 200. Una solicitud de estado rechazada no cancela una tarea ya aceptada.

Espera antes de reintentar

Detén los bucles de reintentos inmediatos y sigue el retraso indicado para el rechazo concreto. El límite de lectura configurado es de 60 por minuto por defecto para las solicitudes de protocolo y de catálogo. El envío de tareas tiene un presupuesto independiente del mayor entre 120 o el doble de ese ajuste; pom_get_task tiene el mayor entre 600 o diez veces ese ajuste. Los intentos de autenticación MCP tienen un límite temprano por IP del mayor entre 1.200 o veinte veces el ajuste. El registro OAuth, los tokens y la revocación conservan cada uno su límite independiente de 5 por minuto por IP.

El envío y el estado de la tarea responden directamente sin esperar al cron. El sondeo no consume el presupuesto de envío ni el de catálogo. Los envíos de lectura y de escritura comparten el mismo presupuesto de envío, y la ejecución en cron no vuelve a cobrar la tarea ya aceptada.

Cuando una tarea sigue esperando

Un recibo de tarea no es un error de límite de frecuencia. Sigue su poll_after_seconds mientras terminal sea falso. phase: waiting_for_dispatch significa que la tarea está esperando a ser programada; waiting_for_cron significa que el ejecutor de cron de su sitio aún no la ha iniciado; executing significa que el trabajo ha comenzado. created_at y started_at ayudan a distinguir el tiempo de espera del tiempo de ejecución.

Cada sitio puede tener una tarea lista para cron, y toda la instalación ejecuta una operación pesada a la vez. Que otros eventos de cron se ejecuten correctamente no demuestra que la tarea del destino seleccionado haya comenzado. Si la espera persiste, pide al administrador que compruebe el ejecutor de cron de ese destino. Conserva el ID de la tarea; enviar la operación de nuevo crea más trabajo en lugar de comprobar la original.

Detén el sondeo automático cuando terminal sea verdadero. Lee result para completed o failed, incluidos los valores anidados de red isError. Para uncertain, inspecciona el destino antes de otra escritura. Una tarea expired no comenzó; un recibo ausente o caducado por sí solo no permite establecer si su operación se ejecutó. Nunca repitas automáticamente una escritura incierta.

Reduce las llamadas innecesarias

• Almacena en caché tools/list, resources/list y prompts/list para la conexión actual.
• Lee solo el recurso necesario para la tarea.
• Usa paginación acotada.
• Evita sondear objetos que no cambian.
• Para tareas en segundo plano, sigue poll_after_seconds y sigue sondeando la tarea existente hasta que sea terminal, en lugar de volver a enviarla.
• Serializa las escrituras y verifica cada resultado.

Si la respuesta de una escritura se perdió antes de que apareciera el error de límite de frecuencia, lee el estado actual antes de enviarla de nuevo. Una entrada, un cupón, un adjunto de medios o un elemento de menú duplicados son más difíciles de reparar que esperar.

Los administradores pueden ajustar la frecuencia principal de MCP, que también escala los presupuestos mayores de envío y de estado. Esto no cambia los presupuestos fijos de OAuth, la capacidad de la cola ni el único trabajador pesado. Los límites de frecuencia no están relacionados con los créditos de IA.

Guías relacionadas: contrato de límite de frecuencia, auditoría de solo lectura y confirmación de escritura.