Model Context Protocol: el “nuevo HTTP” para agentes de IA

OPINIÓN · FUTURO DE INTERNET · AGENTES DE IA

De “abrir una web” a “encargar una tarea”: por qué vuelven a importar los protocolos

HTTP fue el pegamento de la web gráfica que conoces: el protocolo sencillo con el que un navegador pedía páginas y un servidor se las devolvía. Encima de ese gesto tan simple se construyeron Google, Amazon, redes sociales, SaaS, fintech y media internet tal y como la usamos hoy.

La ola de agentes de IA apunta a un cambio de interfaz igual de radical: pasamos de hacer clic en botones a describir objetivos (“reserva un viaje”, “revisa estos contratos”, “sincroniza este informe con el CRM”) y dejar que un agente negocie con varias herramientas por nosotros. Para que esto funcione a gran escala, los modelos necesitan un “lenguaje base” para hablar con calendarios, bases de datos, ERPs, APIs, documentos locales, etc. Ahí entra MCP.

Si te interesan estas capas más “orquestadoras” de la IA, tiene mucha conexión con la transición hacia asistentes más autónomos y multimodales de la que hablo en este análisis sobre asistentes de IA agentic.

Qué es exactamente el Model Context Protocol (MCP)

MCP es un estándar abierto para conectar aplicaciones de IA (como un chat, un IDE con asistente o un copiloto corporativo) con fuentes de datos, herramientas y flujos de trabajo externos. La metáfora oficial es muy gráfica: “un USB-C para aplicaciones de IA”. En lugar de inventar un conector distinto para cada herramienta, todos se enchufan al mismo tipo de puerto.

El protocolo lo lanzó Anthropic a finales de 2024 como especificación abierta, y define cómo se intercambian mensajes entre tres piezas:

• El host: la app que “contiene” al modelo (por ejemplo, un cliente de chat o un editor de código).
• El cliente MCP: la parte que traduce las intenciones del modelo en llamadas al protocolo.
• El servidor MCP: el servicio que expone herramientas, datos o acciones concretas (consultar una base de datos, llamar a una API, leer un repositorio, etc.).

Todo esto viaja sobre JSON-RPC 2.0 y puede transportarse tanto por stdio (ideal para procesos locales) como por HTTP o HTTP+SSE (más natural para servicios remotos), lo que lo convierte en un protocolo de “capa de aplicación” bastante flexible.

Desde la práctica, puedes imaginar MCP como una interfaz normalizada donde un agente pide cosas del tipo: “llama a la herramienta buscar_fichas_cliente con estos parámetros y devuélveme el resultado”. El detalle importante es que esa solicitud tiene el mismo formato, se hable con un CRM propio, con Slack o con una base de datos en Postgres.

Qué problema real resuelve (y por qué a los desarrolladores les entusiasma)

Antes de MCP, cada proveedor iba inventando su manera de conectar modelos con el mundo: APIs de “function calling”, plugins, conectores propietarios, SDKs específicos… Eso crea el famoso problema N×M: si tienes muchos modelos y muchas herramientas, terminas con una explosión de integraciones personalizadas difíciles de mantener.

MCP ataca ese problema de frente: defines un servidor MCP para tu sistema (ERP, CRM, herramienta interna, servicio SaaS) y, en teoría, cualquier agente compatible con el protocolo podría usarlo sin que tengas que reescribir la integración para cada modelo o proveedor. El resultado es menos pegamento frágil y más piezas intercambiables.

De hecho, ya hay servidores MCP de referencia para Google Drive, Slack, GitHub, Postgres, Stripe y otros servicios populares, y se está empezando a ver un ecosistema de “marketplace” de servidores MCP listos para enchufar a tus agentes.

Cómo funciona MCP por dentro (versión sin dolor de cabeza)

Técnicamente, MCP define unos cuantos conceptos simples:

1. Herramientas

Un servidor MCP expone “tools”: funciones con nombre, parámetros tipados y resultados estructurados. Para un agente, una tool es el equivalente a un superpoder: “enviar_email”, “buscar_facturas”, “generar_dashboard”, etc. Los parámetros y respuestas van en JSON, así que encajan bien con el resto del stack web.

2. Recursos y contexto

Además de tools, un servidor puede exponer recursos de solo lectura (por ejemplo, un documento, un fichero de configuración o un fragmento de código) y “prompts” o plantillas especializadas. Esto ayuda a que el agente tenga siempre a mano el contexto importante sin tener que empapuzar el prompt con todo el histórico.

3. Transporte flexible

El mismo protocolo funciona tanto si el servidor MCP está corriendo en tu máquina local (por ejemplo, leyendo tus archivos y tu repositorio de código) como si está en la nube, hablando con servicios de terceros. Eso permite escenarios curiosos: un agente que mezcla datos ultra locales (tu portátil) con datos corporativos (en la nube) bajo la misma abstracción.

Si construyes copilotos internos, la idea es sugerente: en lugar de un mosaico de integraciones ad-hoc, levantas unos cuantos servidores MCP y dejas que el agente negocie con ellos. Esta visión encaja muy bien con el enfoque de automatización por flujos que comentaba al hablar de copilotos internos con herramientas como n8n.

Por qué muchos lo llaman “el nuevo HTTP” (y hasta dónde llega la comparación)

La comparación con HTTP no es solo marketing: hay paralelismos claros. HTTP permitió que cualquier navegador hablara con cualquier servidor web usando unas pocas operaciones estándar. MCP quiere que cualquier agente de IA pueda hablar con cualquier herramienta o servicio compatible usando un vocabulario común de mensajes, herramientas y recursos.

Igual que HTTP fue clave para que surgiera la “web de páginas”, MCP puede ser clave para una “web de agentes”: en lugar de navegar tú entre servicios, delegas en un conjunto de agentes que negocian entre sí. Varios directivos de grandes tecnológicas ya hablan de un “agentic web” donde los agentes colaboran y se coordinan entre empresas distintas, y mencionan explícitamente MCP como uno de los estándares que podría hacerlo viable.

Ahora bien, la analogía tiene límites: HTTP sirve para casi todo lo que pasa por la web; MCP, de momento, se centra en la conversación entre modelos y herramientas. Es posible que en el futuro conviva con otros protocolos más especializados, igual que hoy conviven HTTP, WebSockets, gRPC, etc.

Quién está detrás: de invento de Anthropic a proyecto bajo la Linux Foundation

MCP nació dentro de Anthropic, donde dos ingenieros (David Soria Parra y Justin Spahr-Summers) buscaban una manera más limpia de conectar a Claude con entornos de desarrollo, repositorios y sistemas corporativos. La primera versión pública llegó en noviembre de 2024 con SDKs para varios lenguajes y un buen puñado de servidores de ejemplo.

Desde entonces, MCP se ha ido expandiendo de forma casi silenciosa: OpenAI lo ha integrado en su ecosistema de agentes y conectores, Microsoft lo soporta en Azure para construir agentes sobre su nube, y otras empresas como Google DeepMind, AWS o Cloudflare han mostrado apoyo público a su adopción.

El movimiento clave ha sido el reciente traslado de MCP a la Agentic AI Foundation, un fondo dirigido bajo el paraguas de la Linux Foundation. Anthropic lo ha donado como proyecto fundacional, junto con otros componentes como Goose (Block) o AGENTS.md (OpenAI). La idea: garantizar una gobernanza neutral y abierta para estándares de agentes de IA, evitar el control exclusivo de una sola empresa y atraer contribuciones de todo el sector.

Qué se puede hacer hoy con MCP (más allá de las demos bonitas)

Aunque el hype es reciente, MCP ya se está usando en casos muy concretos:

• Coding assistants: IDEs y herramientas tipo Claude Code o extensiones de VS Code que, vía MCP, pueden leer tu repositorio, ejecutar tests, lanzar scripts o modificar archivos con un contrato bien definido.
• Acceso a bases de datos: servidores MCP que actúan como “traductores” entre consultas en lenguaje natural y SQL sobre Postgres u otros motores.
• Copilotos empresariales: agentes que consultan CRM, sistemas de tickets, documentación interna y herramientas SaaS a través de servidores MCP reutilizables.
• Orquestación multi-agente: entornos donde distintos agentes se reparten tareas pero comparten el mismo catálogo de herramientas expuesto vía MCP.

Combinado con técnicas avanzadas de recuperación de contexto, MCP encaja muy bien en arquitecturas modernas de RAG y “graph-RAG”, de las que hablo con más detalle en este artículo sobre Graph-RAG y conocimiento empresarial.

El lado menos glamuroso: seguridad, identidad y nuevas superficies de ataque

Hacer que agentes de IA puedan hablar con tus sistemas es tan potente como peligroso. MCP no es una bala de plata mágica: si se usa mal, abre puertas enormes a errores y ataques. Ya se han identificado riesgos específicos, como fugas de información por instrucciones maliciosas incrustadas en los datos (prompt injection “embebido”) o servidores MCP expuestos con credenciales débiles.

El gran punto débil hoy no es tanto el protocolo en sí como la gestión de identidad y permisos: MCP puede convertirse en el “túnel” por el que un agente con credenciales sobredimensionadas haga cosas que nadie quería (borrar datos, tocar infraestructura, filtrar información sensible). La recomendación que se repite entre expertos es clara: autenticación fuerte, credenciales efímeras, principio de mínimo privilegio y trazabilidad de todo lo que hace un agente.

También hay una capa regulatoria que no se puede ignorar. Si estás en Europa o trabajas con datos de usuarios europeos, el uso de agentes de IA conectados a sistemas críticos entra de lleno en el radar del EU AI Act y su impacto en pymes y autónomos. MCP facilita la integración técnica, pero no te exime de cumplir con requisitos de gobernanza, evaluación de riesgos o registro de sistemas de alto riesgo.

Qué cambia para ti si construyes productos con IA

Si solo usas un par de asistentes en tu día a día, probablemente MCP te afecte de manera indirecta: la experiencia será más fluida, los agentes tendrán más “poderes” y hablarán con más herramientas sin que tú veas los cables. Pero si estás construyendo productos o infraestructura, MCP sí debería estar en tu radar.

A grandes rasgos, te plantea tres decisiones:

• ¿Eres consumidor o proveedor de MCP?
  Puedes limitarte a usar servidores MCP existentes (para conectarte a Google Workspace, Slack, etc.) o dar el salto y exponer tus propios sistemas como servidores MCP reutilizables.
• ¿Cómo diseñar tu catálogo de herramientas?
  Igual que diseñar una API REST no es trivial, decidir qué tools expones por MCP, con qué granularidad y con qué permisos será una pieza crítica de tu arquitectura de agentes.
• ¿Cómo encaja en tu estrategia de lock-in?
  MCP facilita moverse entre proveedores de modelos sin reescribir integraciones, pero también permite que tus clientes se lleven sus agentes a otro sitio. Es una apuesta consciente por la interoperabilidad.

Si ya estabas experimentando con copilotos internos, automatizaciones y flujos entre herramientas (algo de lo que hablo en detalle en este artículo sobre copilotos internos open source), MCP te da una pieza de lego más estándar y, a medio plazo, menos frágil que las integraciones caso por caso.

Posibles futuros: tres escenarios para la “web de agentes”

Escenario 1: MCP se convierte en el HTTP de facto de los agentes

En este futuro, casi todos los agentes importantes del mercado hablan MCP, los SaaS lanzan su servidor MCP oficial igual que hoy lanzan su API REST, y el usuario final raramente ve una interfaz clásica: habla con un par de agentes que, por debajo, están encadenando decenas de herramientas interconectadas. El valor se desplaza hacia quién diseña mejor esos agentes y flujos, no tanto hacia quién controla el protocolo.

Escenario 2: ecosistema mixto con varios estándares

Otra opción es que MCP coexista con protocolos alternativos: algunos más cerrados y optimizados para un proveedor concreto, otros adaptados a sectores regulados (finanzas, salud, sector público). Aquí MCP sería el “mínimo común denominador” para muchas integraciones, pero no la única vía. Es probablemente el escenario más realista a medio plazo.

Escenario 3: MCP queda como nicho developer, pero deja huella

También puede ocurrir que la idea de un protocolo unificado gane, pero el estándar concreto evolucione a otra cosa o sea absorbido por soluciones más verticales. Incluso en ese caso, MCP habrá marcado el camino: dejar de pensar en “plugins” y empezar a pensar en agentes que se conectan a un bus de herramientas bien definido.

En qué fijarte a partir de ahora

Más allá del hype, lo interesante de MCP es lo que revela sobre hacia dónde se mueve el ecosistema:

• Los agentes dejan de ser juguetes aislados y se convierten en piezas que se conectan de forma profunda con sistemas de negocio reales.
• Los estándares abiertos vuelven al centro del juego, como en los primeros años de la web, después de una fase de APIs propietarias y plugins cerrados.
• La seguridad y la gobernanza pasan de ser notas a pie de página a elementos de diseño de primer nivel.
• La ventaja competitiva se desplaza a quién combina mejor modelos, datos y herramientas, no solo a quién tiene el modelo más grande.

Si estás construyendo algo con IA hoy, merece la pena seguir de cerca la evolución de MCP: ver qué soporte añaden tus proveedores, qué SDKs y servidores aparecen en tu stack favorito y qué prácticas de seguridad se consolidan como “mínimo decente”. No hace falta que lo adoptes mañana, pero ignorarlo por completo es, probablemente, una mala idea.

Igual que HTTP parecía “solo un detalle técnico” antes de que cambiara la economía digital, MCP puede ser ese componente invisible que, dentro de unos años, dé forma a la manera en que tus agentes hablan con el mundo. La diferencia es que esta vez llegamos con la experiencia de treinta años de internet a cuestas. Depende de nosotros aprovecharla.