Durante casi todo 2024, los proyectos de agentes que construimos terminaban con una carpeta llamada más o menos tools/: definiciones de funciones hechas a mano, schemas JSON improvisados, 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 sustituir esa carpeta por una interfaz de verdad. Casi todos los equipos lo siguen tratando como una comodidad para desarrolladores. Nosotros empezamos a tratarlo como lo que es: 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 lo que una tool puede hacer.
El auth deja de ser una preocupación por cada tool. El servidor es dueño de la frontera de credenciales. El agente nunca ve la API key, ni la contraseña de la base de datos, ni el refresh token de OAuth. El radio de daño de un prompt comprometido baja un orden de magnitud.
El drift de schema deja de ser silencioso. Cuando cambia la API de facturación, cambia con ella el schema de respuesta del servidor MCP. El agente falla ruidosamente en la siguiente llamada, y no en silencio tres semanas después, cuando nadie repara en un campo vacío.
La lógica de retry, timeout y rate limit deja de copiarse y pegarse entre wrappers. Vive en el servidor, que es su sitio, junto al resto de las cuestiones operativas de esa integración.
Dónde entra la disciplina de producción
Un servidor MCP es software de producción, no un script de pegamento. Merece el mismo kit operativo que cualquier otro sistema que entregamos: un eval que ejercite las tools contra inputs realistas, un runbook para cuando el servidor devuelva respuestas mal formadas, un registro de decisiones que explique por qué existe cada tool, y un dueño.
El error que vemos una y otra vez es tratar MCP como un problema del agente. No lo es. Un servidor MCP es un servicio de producción cuyo único cliente, por ahora, resulta ser el agente. Constrúyelo con ese criterio.
Lo que todavía no hacemos con MCP
No ponemos un servidor MCP con permisos de escritura delante de un agente de horizonte largo sin un verificador en el loop. El radio de daño de una tool call equivocada y convincente, dentro de un agente de varios pasos, es mayor de lo que casi ningún equipo ha modelado.
No exponemos toda la superficie SQL de una base de datos de producción como una tool MCP, por más que las demos lo hagan parecer sencillo. El eval no puede defender ese resultado, y el modelo terminará lanzando contra datos vivos una query que nadie quería.
Y no dejamos que el servidor MCP sea el sitio donde la revisión de seguridad se salta porque «lo llama la IA». Si un servicio operado por humanos necesitaría credenciales acotadas y un audit log para llamar a ese mismo endpoint, el agente necesita exactamente lo mismo.
Por qué esto importa antes de que se vuelva mainstream
MCP está más o menos donde estaba REST en 2008: real, útil, cada vez más común y todavía desplegado casi siempre como un proyecto paralelo. Los equipos que lo construyan ahora como interfaz de producción —con eval, dueño y runbook— van a pasar los próximos dos años operando sin sobresaltos. Los que lo traten como pegamento van a pasarlos depurando las costuras.