El problema que nadie nombra bien
Cuando uno empieza a construir sistemas con inteligencia artificial, hay una ilusión de progreso: haces una llamada a una API, obtienes un texto, produces algo que parece inteligente. Funciona. Pero si te detienes a mirarlo desde fuera, lo que tienes es un tubo recto: entrada, procesamiento, salida. No un sistema. Un truco.
El verdadero problema aparece cuando quieres que múltiples modelos, herramientas y contextos colaboren sin que tú tengas que cablear manualmente cada conexión. Quieres composición. Quieres que el agente sepa dónde está, qué herramientas tiene disponibles, qué está haciendo el entorno que lo rodea — y que esa información llegue de forma estructurada, no como texto libre que alguien tiene que parsear a mano.
Esa es la pregunta que me llevó al Model Context Protocol.
Qué es MCP y por qué importa más allá del código
MCP es un protocolo abierto que define cómo un modelo de lenguaje puede interactuar con herramientas y contexto externo de manera estandarizada. En lugar de que cada integración invente su propia forma de pasar datos, MCP propone un contrato: hay servidores que exponen capacidades (herramientas, recursos, prompts) y hay clientes que las consumen. La negociación ocurre mediante JSON-RPC sobre stdio o HTTP.
Esto puede sonar técnico y aburrido. Pero si uno piensa en lo que significa desde la abstracción, es algo más profundo: MCP es el reconocimiento de que los agentes necesitan un idioma compartido antes de poder cooperar. Es la diferencia entre pedirle a alguien que haga algo y tener un equipo con roles claros, contratos de interfaz y canales de comunicación definidos.
En filosofía del lenguaje, Wittgenstein argumentó que los límites de mi lenguaje son los límites de mi mundo. Para los agentes de IA, el protocolo de comunicación define qué mundos son siquiera posibles.
Lo que construí
MCPagents es un servidor MCP con capacidades autónomas integradas con OpenAI. Expone dos modos de operación: un servidor stdio para integrarse directamente con editores como VS Code o Claude Desktop, y un servidor HTTP para quienes prefieren una API REST o quieren composición vía web.
Las herramientas que expone son deliberadas. autonomous_ask permite que cualquier cliente MCP le haga preguntas al asistente con contexto automático del proyecto — estado de git, estructura de archivos, archivos principales — sin que el cliente tenga que saber cómo recolectar ese contexto. analyze_code lleva eso al dominio técnico: análisis, corrección, optimización, explicación. get_project_context lo hace explícito: si el agente necesita saber dónde está parado, puede preguntar.
El detalle que me parece más revelador es la detección automática del modelo y la configuración de parámetros. Cada modelo de OpenAI tiene restricciones distintas sobre tokens, temperatura, y cómo se llaman ciertos campos. El servidor absorbe esa complejidad internamente. Para el cliente MCP, hay una interfaz uniforme. Eso es encapsulación en el sentido más serio: no esconder complejidad por comodidad, sino eliminar la necesidad de que el agente consumidor sepa cosas que no le conciernen.
La lección sobre sistemas que colaboran
Hay una diferencia fundamental entre un sistema que usa IA y un sistema donde la IA es un componente que puede ser reemplazado, combinado o extendido. El primero es monolítico aunque parezca moderno. El segundo es componible.
MCP me enseñó que la composabilidad no es gratuita. Exige decisiones de diseño que duelen un poco al principio: definir contratos explícitos en lugar de acoplamientos implícitos, exponer capacidades en lugar de implementaciones, pensar en quién va a consumir esto y qué necesita saber versus qué no debería necesitar saber.
Esa disciplina es lo que separa construir un agente que funciona hoy de construir una arquitectura que puede crecer mañana. No es que los agentes autónomos de propósito único sean malos — es que tienen un techo de complejidad muy bajo. Cuando quieres que varios agentes resuelvan problemas juntos, necesitas un protocolo. Necesitas MCP, o algo equivalente en rigor.
De MCPagents hacia algo más grande
Este proyecto fue, en retrospectiva, un punto de inflexión. No porque el código sea espectacular — es un servidor en JavaScript con integraciones estándar. Sino porque el problema que resuelve sentó las bases conceptuales para lo que construiría después.
Si quieres un sistema donde múltiples agentes especializados colaboran — uno que razona, otro que busca información, otro que ejecuta acciones — necesitas exactamente lo que MCP provee: un protocolo que permita que esos agentes se descubran, negocien capacidades y se comuniquen sin que tú tengas que mantener el código de integración en tu cabeza todo el tiempo.
La arquitectura agéntica no es solo poner varios modelos juntos. Es diseñar sistemas donde la inteligencia emerge de la composición, no de un único modelo omnisciente. Eso requiere protocolos. Requiere contratos. Requiere pensar en los agentes no como cajas negras mágicas sino como componentes de software con interfaces bien definidas.
MCPagents fue donde empecé a pensar en esos términos.
El fondo filosófico
Hay algo interesante en el hecho de que los sistemas más capaces de IA no son los más grandes, sino los mejor coordinados. Un modelo de 70 mil millones de parámetros trabajando solo puede ser menos efectivo que tres modelos más pequeños con roles claros y un protocolo de comunicación sólido. La inteligencia colectiva, cuando está bien organizada, supera a la inteligencia individual.
Eso no es nuevo. Es lo que las ciencias sociales llevan siglos estudiando en los humanos. Lo que cambia con MCP y los sistemas agénticos es que ahora podemos diseñar esa coordinación explícitamente, con la precisión de un contrato de software.
Eso me parece filosóficamente honesto: no atribuirle propiedades mágicas a los modelos de lenguaje, sino entender que su valor real aparece cuando están bien integrados en sistemas que los usan bien. El protocolo no es el detalle técnico aburrido. Es la condición de posibilidad del sistema.