Comprender los límites de velocidad de MCP

MCP y los límites de OAuth protegen el servidor. Se contabilizan por minuto.

Límites por operación

El envío de tareas y el estado tienen presupuestos separados. Consultar una tarea aceptada no consume su presupuesto de envío ni el de catálogo. Las operaciones de lectura y escritura comparten el presupuesto de envío porque la solicitud solo guarda trabajo para su ejecución posterior. Cron no vuelve a cobrar una tarea aceptada una segunda vez.

Las solicitudes de registro, token y revocación de OAuth tienen cada una su propio presupuesto fijo por IP de cliente. Los intentos fallidos también cuentan. Los intentos repetidos de conexión MCP tienen un límite temprano por IP antes de la verificación de credenciales.

El transporte de WordPress 6.8 y el WordPress MCP Adapter incluido usan los mismos presupuestos de envío de tareas y de estado. Las solicitudes concurrentes no pueden compartir la misma franja restante. Un dry_run es también una operación enviada; las comprobaciones de permisos no añaden otro cargo.

Configurar el límite de lectura

Settings → POM AI → MCP server → Runtime limits → Read rate limit per minute, predeterminado 60.

Este ajuste controla las solicitudes de protocolo/catálogo y escala los presupuestos de tareas mayores de la tabla. Reducirlo no disminuye los envíos por debajo de 120 ni el estado de tareas por debajo de 600 por minuto. La capacidad de la cola y un único worker pesado siguen limitando la ejecución de forma independiente.

Cómo se contabilizan las solicitudes

El recuento es por usuario autenticado, por minuto:

• Llamadas MCP de OAuth — por cliente y usuario que actúa, compartido entre los tokens de ese par.
• Clave de API — por clave. Todo lo que use esa clave comparte un presupuesto, razón por la que conviene preferir OAuth cuando se conectan varias herramientas.
• Endpoints OAuth no autenticados — por IP de cliente.

Cada minuto es su propia ventana. Un cliente limitado al final de un minuto puede continuar al comienzo del siguiente.

Un cliente conectado puede hacer varias solicitudes HTTP para inicializar, descubrir herramientas y consultar resultados en segundo plano. El envío y pom_get_task responden directamente sin esperar a cron. Pueden ejecutarse junto con el descubrimiento y otros envíos, sujetos a sus propias cuotas y a la admisión en la cola. Las operaciones pesadas se ejecutan a través de WordPress cron, de una en una para la instalación.

Cómo se ve cuando estás limitado

Un envío rechazado no inicia una operación. Una solicitud de estado rechazada no cancela ni cambia un trabajo que ya fue aceptado. Los errores de herramienta pueden devolverse dentro de una respuesta HTTP 200, así que inspecciona también el resultado de la herramienta.

Qué protege y qué no

Limita la velocidad a la que un cliente puede actuar. Eso ayuda frente a un cliente atascado en un bucle de reintentos, una integración mal configurada que consulta de forma agresiva y una sesión descontrolada que hace más de lo previsto.

Los límites de velocidad no autorizan cambios. Las compuertas de escritura, las capacidades del usuario que actúa, los ámbitos del token y la aprobación de los cambios exactos siguen siendo necesarios. Consulta MCP security model.

Durante la configuración

Cada endpoint OAuth permite cinco intentos por minuto por IP, de modo que un cliente que reintenta en bucle un intercambio fallido puede agotar el presupuesto de ese endpoint. Registrar un cliente no consume el presupuesto del endpoint de token.

Al diagnosticar un fallo de OAuth: cambia una cosa, prueba una vez, espera si ves 429. Los reintentos repetidos ocultan si tu corrección funcionó.

Durante el trabajo en lote

Usa operaciones acotadas, envía cada cambio previsto una sola vez y consulta su tarea existente. La cola puede llenarse antes de que se agote un presupuesto por minuto, sobre todo cuando cron se retrasa o el trabajo tarda más en terminar.

Sigue consultando tras poll_after_seconds mientras terminal sea false. Cuando pase a true, inspecciona el estado y el resultado finales antes de continuar. Nunca reproduzcas automáticamente una escritura uncertain. Consulta el background result contract.

Reducir la frecuencia con la que lo alcanzas

• Pide registros específicos en lugar de listados amplios.
• Prefiere herramientas que devuelvan recuentos frente a herramientas que devuelvan cada registro.
• Deja que el cliente almacene en caché la lista de herramientas en lugar de volver a listarla en cada turno.
• Envía un mensaje JSON-RPC por solicitud HTTP. Ambos transportes rechazan lotes de protocolo; las herramientas individuales pueden aceptar sus propias entradas de lote documentadas.
• Sigue Retry-After, o JSON-RPC data.retry_after, ante un rechazo de cuota y poll_after_seconds ante una tarea pendiente. Consultar no vuelve a enviar la operación.
• Distribuye los trabajos grandes entre límites de minutos. Abrir otra sesión no restablece el presupuesto del mismo usuario.

Comprobar si los límites son el problema

Inspecciona la respuesta en el cliente y los registros MCP recientes en el panel de ajustes. Las denegaciones de autenticación repetidas se muestrean, y una solicitud rechazada antes de la autenticación puede no tener una entrada de registro individual. Un registro vacío no demuestra que la solicitud haya fallado en origen.

Si el servidor informa de que la limitación de solicitudes no está disponible temporalmente, espera y pide al administrador del sitio que compruebe el almacenamiento de WordPress. El servidor no ejecuta la operación mientras esa salvaguarda no esté disponible.

Multisitio

Los límites son por sitio, ya que cada sitio tiene su propio servidor, tokens y clave de API. Las conexiones de sitios separados tienen presupuestos separados. Las solicitudes delegadas a través de la conexión MCP del sitio principal también siguen sujetas a los límites de esa conexión.