Durante casi todo 2024, cada proyecto de agente que tocamos terminaba con una carpeta llamada algo así como tools/: definiciones de funciones hechas a mano, esquemas JSON ad-hoc, una clase wrapper por integración y una maraña de lógica de retry y timeout reinventada en cada proyecto. El Model Context Protocol es el primer intento creíble de reemplazar esa carpeta con una interfaz real. La mayoría de los equipos todavía lo trata como una conveniencia para desarrolladores. Nosotros estamos empezando a tratarlo como la interfaz de producción entre el agente y los sistemas que toca.
Qué cambia cuando MCP es el contrato
Cuando el agente habla con tus bases de datos, tu índice de búsqueda, tu sistema de tickets y tu API de facturación a través de servidores MCP, cuatro cosas dejan de ser tu problema y pasan a ser problema del servidor.
Las definiciones de tools dejan de ser prompts escritos a mano. Las produce el servidor, las versiona el servidor y el agente las descubre en runtime. El prompt del agente deja de ser la fuente de verdad sobre qué puede hacer una tool.
El auth deja de ser una preocupación por tool. El servidor es dueño de la frontera de credenciales. El agente nunca ve la API key, la contraseña de la base de datos ni el refresh token de OAuth. El blast radius de un prompt comprometido baja un orden de magnitud.
El drift de esquema deja de ser silencioso. Cuando la API de facturación cambia, el esquema de respuesta del servidor MCP cambia con ella. El agente falla ruidosamente en la siguiente llamada, no silenciosamente tres semanas después cuando nadie nota el campo vacío.
La lógica de retry, timeout y rate-limit deja de copiarse y pegarse entre wrappers de tools. Vive en el servidor, donde corresponde, junto con el resto de las preocupaciones operativas de esa integración.
Dónde aplica la regla de la fábrica
El servidor MCP es una pieza de software de producción, no un script de pegamento. Merece el mismo kit operativo que cualquier otro sistema de producción que entregamos: un set de evaluación que ejercita las tools contra inputs realistas, un runbook para cuando el servidor devuelve respuestas mal formadas, un registro de decisiones de por qué existe cada tool, y un dueño.
El error que vemos cometer a los equipos es tratar a MCP como un problema del agente. No lo es. El servidor MCP es un servicio de producción del que el agente es, por ahora, el único cliente. Constrúyelo como tal.
Lo que todavía no hacemos con MCP
No ponemos un servidor MCP con capacidad de escritura delante de un agente de horizonte largo sin un verificador en el loop. El blast radius de una llamada a tool confiadamente equivocada dentro de un agente de varios pasos es mayor de lo que la mayoría de los equipos ha modelado.
No exponemos toda la superficie SQL de una base de datos de producción como tool MCP, aunque las demos lo hagan ver fácil. La evaluación no puede defender el resultado, y el modelo, eventualmente, va a correr una query que nadie quería a las 3 a. m.
No dejamos que el servidor MCP sea el lugar donde la revisión de seguridad se saltea porque "lo llama la IA". Si un servicio humano llamando al mismo endpoint necesitaría credenciales acotadas y un audit log, el agente necesita lo mismo.
Por qué esto importa antes de que sea mainstream
MCP está más o menos donde estaba REST en 2008: real, útil, cada vez más común, y todavía mayormente desplegado como si fuera un proyecto paralelo. Los equipos que lo construyan ahora como una interfaz de producción — con evaluación, dueño y runbook — van a pasar los próximos dos años operando limpiamente. Los equipos que lo traten como pegamento van a pasar esos dos años depurando las costuras.