El Model Context Protocol (MCP) es un protocolo abierto desarrollado inicialmente por Anthropic que define un estándar para que modelos de lenguaje (LLMs) puedan descubrir, acceder e interactuar con herramientas, fuentes de datos y servicios externos de forma segura y estandarizada.
Cualquiera que haya conectado un modelo de lenguaje con sistemas reales conoce el patrón: escribes un adaptador a medida para que el LLM hable con tu base de datos, otro para tu API interna, otro para el warehouse… y cuando cambias de modelo, vuelves a empezar. Cada nueva combinación de modelo × herramienta es integración nueva, frágil y difícil de mantener. Es el clásico problema n×m: con m modelos y n herramientas acabas manteniendo n×m piezas de pegamento.
El Model Context Protocol (MCP) es un estándar abierto que da a los modelos de IA una forma universal de conectarse a herramientas externas, fuentes de datos y servicios. La analogía que se ha vuelto canónica lo resume bien: MCP es el «USB-C para la IA» —un único conector en lugar de un cable distinto por cada dispositivo. Construyes un servidor una vez y cualquier cliente compatible puede usarlo. El problema n×m se convierte en n+m.
MCP en cifras (julio de 2026)• Publicado por Anthropic en noviembre de 2024; hoy es el estándar de facto para conectar IA con el mundo real. • Adoptado por OpenAI, Google, Microsoft, AWS y Snowflake, entre otros. • Los SDK de Python y TypeScript suman ~97 millones de descargas mensuales. • Más de 10.000 servidores públicos activos; un censo independiente indexó más de 17.000. • En diciembre de 2025 se donó a la Agentic AI Foundation, bajo la Linux Foundation: ya es un estándar vendor-neutral. |
1. ¿Qué es el Model Context Protocol y por qué es importante?
Técnicamente, MCP hace por la integración de IA lo que REST hizo por los servicios web: proporciona un vocabulario compartido que vuelve interoperables sistemas que antes no lo eran. La diferencia respecto a versiones anteriores de «tool calling» es que MCP no es la API de un único proveedor, sino una capa por encima: define cómo una aplicación de IA descubre e invoca capacidades, con independencia del modelo que haya debajo.
El punto de inflexión llegó a finales de 2025. Cuando Anthropic donó MCP a la Linux Foundation —con OpenAI, Google, Microsoft, AWS, Cloudflare y Bloomberg respaldando la iniciativa— dejó de ser «el protocolo de Anthropic» para convertirse en infraestructura de industria. Para un equipo técnico, esto cambia el cálculo: apostar por MCP ya no es apostar por un vendor, sino por un estándar con gobernanza abierta, working groups y un proceso formal de propuestas de mejora (SEP).
Una vez entendido qué es Model Context Protocol, veamos cómo está diseñado internamente y cómo interactúan sus distintos componentes.
2. Cómo funciona el Model Context Protocol: la arquitectura
MCP define tres roles y un protocolo de mensajería. Entenderlos es todo lo que necesitas para tener el modelo mental correcto:
- Host — la aplicación de IA (un IDE, Claude, tu agente). Contiene uno o más clientes y es donde viven la seguridad y el consentimiento del usuario.
- Client — el conector 1:1 dentro del host que mantiene la conexión con un servidor concreto.
- Server — el programa que expone capacidades: tu wrapper de Snowflake, de dbt, del filesystem o de cualquier API.
La comunicación se hace con JSON-RPC 2.0 sobre uno de dos transportes: stdio para servidores locales lanzados como subproceso, y Streamable HTTP para servidores remotos. Y expone tres primitivas, que son el corazón del modelo: tools (acciones ejecutables), resources (contexto de solo lectura) y prompts (plantillas reutilizables). Un detalle de diseño importante: la seguridad no vive en el protocolo, sino en el host, que es dueño del consentimiento, del alcance de las credenciales y de la allow-list por herramienta.
3. Cómo crear tu primer servidor Model Context Protocol
La forma más rápida de interiorizarlo es escribir uno. Con el SDK oficial de Python bastan unas pocas líneas para exponer una tool y un resource. El siguiente servidor da a un agente acceso de solo lectura a un warehouse de Snowflake:
| from mcp.server.fastmcp import FastMCP
import snowflake.connector
mcp = FastMCP(«snowflake-analytics»)
def _connect(): return snowflake.connector.connect( account=»mi_cuenta», user=»svc_agent», role=»RO_ANALYST», # rol de solo lectura, mínimo privilegio warehouse=»WH_AGENT_XS», )
@mcp.tool() def run_query(sql: str) -> str: «»»Ejecuta una consulta SELECT sobre el warehouse y devuelve el resultado.»»» if not sql.strip().lower().startswith(«select»): raise ValueError(«Solo se permiten consultas de lectura.») with _connect() as cx: rows = cx.cursor().execute(sql).fetchmany(100) return «\n».join(str(r) for r in rows)
@mcp.resource(«schema://{table}») def table_schema(table: str) -> str: «»»Expone el esquema de una tabla como contexto de solo lectura.»»» with _connect() as cx: cols = cx.cursor().execute(f»DESCRIBE TABLE {table}»).fetchall() return «\n».join(f»{c[0]}: {c[1]}» for c in cols)
if __name__ == «__main__»: mcp.run() # transporte stdio por defecto |
Fíjate en el patrón: la tool es una acción con una validación explícita (rechaza cualquier cosa que no sea un SELECT), y el resource entrega contexto sin efectos secundarios. El docstring no es decorativo: se convierte en la descripción que el modelo lee para decidir cuándo usar la herramienta. Esa descripción viajará al contexto del LLM —recuérdalo, porque es la puerta que explotan los ataques que veremos más abajo.
4. MCP para data engineers: cerrar el «context gap»
Aquí es donde el Model Context Protocol deja de ser una curiosidad y se vuelve estratégico para quien trabaja con datos. El problema de fondo lo resume bien la propia Snowflake: en data engineering de producción el contexto lo es todo, pero la mayoría de herramientas de IA operan fuera de tu entorno. Generan SQL en aislamiento, no conocen tus esquemas, tus convenciones ni tu lineage, así que el ingeniero acaba reconstruyendo ese contexto a mano en cada prompt. Es fricción que crece con la complejidad del sistema.
MCP es precisamente el puente que cierra ese hueco: en vez de describirle el warehouse al modelo, le das acceso gobernado a él. Y el ejemplo más maduro en el mundo de los datos es el servidor MCP de dbt. Da a los agentes acceso gobernado a los assets gestionados por dbt —incluida la Semantic Layer— para que descubran métricas y modelos y tiren de lineage, documentación y señales de confianza antes de generar una sola query. Es lo que dbt Labs llama la «structured context layer»: el sitio donde el significado se define una vez, en código, con control de versiones, review, tests y lineage, y se mantiene correcto en el tiempo.
Lo potente aparece al combinar fuentes. Un host puede registrar varios servidores a la vez —tu warehouse y tu capa semántica, por ejemplo— y el agente los orquesta. La configuración es tan simple como declararlos (ejemplo ilustrativo; ajusta el comando de arranque a la documentación de cada servidor):
| {
«mcpServers»: { «snowflake»: { «command»: «python», «args»: [«snowflake_server.py»] }, «dbt»: { «command»: «uvx», «args»: [«dbt-mcp»], «env»: { «DBT_PROJECT_DIR»: «/ruta/a/mi/proyecto» } } } } |
Cuando el modelo trabaja dentro de estas guías, el beneficio es triple: correctness (las queries siguen las definiciones oficiales de métricas y esquema), gobernanza (accesos, contratos y trust signals se aplican de extremo a extremo) y eficiencia de coste (prompts más pequeños, menos escaneos del warehouse y menos reintentos). Para un data engineer, MCP no es «IA que escribe SQL»: es la capa que conecta esa IA con el conocimiento que tu equipo ya modela cada día.
Como cualquier estándar que conecta modelos de IA con sistemas reales, MCP también introduce nuevos retos de seguridad que conviene conocer antes de llevarlo a producción.
5. Seguridad en MCP: el tema que no puedes ignorar
Un artículo honesto sobre MCP en 2026 tiene que hablar de seguridad, porque el mismo diseño que lo hace potente abre una superficie de ataque nueva. La vulnerabilidad estrella es el tool poisoning, una forma de inyección de prompt indirecta que OWASP sitúa en lo más alto de su Top 10 para aplicaciones agénticas.
El mecanismo es elegante y peligroso a la vez. Un atacante publica —o compromete— un servidor MCP cuyas herramientas parecen inofensivas, pero cuyas descripciones o respuestas contienen instrucciones ocultas. Cuando el agente las lee, esas instrucciones caen en el contexto del LLM y se tratan como input de confianza. La causa raíz es un gap de confianza entre el connect-time y el runtime: las descripciones de herramientas se revisan una sola vez, al conectar, pero las respuestas van directas al contexto sin ningún control equivalente. A eso se suma la «fatiga de aprobación»: los usuarios aceptan invocaciones sin inspeccionarlas.
Figura 2. Anatomía de un ataque de tool poisoning y las mitigaciones que lo contienen.
No es teoría: hay research de Microsoft Defender y de la academia documentando estos ataques contra clientes reales, y la propia NSA publicó en 2026 una guía de consideraciones de diseño de seguridad para MCP. La buena noticia es que las mitigaciones son conocidas y accionables:
- Human-in-the-loop: la spec exige que un humano pueda denegar cada invocación de herramienta. No lo desactives «por comodidad».
- Mínimo privilegio: credenciales de alcance reducido y allow-list por herramienta (como el rol de solo lectura del ejemplo).
- Pinning de descripciones: fija y verifica el metadata de las tools; rechaza cambios silenciosos entre sesiones.
- Cadena de suministro: usa servidores de fuentes confiables (el MCP Registry ayuda), el modelo OAuth Resource Server y sandboxing.
6. Hacia dónde va: el núcleo «stateless» de 2026
Si vas a construir sobre MCP, conviene mirar la nueva especificación 2026-07-28, la mayor revisión desde el lanzamiento. El cambio estrella es que el protocolo pasa a ser stateless. Desaparecen el handshake initialize y la cabecera Mcp-Session-Id, de modo que cualquier request se convierte en autocontenido y puede aterrizar en cualquier instancia del servidor:
| POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: run_query Content-Type: application/json
{ «jsonrpc»: «2.0», «id»: 1, «method»: «tools/call», «params»: { «name»: «run_query», «arguments»: { «sql»: «select 1» } } } |
Para un data engineer esto es enorme desde el punto de vista operativo: un servidor remoto que antes exigía sticky sessions y un almacén de sesión compartido ahora corre detrás de un load balancer round-robin normal, escala horizontalmente sin estado y permite cachear listas de herramientas. El estado que tu aplicación necesite se maneja de forma explícita (el modelo pasa un identificador de una llamada a la siguiente), lo que además lo hace visible y auditable. La revisión trae también un framework de Extensions —con MCP Apps (UIs renderizadas por el servidor) y Tasks (trabajo de larga duración)— y un endurecimiento de la autorización alineado con OAuth 2.0 y OpenID Connect.
Conclusión
MCP ha recorrido en año y medio el camino que a otros estándares les lleva una década: de propuesta de un solo vendor a infraestructura común gobernada por la Linux Foundation, adoptada por competidores directos y medida en decenas de millones de descargas al mes. Para quien programa —y muy especialmente para quien trabaja con datos— el mensaje es claro: MCP se ha convertido en una skill requerida junto a REST y gRPC. La recomendación práctica es igual de directa: deja de escribir integraciones de usar y tirar, y empieza a exponer tus sistemas como servidores MCP. Los minutos que inviertas hoy en estandarizar una herramienta se pagan en mantenibilidad, gobernanza y flexibilidad durante mucho tiempo.
En definitiva, Model Context Protocol se perfila como el estándar que permitirá conectar modelos de IA con herramientas, aplicaciones y plataformas de datos de forma interoperable. Igual que REST transformó las APIs web, MCP tiene el potencial de convertirse en la infraestructura sobre la que se construirán los agentes de inteligencia artificial de los próximos años.
Preguntas frecuentes sobre MCP:
¿Qué es el Model Context Protocol (MCP)?
El Model Context Protocol (MCP) es un estándar abierto que permite conectar modelos de inteligencia artificial (LLMs) con herramientas, bases de datos, APIs y servicios externos mediante un protocolo común. Su objetivo es que cualquier cliente compatible pueda descubrir e invocar capacidades de forma estandarizada, evitando desarrollar integraciones específicas para cada modelo. Gracias a MCP, los desarrolladores pueden crear aplicaciones de IA más reutilizables, escalables y fáciles de mantener.
¿Para qué sirve Model Context Protocol?
El Model Context Protocol sirve para que un modelo de IA pueda acceder de forma segura a información y herramientas externas, como bases de datos, sistemas empresariales, APIs o plataformas de datos. En lugar de limitarse al conocimiento incluido en su entrenamiento, el modelo puede consultar información actualizada, ejecutar acciones y trabajar con datos reales mediante una interfaz estandarizada.
¿Quién creó el Model Context Protocol?
El Model Context Protocol (MCP) fue presentado por Anthropic en noviembre de 2024 como un estándar abierto para la integración de modelos de IA con sistemas externos. En diciembre de 2025, el protocolo pasó a estar gestionado por la Agentic AI Foundation, bajo la Linux Foundation, con el respaldo de empresas como OpenAI, Google, Microsoft, AWS, Snowflake y Cloudflare, consolidándose como un estándar abierto y neutral.
¿Cómo funciona el Model Context Protocol?
MCP se basa en una arquitectura formada por tres componentes principales: Host, Client y Server. El host es la aplicación que utiliza el modelo de IA, el cliente mantiene la conexión con un servidor específico y el servidor expone herramientas, recursos o prompts que el modelo puede utilizar. La comunicación se realiza mediante JSON-RPC 2.0 sobre diferentes transportes, permitiendo que un mismo servidor pueda ser utilizado por múltiples clientes compatibles.
¿Qué ventajas ofrece Model Context Protocol frente al tool calling tradicional?
La principal diferencia es que MCP no depende de un único proveedor de IA. Mientras que el tool calling suele estar ligado a una plataforma concreta, Model Context Protocol define un estándar abierto que cualquier modelo compatible puede utilizar. Esto reduce el número de integraciones necesarias, facilita la interoperabilidad entre herramientas y disminuye el coste de mantenimiento de las aplicaciones de inteligencia artificial.
¿Por qué Model Context Protocol es importante para los data engineers?
Para los equipos de datos, Model Context Protocol elimina el llamado context gap, permitiendo que los modelos de IA accedan directamente a información estructurada como esquemas, métricas, documentación o lineage. Esto mejora la precisión de las consultas, reduce errores al generar SQL y permite aprovechar plataformas como Snowflake o dbt con un acceso gobernado y seguro.
¿Qué plataformas son compatibles con Model Context Protocol?
Actualmente, el ecosistema de Model Context Protocol cuenta con el respaldo de numerosos proveedores tecnológicos. Entre ellos se encuentran OpenAI, Anthropic, Google, Microsoft, AWS y Snowflake, además de una creciente comunidad de desarrolladores que publica miles de servidores MCP para integrar herramientas, bases de datos, servicios cloud y aplicaciones empresariales.
¿Es seguro utilizar Model Context Protocol?
Sí, siempre que se apliquen buenas prácticas de seguridad. El protocolo delega el control del acceso en el host, que gestiona el consentimiento del usuario, las credenciales y los permisos disponibles para cada herramienta. Además, es recomendable utilizar el principio de mínimo privilegio, servidores de confianza, listas de herramientas autorizadas y mecanismos para prevenir ataques como el tool poisoning o la inyección indirecta de prompts.
¿Qué relación existe entre Model Context Protocol y dbt o Snowflake?
Model Context Protocol facilita que herramientas como dbt y Snowflake expongan información estructurada a modelos de IA mediante servidores MCP. De esta forma, los agentes pueden consultar métricas, modelos, documentación, esquemas o lineage directamente desde la Semantic Layer, generando respuestas y consultas SQL mucho más precisas y alineadas con la gobernanza de datos de la organización.
¿Por qué se considera MCP el «USB-C de la inteligencia artificial»?
Se compara con el USB-C porque proporciona un único estándar para conectar modelos de IA con múltiples herramientas y servicios. En lugar de desarrollar una integración distinta para cada combinación de modelo y aplicación, basta con implementar un servidor MCP una sola vez para que cualquier cliente compatible pueda utilizarlo, simplificando enormemente la interoperabilidad entre sistemas.
¿Cuál es la diferencia entre MCP y una API REST?
Una API REST define cómo una aplicación consume un servicio concreto, mientras que Model Context Protocol (MCP) define cómo un modelo de inteligencia artificial descubre y utiliza herramientas de forma estandarizada. REST resuelve la comunicación entre aplicaciones; MCP resuelve la comunicación entre modelos de IA y herramientas externas. Ambos pueden coexistir, ya que muchos servidores MCP utilizan APIs REST para acceder a los sistemas que exponen.
Nota: el ecosistema MCP evoluciona muy rápido. Trata los números de adopción y los nombres de clientes/servidores como una foto de julio de 2026, no como datos permanentes.
