Servidor MCP: ¿qué límite de tasa evita desbordar la cuenta?

El límite que evita la cuenta desbordada es el techo por operación, contado en la capa que ve la llamada de herramienta, no el techo por servidor MCP. El techo no es un número de protección. Es una decisión de economía, y quien no la toma en el proyecto termina tomándola en medio del incidente, con el gráfico todavía subiendo.

A las 2:40, el panel de operación muestra la curva de llamadas de herramienta saliéndose de escala. Nadie sabe si eso es un cliente que paga descubriendo un caso de uso nuevo o un agente en bucle. El gráfico solo muestra el síntoma. La respuesta está en quién cree el servidor que está llamando.

La especificación del Model Context Protocol, en la revisión de 2026-07-28, exige que el servidor valide todas las entradas de herramienta, implemente control de acceso, limite la tasa de invocación de herramientas y sanitice las salidas. El texto normativo tiene cuatro palabras: "Rate limit tool invocations". Unidad, número, ventana y respuesta no están ahí. El resto es ingeniería de quien opera.

Requisitos previos: qué existe antes del primer límite de tasa MCP

Antes de elegir un número, cuatro cosas tienen que existir: identidad por llamada, un contador que sobreviva a la petición, un log con una línea por operación y un dueño nombrado del techo. Sin los cuatro, el límite de tasa MCP se vuelve un número que nadie cuestiona después del incidente.

• Identidad por llamada: un contador sin sujeto cuenta el total del servidor. El sujeto es la credencial con audiencia validada, y clientInfo es una etiqueta declarada, no identidad.
• Un contador que sobreviva a la petición y sea compartido entre réplicas: el protocolo quedó sin sesión, y nada garantiza que la llamada siguiente caiga en el mismo proceso.
• Un log con una línea por operación, con herramienta, llamador, resultado y duración.

El cuarto ítem es el más barato y el que más falta: un dueño nombrado del techo. Sin dueño, el número sube con la primera queja y nadie registra el motivo.

Una operación, aquí, es un tools/call admitido, un POST. Un input_required hace que el cliente repita con id nuevo, y el limitador cobra las dos: el techo cuenta petición, no invocación lógica.

Los seis pasos:

1. Elige la unidad del techo.
2. Dimensiona el techo de rpm por el peor caso.
3. Calcula el costo por operación aceptada.
4. Decide dónde corre el techo.
5. Trata el rechazo de cuota como error de negocio.
6. Define la excepción de abuso antes del incidente.

Paso 1: elige la unidad del límite de tasa por operación

La unidad decide qué protege el techo. Por servidor, protege la infraestructura y deja que el agente gaste por su cuenta. Por agente, protege la cuenta y deja el servidor expuesto. Por operación, protege la factura por llamada. La elección es qué riesgo limitar primero.

Los tres niveles de techo de gasto de clave y gasto por agente limitan el consumo del modelo; la tabla de abajo limita el tráfico de herramientas. Son dos cuentas.

Cada unidad engaña a su manera: el techo por servidor MCP aguanta la infraestructura cuando un agente es el mayor consumidor, el de herramienta cae cuando el agente cambia de herramienta, el de agente cae cuando dos equipos comparten la credencial, y el de operación cae cuando la cuenta que importa es la del resultado.

Paso 2: dimensiona el techo de rpm por el peor caso, no por el promedio

El techo de rpm sale de la concurrencia y de la latencia de la herramienta, no del promedio del mes. Con N llamadas simultáneas y latencia L en segundos, el servidor MCP recibe cerca de N por 60 dividido por L operaciones por minuto. Ese número es rendimiento en saturación de lazo cerrado, no pico observado.

Llamadas simultáneas: N. Latencia de la herramienta: L, en segundos. Operaciones por minuto: N × 60 ÷ L.

Ejemplo de cuenta, sin precio y sin medición: 40 llamadas simultáneas con 1,5 segundos de latencia dan 1.600 operaciones por minuto, y el margen de 25% lleva el techo de rpm a 2.000.

El margen no es simpatía, es el precio de no detener la operación legítima: un techo demasiado alto documenta el desborde, y uno demasiado bajo rechaza llamada buena.

El techo queda por encima del pico legítimo y por debajo de lo que el presupuesto sostiene, y el publicado es el menor de los dos. El gasto permitido por ventana dividido por el costo de una operación aceptada, que define el paso siguiente, da cuántas operaciones aceptadas paga la factura; dividir por la tasa de aceptación llega al rpm admitido. El techo de rpm protege la disponibilidad, y el del presupuesto protege la factura: es el que rechaza el bucle cuando la factura no paga la tasa legítima.

La ventana es una elección: una fija de 60 segundos admite hasta el doble del techo en el cambio de ventana, así que usa ventana deslizante o cubo de tokens.

El techo cuenta operaciones de alguien, y la identidad del llamador en el tráfico de agentes decide quién es ese alguien.

Paso 3: calcula el costo por operación MCP que devolvió resultado

El costo por operación es el gasto total dividido por las operaciones que devolvieron un resultado utilizable. Incluye los intentos que fallaron, las repeticiones que pidió el modelo y la llamada de herramienta que cobró sin entregar. Operación intentada no es operación pagada.

El gasto total tiene dos lados. El de la herramienta es ejecución y llamada. El del contexto es lo que la operación hace con la llamada de modelo siguiente: definición y resultado son entrada cobrada por token, y el tamaño del resultado es la palanca. Listas con ttlMs y cacheScope, y orden determinista, recortan el costo de actualización.

La tasa de aceptación es el multiplicador que nadie ve.

La cuenta tiene dos números: operaciones intentadas y aceptadas. Un agente que intenta 1.000 operaciones y entrega 250 carga el costo de las otras 750: tres operaciones fallidas por operación aceptada, y una operación aceptada cuesta cuatro unidades de operación.

Son cuentas distintas: el costo operativo de un gateway de IA mide el overhead de la capa en latencia, memoria y costo por petición, y el costo por operación aceptada mide la llamada que devolvió resultado.

El límite de tasa por operación tiene una trampa: cuenta llamadas que el techo admitió, y llamada admitida no es llamada que devolvió resultado.

Paso 4: decide dónde corre el techo, en el servidor MCP o en el enrutador de LLM

El techo solo vale donde llega la identidad. La RFC 6585, sección 4, deja el criterio de identificación abierto: si el servidor identifica por la credencial y el gateway presenta la propia, el contador cuenta el gateway entero, y la cuota por agente deja de existir ahí.

La revisión de 2026-07-28 dejó el protocolo sin sesión, con credencial por petición, y la capa de control del tráfico de herramientas es el único punto que ve, en la misma petición, la operación y quién la pidió; el servidor valida que el token fue emitido para él y no lo reenvía, como ya describió identidad del llamador.

La capa identifica la operación por los encabezados: Mcp-Method en toda petición y Mcp-Name en tools/call, reflejando el nombre de la herramienta. Cuenta por herramienta sin leer el cuerpo.

El cambio de credencial no es una falla de configuración: el dato que sostenía la cuota por agente no cruza la frontera. La cuota por agente muere ahí. Quien opera la capa que ve la operación asume el techo por llamador.

El techo por servidor MCP sigue donde siempre estuvo: es el techo que existe sin intermediario en el camino, y por eso se queda.

El Nexforce Router es un gateway de LLM con enrutamiento entre más de 300 modelos, presupuesto por clave, por agente y por proyecto, y rastro de cada llamada, lo que hace auditable el gasto de modelo por llamada.

La capa de enrutamiento mide y gobierna el lado del modelo y el gasto de la clave, y ninguna herramienta decide el techo en lugar del dueño de la operación.

Paso 5: trata el error de techo como error de negocio, no como error de herramienta

La especificación define error de ejecución por el lugar donde se reporta, en el resultado de la herramienta con isError: true, y recomienda que el cliente devuelva esos errores al modelo para permitir autocorrección. El rechazo de cuota, el error de techo de esta pieza, no es resultado de herramienta. Devolverlo como error de herramienta le enseña al agente a intentar de nuevo.

Son tres capas. Error de protocolo es objeto de error JSON-RPC, que el cliente puede omitir del modelo. Error de ejecución va en el resultado con isError: true. El rechazo de cuota es la tercera: en el transporte llega como 429, el código de la RFC 6585, sección 4, con detalle y Retry-After opcional.

La separación vale para el rechazo del limitador, antes del despacho. Cuando la herramienta envuelve una API de tercero y su 429 vuelve como isError: true, el implementador traduce la señal a error de negocio.

La RFC 9110, sección 10.2.3, define Retry-After como fecha HTTP o número entero de segundos, la única espera estandarizada que el llamador obedece.

Reempaquetar el rechazo como isError es el atajo caro: el modelo lee falla corregible, intenta de nuevo, y la repetición consume la cuota que el techo protegía. El llamador necesita el error de negocio, con techo nombrado y espera.

Y la espera necesita jitter: un Retry-After en segundos enteros sincroniza a los llamadores y devuelve la ráfaga en el cambio de ventana. El presupuesto de repetición y el techo de llamadas en vuelo por llamador completan la respuesta de rechazo. Llamada en vuelo es la que todavía no volvió, y sin concurrencia limitada un bucle ocupa todas las conexiones.

La repetición ciega después de un rechazo es el mismo error de lectura que tratar el failover como balanceo, como muestra failover no es load balancer.

Paso 6: define la excepción de abuso antes del incidente

Bucle de agente, lote legítimo y cliente abusivo producen el mismo síntoma y piden respuestas distintas. La excepción es un ítem de proyecto: clave separada, techo propio, vigencia declarada y dueño nombrado, decidida con el sistema en calma, nunca en el incidente, y la diferencia solo aparece en el registro que pide la sección.

Síntoma idéntico: volumen fuera de curva en el mismo servidor MCP, rechazo subiendo, y una mala hora para descubrir la diferencia. El bucle es un bug. El lote legítimo pide ventana agendada y techo propio, y el abusivo pide límite contractual, no un ajuste silencioso en el panel.

Lo que tiene que quedar registrado:

• La clave separada y el techo propio de cada excepción.
• La vigencia declarada, con fecha de revisión.
• El dueño nombrado que aprueba la renovación.

La excepción que nadie revisa es un segundo techo, con el nombre del primero.

Cómo verificar que el techo funciona

La verificación tiene cuatro lecturas: el contador del gateway cierra con el del servidor MCP, la tasa de rechazo por techo se queda en el rango esperado, la latencia p95 no empeora después del límite y el costo por operación MCP deja de subir con el volumen.

El trace de la llamada de LLM es la fuente de las cuatro: cada lectura compara dos conteos que solo existen si la llamada quedó registrada entera.

La primera es la conciliación, que solo cierra cuando los dos lados filtran igual: mismo método, misma ventana y mismo mapa de llamador, sin tools/list ni repeticiones.

La segunda es el rango de rechazo. Rechazo cerca de cero con volumen creciendo quiere decir techo flojo; rechazo alto en un pico legítimo quiere decir techo bajo, y el síntoma llega en la queja antes que en el panel.

La tercera es la latencia p95: si empeora después del límite, la cola del techo está mal. La cuarta es el costo por operación aceptada, que no sube con el volumen.

Errores comunes y cómo corregirlos

Un techo único para todas las herramientas es el primero. Búsqueda y escritura no tienen la misma latencia ni el mismo costo, y el techo único sobra para una y falta para la otra. La corrección es un techo por herramienta, con el del servidor como paraguas.

Un techo dimensionado por el promedio es el segundo: nunca aguanta el peor caso, que es el que desborda la cuenta. La corrección es la cuenta del Paso 2, con el margen declarado.

Un contador en memoria que se reinicia en el despliegue es el tercero. Todo despliegue devuelve cuota llena. Con POST independientes el hueco es mayor, porque N réplicas con contador local dan N veces el techo publicado, y tiene que ser atómico y compartido, no solo persistente.

Un rechazo sin detalle ni espera declarada es el cuarto. El llamador no sabe si espera un segundo o una hora, entonces intenta de nuevo, y el intento es lo que el techo debía impedir. La corrección es el Retry-After de la RFC 9110, con el techo nombrado.

Preguntas frecuentes

¿Qué exige la especificación a un servidor MCP en límite de tasa? Exige que el servidor limite la tasa de invocación de herramientas, con validación de entrada, control de acceso y sanitización de salida, en la revisión de 2026-07-28. El texto normativo es "Rate limit tool invocations", y no fija unidad, número, ventana ni respuesta: esos cuatro quedan con quien opera el servidor.

¿Qué unidad de techo usar cuando el agente es compartido? Dos al mismo tiempo. El techo de rpm por agente protege la cuenta cuando la credencial es de un solo agente; el techo por servidor protege la infraestructura cuando varios agentes suman volumen. Con credencial dividida, la atribución desaparece y el techo por agente pasa a valer para el grupo entero.

¿Qué cambia cuando el gateway deja de reenviar la clave del llamador? El contador del servidor pasa a contar el gateway, no el agente. La RFC 6585, sección 4, deja la identificación abierta, y la especificación prohíbe reenviar el token del cliente. El techo corre donde la operación es visible, y quien ve la operación asume el techo por llamador.

¿Cómo debe reaccionar el agente a un rechazo de cuota? Como error de negocio, no como error de herramienta. El rechazo llega en el transporte, con el techo nombrado y la espera declarada, y el agente espera con jitter en vez de repetir. Reempaquetado como error de ejecución, se vuelve orden de nuevo intento que consume la cuota que el techo protegía.

¿Cuándo el techo por servidor sigue siendo la elección correcta? Cuando el riesgo es que caiga la infraestructura, y no que suba la factura. Es el techo que existe sin ningún enrutador de LLM en el camino: un cliente que habla directo con el servidor pasa por él, y en esa ruta el techo por llamador solo existe si el servidor cuenta la credencial que ya valida.

Referencias y lectura complementaria

• Model Context Protocol, especificación, revisión 2026-07-28, página de herramientas. Acceso el 27/10/2026. https://modelcontextprotocol.io/specification/2026-07-28/server/tools
• Model Context Protocol, autorización, consideraciones de seguridad, revisión 2026-07-28. Acceso el 27/10/2026. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
• RFC 6585, sección 4, 429 Too Many Requests. Acceso el 27/10/2026. https://www.rfc-editor.org/rfc/rfc6585.txt
• RFC 9110, sección 10.2.3, Retry-After. Acceso el 27/10/2026. https://www.rfc-editor.org/rfc/rfc9110.txt

Cuándo revisar el techo

El techo es premisa, no constante. Cuatro cambios obligan a rehacer el Paso 2 y el Paso 3 en vez de subir el número: herramienta nueva o herramienta que cambió de latencia, cambio en la concurrencia del agente, llamador nuevo en el mismo servidor MCP y cambio en la forma en que la credencial llega al servidor. Rehacer la cuenta cuesta una tarde. Descubrir la premisa vieja cuesta el trimestre. El techo es una pieza de la capa de gateway, y qué es un gateway LLM muestra dónde encaja.