Anthropic publicó el Model Context Protocol (MCP) en noviembre de 2024 como protocolo abierto para conectar modelos con herramientas externas: bases de datos, repositorios, sistemas de tickets. Hoy ese mismo protocolo corre en Claude Desktop, Cursor, VS Code y en el Agents SDK de OpenAI. La adopción ha ido más rápido que la madurez operativa: hay equipos que ya han dado a sus agentes acceso de escritura a sistemas reales sin permisos por herramienta, sin límites de uso y sin registrar nada. Llevar MCP en producción con garantías se reduce a tres capas: permisos, quotas y logs.
Qué MCP resuelve y qué te deja pendiente
Técnicamente, MCP es un protocolo basado en JSON-RPC 2.0 en el que un servidor expone herramientas, recursos y prompts, y el cliente los descubre e invoca en tiempo de ejecución. Los transportes oficiales son stdio para procesos en la misma máquina y Streamable HTTP para servidores remotos; la revisión 2025-03-26 retiró el transporte anterior basado en SSE.
La especificación evoluciona por revisiones fechadas (2024-11-05, 2025-03-26 y 2025-06-18) y ninguna de las tres define quotas, sandboxing ni políticas por herramienta. Eso queda en manos de quien explota el sistema. La división más sana es tratar MCP como capa de transporte y cada herramienta como un objeto de producción con dueño y presupuesto.
Siguiente paso: inventaría los servidores MCP que tocan tus entornos de producción y anota para cada uno qué sistema externo accede y con qué credencial.
Permisos: OAuth 2.1 y mínimo privilegio
La revisión vigente, 2025-06-18, define los servidores MCP como resource servers OAuth 2.1: tokens de vida corta, con audiencia acotada y validados contra la audiencia prevista. Aplícale a cada servidor el mismo mínimo privilegio que esperarías de un microservicio. Si una herramienta envuelve una base de datos, su credencial debe ser un rol de solo lectura sobre las tablas necesarias, no la cuenta de administrador.
Después viene el control por herramienta. Los clientes ya dan pie para esto: Claude Code pide confirmación antes de ejecutar acciones y permite decidir si la autorización vale siempre, solo una vez o ninguna. Sobre esa base, mantén una allowlist por agente y obliga a confirmación humana explícita en las herramientas destructivas: despliegues, borrados, envíos.
El riesgo más traicionero no está en tu código, sino en las descripciones de terceros. Invariant Labs documentó en 2025 ataques de tool poisoning, con instrucciones maliciosas ocultas en la descripción de una herramienta, y también casos en los que esa descripción cambia después de que el usuario la haya aprobado. Su utilidad open source mcp-scan inspecciona los servidores y marca descripciones sospechosas.
Siguiente paso: fija versión o hash de cada servidor permitido, rescanea con cada actualización y trata el diff de descripciones de tools como un evento auditable.
Quotas: límites por llamada, por usuario y por token
Ninguna parte de la especificación habla de rate limiting, de concurrencia máxima o de gasto acumulado, así que la práctica extendida es poner una gateway entre el agente y los servidores y medir ahí. Etiqueta cada llamada con herramienta, usuario y desenlace, y define tres topes: llamadas por minuto por usuario, llamadas concurrentes por servidor y presupuesto mensual por herramienta de alto coste. Cuando el tope se cruce, la gateway responde con error y el agente debe tratarlo como cualquier fallo de herramienta.
En la capa de modelo, LiteLLM soporta presupuestos y límites de peticiones por minuto y tokens por minuto por clave, y responde con 429 al agotar el cupo. En la capa MCP, Docker lanzó en 2025 su MCP Gateway, que expone los servidores como endpoints gestionados: un punto natural para inyectar políticas. Añade caché cuando la arquitectura te lo permita: muchas llamadas a herramientas repiten la misma consulta y no necesitan reejecutarse.
Siguiente paso: define un SLO por herramienta, con latencia p95 objetivo y presupuesto de errores, y configura una alerta para cuando una herramienta consuma su quota mensual antes de la fecha prevista.
Logs de MCP en producción: qué registrar y qué redactar
El registro útil para auditar agentes está en la llamada a la herramienta, no en la respuesta del modelo. Por cada invocación, guarda el nombre de la herramienta, la identidad del agente y del usuario final, los argumentos redactados, el tamaño y estado del resultado, la latencia y un identificador de traza que una la llamada con su turno de conversación. Sin ese identificador, correlacionar un incidente con la conversación que lo provocó se convierte en arqueología.
MCP trae logging nativo, pero no es auditoría: el servidor puede emitir mensajes hacia el cliente con notifications/message, y el cliente controla el nivel con logging/setLevel. Sirve para depurar el proceso del servidor, no para reconstruir qué hizo el agente. Para lo segundo, envuelve cada llamada en un span de OpenTelemetry; las convenciones semánticas de GenAI, todavía experimentales, ya estandarizan los nombres de los atributos.
Hay una consecuencia que muchos descubren tarde: esos logs contienen prompts, argumentos y resultados, y en sistemas reales eso casi siempre incluye datos personales. Trata el almacén de logs como un sistema de primera categoría, con acceso restringido, minimización y retención corta, en el orden de semanas antes que de años. Si el tema te pica, ya cubrimos en el blog qué conviene mantener dentro de tu propia infraestructura cuando entra el RGPD: Privacidad y RGPD con IA local: qué datos nunca salen de tu servidor.
Siguiente paso: redacta los argumentos antes de persistirlos y decide desde el día uno la retención y el control de acceso del almacén de logs.
Por dónde empezar
Un modelo mediocre con buena telemetría es operable; un modelo brillante sin logs de herramientas es una caja negra. Empieza pequeño: elige la herramienta MCP más peligrosa de tu sistema y esta misma semana ponla detrás de un control de permisos, dale un tope de llamadas y registra cada invocación con argumentos redactados. Con ese patrón funcionando para una sola herramienta, replicarlo en el resto es trabajo mecánico, y la primera incidencia de producción te lo agradecerá.