Limitación de velocidad de MCP

POM AI cuenta las solicitudes en depósitos por minuto asociados al cliente autenticado o, cuando es necesario, a una clave basada en IP con hash.

Límites

• Las solicitudes de protocolo y de catálogo usan la velocidad de MCP configurada por el administrador, con un valor predeterminado de 60 por minuto. El modo nativo cuenta las solicitudes de protocolo autenticadas; el modo estándar la aplica a los listados de catálogo y a las solicitudes de disponibilidad.
• Los envíos de tareas usan un depósito task-submit independiente: max(120, configured_rate × 2) por minuto. Cubre las llamadas a herramientas distintas de pom_get_task, las lecturas de recursos y las solicitudes de prompts.
• pom_get_task usa un depósito task-status independiente: max(600, configured_rate × 10) por minuto.
• Los intentos de autenticación de MCP tienen un presupuesto temprano por IP de max(1200, configured_rate × 20) por minuto.
• Las solicitudes de registro, token y revocación de OAuth usan cada una un límite fijo independiente de 5 por minuto por IP.

El ajuste se limita a un mínimo de uno. Los contadores se alinean con el minuto UTC actual y se conservan un poco más de un minuto para cubrir el límite del depósito.

Ambos transportes usan los mismos presupuestos de envío y de estado. Un envío de escritura, incluida una vista previa, consume una ranura de envío. No consume además una cuota de escritura independiente ni la cuota de catálogo. A una tarea aceptada no se le vuelve a cobrar cuando cron la ejecuta, incluso cuando la ejecución se delega a otro sitio. Las comprobaciones de permisos no añaden cargos.

Los fallos de velocidad de MCP estándar conservan JSON-RPC -32029 e incluyen data.code y data.status. Los fallos de cuota también incluyen retry_after, bucket, operation y limit en data. Un fallo del limitador se distingue por data.code: pom_ai_mcp_rate_unavailable y data.status: 503; no afirma que la cuota se haya agotado. Los fallos anteriores al despacho JSON-RPC usan el estado HTTP correspondiente.

Los fallos de límite de solicitudes nativas usan HTTP 429 con Retry-After. Los fallos de cuota de OAuth usan HTTP 429 con rate_limited y Retry-After. El retraso es el tiempo restante hasta la siguiente ventana de minuto, con un mínimo de un segundo. Un fallo del limitador usa HTTP 503; OAuth informa temporarily_unavailable. Consulta el contrato de errores.

Trabajo concurrente y tamaño de las solicitudes

Enviar una tarea y leerla con pom_get_task son operaciones HTTP síncronas. Devuelven sin esperar a cron ni a un trabajador pesado. Las solicitudes MCP públicas no reservan una ranura de solicitud para toda la instalación; la admisión en la cola en sí sigue siendo atómica y acotada. La autenticación, las cuotas y la validación de entrada se aplican a cada solicitud.

Las operaciones MCP pesadas comparten una ranura de ejecución en segundo plano para toda la instalación. Las herramientas de IA del administrador se ejecutan directamente en las solicitudes de su navegador y no usan esta ranura. El trabajo espera en el cron de WordPress en lugar de mantener abierta la solicitud HTTP de origen. El descubrimiento concurrente o el sondeo de estado no aumenta la concurrencia de operaciones pesadas ni la capacidad de la cola.

La cola acepta como máximo 64 tareas en cola o en ejecución y conserva como máximo 512 recibos de tarea. Cuando la admisión está llena u ocupada, pom_ai_task_busy rechaza la nueva tarea sin iniciar su operación. Las entradas de tarea están limitadas a 1 MiB y los resultados conservados a 2 MiB. Una asignación compartida de 128 MiB cubre las cargas útiles y los resultados de las tareas, reservando 2 MiB para cada operación aceptada hasta que termine.

Cuando se necesita capacidad de recibos o de bytes, la admisión elimina primero los recibos terminales más antiguos, sin eliminar tareas en cola o en ejecución ni sus aprobaciones de escritura independientes. Si aún no se puede reservar capacidad, rechaza la admisión. Las tareas en cola tienen una hora para iniciarse; los resultados caducan hasta una hora después de la finalización y pueden eliminarse antes bajo presión de capacidad. Cron elimina los registros caducados. Guarda los resultados cuando los recibas; la ausencia de un recibo nunca demuestra que una escritura no se ejecutó. Usa operaciones paginadas más pequeñas y retroceso; estos límites son independientes de la cuota por minuto.

Cada sitio de destino puede tener una operación siguiente lista para su ejecutor de cron. Por lo tanto, el cron de un sitio retrasado no impide que la operación lista de otro sitio compita por el único trabajador pesado compartido. Las operaciones posteriores para el mismo sitio permanecen en cola. Un evento de recuperación periódico restaura el trabajo programado que falta sin volver a reproducir una operación que ya comenzó. Los nuevos envíos no posponen una recuperación que ya vence. Si otro lote de POM AI mantiene la ranura de ejecución, el trabajador listo reintenta 30–60 segundos después sin esperar en PHP.

Estos límites cubren el almacenamiento de tareas MCP y la concurrencia de operaciones pesadas MCP. No establecen un porcentaje de CPU, un techo de memoria PHP ni un recuento total de procesos PHP: el arranque de WordPress, las solicitudes entrantes, los ejecutores de cron y otros plugins siguen usando recursos del servidor. La asignación de 128 MiB excluye la sobrecarga de la base de datos, los datos de otros plugins y las subidas temporales ordinarias.

Envía un mensaje JSON-RPC por solicitud HTTP, no mayor de 1 MiB. Las herramientas de dominio conservan sus entradas de lote documentadas. Los lotes de términos largos comprueban un presupuesto de trabajo de 15 segundos entre entradas; inspecciona los resultados parciales antes de continuar. Este presupuesto no interrumpe una devolución de llamada de WordPress que ya se está ejecutando.

La revisión humana no reserva un trabajador. Sondea la tarea de preparación para obtener la revisión pendiente; después de la confirmación, inspecciónala con pom_site_get_write_job antes de ejecutar sus operaciones.

Estrategia del cliente

Usa la paginación de forma responsable, almacena en caché los resultados de descubrimiento para la conexión actual y evita leer el mismo recurso antes de cada llamada a herramienta. Serializa las escrituras consecuentes en lugar de lanzar un lote amplio de llamadas independientes. Ante un límite de velocidad, espera al siguiente límite de minuto y reintenta con retroceso; los bucles inmediatos solo prolongan el patrón de fallo.

Sigue poll_after_seconds en cada recibo de tarea mientras terminal sea falso. Comienza en cinco segundos y aumenta a treinta segundos para las tareas más antiguas, reduciendo las solicitudes de estado repetidas mientras la cola está ocupada. Las solicitudes de estado cuentan solo hacia su presupuesto de estado de tarea independiente, además de la comprobación temprana de intentos de autenticación. Una cuota de catálogo o de envío no consume ese presupuesto de estado.

Usa phase para distinguir waiting_for_dispatch, waiting_for_cron y executing; created_at y started_at describen el tiempo de la tarea. Las fases terminales coinciden con su estado final. Detén el sondeo automático cuando terminal se vuelva verdadero e inspecciona el resultado final, incluidos los errores de red anidados. Consulta el contrato completo del recibo de tarea.

No reintentes automáticamente escrituras no idempotentes después de una respuesta perdida. Lee primero el estado objetivo.

El límite de velocidad protege el sitio de WordPress; no está relacionado con los saldos de crédito de POM AI y no modifica las cuotas del proveedor.

Guías relacionadas: solución de problemas de límite de velocidad, transporte y receta de auditoría de solo lectura.