Resumen de la publicación
El Model Context Protocol (MCP) se convirtió en el estándar de facto para conectar agentes de IA con herramientas y datos: lo que antes era integración a medida, multiplicada en cada proyecto, hoy se resuelve con un servidor que los agentes descubren en tiempo de ejecución.
Comparto por qué me parece el cambio de arquitectura más importante del último año para quienes construimos agentes, qué ordena de verdad y por qué, al mismo tiempo, su seguridad todavía corre por detrás de su adopción.
Hay tecnologías que se anuncian con mucho ruido y otras que, casi sin que te des cuenta, terminan ordenando cómo trabajás. El Model Context Protocol (MCP) es de las segundas. Lo lanzó Anthropic a fines de 2024 como un estándar abierto y, año y medio después, lo veo en todos lados: en los IDEs que uso, en los productos de los alumnos del AI-First Builders Lab y hasta en las herramientas de la competencia directa de Anthropic. Quiero contarte por qué, desde mi punto de vista, es el cambio de arquitectura más sano que nos pasó en el mundo de los agentes.
El problema que vengo viendo hace rato
Si alguna vez armaste un sistema con varios agentes, esto te va a sonar. Cada agente necesita «herramientas» —buscar en una base, llamar a una API, mandar un mail—, y esas herramientas terminan definidas en tres o cuatro lugares distintos, cada una con su pequeña variación. Cambiás el esquema de una y tenés que tocar cuatro archivos. La lógica de aprobación humana cableada a mano, una por herramienta. Sumar una capacidad nueva significa coordinar entre equipos que ni comparten el mismo código. Es deuda técnica que crece sola.
Hay un artículo muy concreto en Towards Data Science que describe este dolor con números: un equipo con siete agentes, herramientas duplicadas en varios módulos, actualizaciones de esquema que obligaban a editar cuatro archivos. Lo que me gustó es el «después»: movieron las herramientas a un único servidor MCP y los agentes pasaron a descubrirlas en tiempo de ejecución en lugar de mantener copias locales. Agregaron una herramienta nueva una semana y al día siguiente el agente ya la estaba usando, sin tocar el orquestador. Eso, para cualquiera que haya sufrido el cableado a mano, es enorme.
Qué ordena MCP, en criollo
La idea de fondo es simple y por eso funciona: en vez de que cada agente tenga sus integraciones hechas a medida, hay servidores que exponen herramientas, recursos y prompts de forma estándar, y clientes (tu agente, tu IDE, tu app) que se conectan y los descubren. Está inspirado en el Language Server Protocol, ese que hizo que un mismo soporte de lenguaje sirviera para todos los editores en vez de reescribirlo para cada uno. Acá la analogía es directa: escribís la integración una vez, contra un estándar, y la consume cualquiera.
El beneficio que más valoro no es técnico sino organizativo: queda un contrato claro entre quien mantiene las herramientas y quien arma el agente. El equipo de datos cuida su servidor, el de aplicación cuida su orquestación, y nadie tiene que meter mano en el código del otro. Esa separación de responsabilidades es justo lo que falta cuando un proyecto de agentes empieza a crecer.
Por qué digo que «ganó»
No es entusiasmo de fanático. En 2026 adoptaron MCP de forma nativa OpenAI, Google en Gemini y Microsoft —que incluso publicó un SDK oficial en C# y lo soporta de manera nativa en VS Code y en el modo agente de Copilot—, además de Cursor, Replit y Sourcegraph. Y hay una señal todavía más fuerte: en diciembre de 2025 Anthropic donó MCP a la Linux Foundation, sacándolo de la órbita de un solo proveedor y convirtiéndolo en infraestructura gobernada por la comunidad. Cuando un estándar deja de ser «el protocolo de tal empresa» para pasar a ser neutral, es porque la industria ya lo dio por ganador.
La parte que no me quiero saltear: la seguridad
Ahora, seamos honestos, porque esto también lo enseño y no quiero venderte humo. La seguridad de MCP va por detrás de su adopción. En los primeros meses de 2026 se reportaron más de 40 CVEs contra implementaciones de MCP: inyección de comandos, inyección de prompts, el clásico «confused deputy», riesgos de cadena de suministro porque muchos servidores MCP son software que descargás de repositorios públicos. Y todavía no hay un límite a nivel protocolo para el consumo de tokens o llamadas a API, así que un servidor malicioso puede vaciarte la cuenta. La madurez operativa, por ahora, no está a la altura de la madurez estratégica.
¿Qué hago con eso? Lo mismo que recomiendo en clase: usar MCP —porque ordena de verdad y es el camino— pero vetar los servidores que conectás como vetarías cualquier dependencia, endurecer la autenticación y poner límites de consumo. El estándar correcto mal asegurado sigue siendo un problema.
El nuevo perímetro de los agentes
Si tuviera que resumir lo que pienso: MCP es a los agentes lo que los drivers estándar fueron al hardware o lo que HTTP fue a la web. No es glamoroso, es plomería, y justamente por eso importa tanto. Lo que viene no es discutir si lo adoptamos, sino aprender a operarlo bien —vetando, autenticando, limitando—, porque la herramienta que conectás hoy con dos líneas es también la puerta por la que puede entrar el problema de mañana. ¿Ya estás usando MCP en tus proyectos, o todavía lo estás mirando de afuera? Me encantaría leer tu experiencia en los comentarios.
