El protocolo de contexto del modelo es un estándar abierto que permite a las aplicaciones de IA conectarse a fuentes de datos y herramientas externas a través de una interfaz común. En lugar de crear un conector específico para cada repositorio, CRM, IDE o sistema interno, los desarrolladores pueden exponer el contexto mediante servidores MCP y permitir que un host de IA lo invoque de forma segura, con el consentimiento del usuario. Piense en USB-C para las integraciones de IA, pero con unos bordes de seguridad más afilados.
Protocolo de contexto del modelo, explicado de forma sencilla
El protocolo de contexto del modelo, normalmente abreviado como MCP, fue liberado como código abierto por Anthropic el 25 de noviembre de 2024. Anthropic afirmó que fue creado por David Soria Parra y Justin Spahr-Summers para resolver un problema muy práctico: los asistentes de IA eran cada vez más inteligentes, pero seguían desconectados de los lugares donde se realiza el trabajo útil.
Un modelo de lenguaje por sí solo conoce patrones procedentes del entrenamiento y cualquier cosa que usted pegue en el chat. Una aplicación de IA conectada mediante MCP puede solicitar un archivo de un repositorio, recuperar un registro de cliente, llamar a una herramienta de compilación o utilizar una plantilla de flujo de trabajo proporcionada por un servidor. El protocolo no hace que el modelo sea más inteligente por sí mismo. Proporciona a la aplicación una forma estándar de aportar al modelo el contexto y las acciones relevantes.
La especificación oficial de MCP del 2025-03-26 lo define como un protocolo abierto para la integración entre aplicaciones LLM y fuentes de datos y herramientas externas. Esa redacción importa. MCP no es un modelo, ni un marco de agentes por sí mismo, ni una función exclusiva de Claude, aunque Anthropic lo iniciara.
Si sigue el movimiento más amplio hacia el software autónomo, MCP se sitúa junto a temas como Sistemas de IA que construyen, prueban y mejoran el trabajo en bucles. Proporciona la capa de conexión que esos sistemas necesitan cuando dejan de ser demostraciones y empiezan a interactuar con archivos reales, tickets, bases de datos y herramientas de producción.
¿Por qué apareció MCP en 2024?
Antes de MCP, la mayoría de las integraciones de herramientas de IA eran trabajos a medida. Un equipo creaba un conector para GitHub, otro construía un puente privado con Google Drive, un tercero conectaba un chatbot a Slack o Jira, y todos ellos tenían que resolver la autenticación, los permisos, las descripciones de las herramientas, los errores y el registro de actividad de formas ligeramente distintas.
El coste no es solo tiempo de desarrollo. Los conectores personalizados envejecen mal. Cuando un proveedor cambia una API, cuando una empresa añade un segundo asistente de IA o cuando seguridad pregunta quién puede acceder a qué, el conjunto de integraciones se vuelve incómodo de auditar. MCP surgió en 2024 y 2025 para sustituir esa fragmentación por una única capa de protocolo.
Aquí tiene un cálculo sencillo. Supongamos que una empresa tiene 4 aplicaciones de IA y quiere que cada una acceda a 8 sistemas empresariales. Con integraciones personalizadas por pares, eso supone 32 conectores que diseñar, probar, supervisar y proteger en 2026. Con MCP, el objetivo más limpio se acerca más a 4 clientes del lado del host más 8 servidores, es decir, 12 superficies de integración. Las implantaciones reales no serán perfectamente ordenadas, pero la dirección es evidente: menos puentes a medida, menos lugares donde cometer errores.
Microsoft anunció la primera versión del soporte para MCP en Microsoft Copilot Studio el 19 de marzo de 2025. Una semana después, TechCrunch informó de que OpenAI había puesto MCP a disposición en su Agents SDK y de que Sam Altman dijo que el soporte llegaría a todos los productos de OpenAI, y que más adelante se añadiría compatibilidad con la aplicación de escritorio de ChatGPT y la Responses API. Eso no significa que MCP se haya adoptado de forma universal, pero sí muestra por qué los desarrolladores empezaron a prestarle atención rápidamente.
Cómo funcionan hosts, clientes y servidores
La arquitectura de MCP tiene tres partes principales: hosts, clientes y servidores. El host es la aplicación LLM que inicia las conexiones. Podría ser un IDE con IA, una interfaz de chat o un asistente interno personalizado.
Un cliente reside dentro del host y gestiona una conexión con un servidor. El servidor proporciona contexto y capacidades. En pocas palabras: el host es donde usted habla con la IA, el cliente es el conector y el servidor es el componente orientado al sistema que sabe cómo exponer datos o acciones.
El diagrama oficial puede describirse así: Usuario → aplicación de IA/host → cliente MCP → servidor MCP → herramienta externa o fuente de datos; los resultados vuelven por el mismo camino a la aplicación de IA. No es deslumbrante. Es útil.
La especificación del 2025-03-26 dice que MCP utiliza mensajes JSON-RPC 2.0 entre estas piezas. Los mensajes incluyen Solicitudes, Respuestas y Notificaciones. Una notificación es unidireccional y no debe incluir un ID, lo que parece una trivialidad del protocolo hasta que está depurando por qué una aplicación de IA está esperando una respuesta que nunca debería llegar.
| Componente o característica | Rol definido en 2025 | Ejemplo práctico |
|---|---|---|
| Host | Aplicación LLM que inicia conexiones | Un asistente de programación con IA o una aplicación de chat empresarial |
| Cliente | Conector dentro del host | La parte de la aplicación que se comunica con un servidor MCP |
| Servidor | Proveedor de contexto y capacidades | Un servidor que expone archivos del repositorio, tickets o datos empresariales |
| Recursos | Contexto y datos expuestos a la aplicación de IA | Documentos, registros, archivos fuente, logs |
| Prompts | Mensajes o flujos de trabajo con plantillas | Un flujo de trabajo de triaje de soporte o un prompt de revisión de código |
| Herramientas | Funciones que el modelo puede ejecutar | Crear una incidencia, ejecutar un comando, consultar un sistema |
Los servidores pueden exponer tres tipos principales de capacidades: Resources, Prompts y Tools. Resources son el contexto del lado de lectura. Prompts son plantillas reutilizables o flujos de trabajo. Tools son funciones ejecutables que el modelo de IA puede llamar a través de la aplicación.
Las funciones del lado del cliente en la especificación 2025-03-26 incluían Sampling y listas de directorios raíz, mientras que las utilidades incluían registro, autocompletado de argumentos, seguimiento del progreso, cancelación e informe de errores. Todas las implementaciones deben admitir el protocolo base y la gestión del ciclo de vida. Las demás partes son opcionales, según lo que la aplicación necesite realmente.
¿Qué se puede crear con ello?
Los casos de uso más sólidos de MCP son aburridos en el mejor sentido. Un asistente de programación con IA puede leer un repositorio, inspeccionar una incidencia, sugerir un parche y llamar a una herramienta local. Un asistente de atención al cliente puede recuperar documentos de políticas, resumir un ticket y preparar una respuesta usando una plantilla de flujo de trabajo.
Los IDE con IA son una opción evidente. Si te interesan las herramientas para desarrolladores, la distinción entre los IDE completos y los editores más ligeros en Visual Studio versus Visual Studio Code ayuda a situar dónde pueden aparecer los servidores MCP: cerca del código, las extensiones, los terminales y los archivos del proyecto. Al protocolo en sí no le importa qué editor prefieras.
Los sistemas empresariales son otro objetivo natural. Los repositorios de contenido, las bases de conocimiento internas, las herramientas de ventas y los entornos de desarrollo estuvieron entre los ejemplos citados por Anthropic y la especificación MCP. Zendesk anunció el acceso anticipado a MCP Client el 21 de mayo de 2026, y dijo que el acceso anticipado a MCP Server estaba previsto para el verano de 2026, lo que apunta a que los flujos de trabajo de atención al cliente se conviertan en un caso de prueba generalizado.
Hay un argumento en contra, y merece respeto: si solo necesitas que una aplicación de IA llame a una API estable, MCP puede ser más infraestructura de la necesaria. Sinceramente, esta opción tiene más sentido cuando las integraciones se multiplican o cuando quieres un modelo estándar de seguridad y capacidades en varias herramientas.
- Usa MCP cuando varias aplicaciones de IA necesiten acceso al mismo sistema.
- Usa MCP cuando quieras Resources, Prompts o Tools reutilizables en lugar de soluciones improvisadas basadas solo en prompts.
- Actúa con cautela cuando un servidor pueda ejecutar comandos locales o acceder a datos sensibles.
- No uses MCP como atajo para eludir los permisos normales de la API, el registro o la revisión.
El protocolo también encaja con el auge del comercio agéntico y la automatización de tareas. Si estás siguiendo cómo los agentes de IA pueden actuar en flujos de compra reales, el trabajo de OpenAI y Visa sobre pagos con IA agéntica es un ejemplo útil relacionado, aunque la autorización de pagos tiene su propia carga de cumplimiento normativo.
El riesgo de seguridad que la gente pasa por alto
La promesa de MCP es también su riesgo: puede conectar una aplicación de IA con datos reales y acciones reales. La guía de seguridad de 2025-03-26 dice que los implementadores deben gestionar el consentimiento del usuario, la privacidad de los datos, la seguridad de las herramientas y los controles de muestreo. Los hosts deben obtener el consentimiento explícito del usuario antes de exponer datos del usuario a los servidores o de invocar herramientas.
Un riesgo que rara vez se explica con claridad es la confianza en la descripción de las herramientas. La especificación dice que las descripciones y anotaciones de las herramientas deben considerarse no fiables a menos que procedan de un servidor de confianza. En la práctica, un servidor malicioso o comprometido podría describir una herramienta de forma inocente mientras provoca que el modelo o el host se comporten de manera insegura.
Los investigadores de seguridad han estado observando esto muy de cerca. Un preprint académico del 23 de marzo de 2026 sobre el modelado de amenazas de MCP informó de que el envenenamiento de herramientas era una vulnerabilidad prevalente del lado del cliente y propuso mitigaciones. El 15 de abril de 2026, OX Security reveló lo que calificó como una vulnerabilidad sistémica crítica relacionada con MCP STDIO y el comportamiento de ejecución de procesos locales.
OX afirmó que el problema expuso más de 150 millones de descargas y hasta 200.000 servidores a una posible toma de control. TechRadar informó el 16 de abril de 2026 de que OX dijo que más de 7.000 servidores accesibles públicamente y hasta 200.000 instancias eran vulnerables, y que los SDK oficiales en Python, TypeScript, Java y Rust estaban afectados. Tom’s Hardware también informó sobre esas afirmaciones relativas a los lenguajes de los SDK el 22 de abril de 2026.
Esas cifras proceden de proveedores de seguridad e informes de prensa, no de una auditoría final de un organismo de normalización, por lo que deberías tratarlas como afirmaciones y no como mediciones concluyentes. Aun así, la advertencia es razonable. Cualquier protocolo que permita a una aplicación de IA acceder a procesos locales, credenciales y sistemas empresariales necesita configuraciones predeterminadas conservadoras. Para un contexto de seguridad más amplio, compáralo con cómo se están posicionando las plataformas modernas de seguridad de IA en operaciones de SOC impulsadas por IA.
La autorización también difiere según el transporte. La especificación del 26-03-2025 dice que el marco de autorización de MCP se aplica al transporte basado en HTTP, mientras que el transporte STDIO debería recuperar las credenciales del entorno en su lugar. Pequeño detalle. Gran consecuencia operativa.
Hacia dónde se dirige el estándar en 2026
MCP ha avanzado rápidamente desde que Anthropic lo publicó como código abierto. El 9 de diciembre de 2025, Anthropic anunció la donación de MCP a la Agentic AI Foundation bajo la Linux Foundation, con Block y OpenAI como cofundadores y el apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg. Ese cambio de gobernanza importa porque un estándar de conexión no puede seguir siendo creíble si parece estar controlado por un único proveedor de modelos.
El 9 de marzo de 2026, la hoja de ruta oficial de MCP enumeró prioridades que incluían la escalabilidad del transporte, la comunicación entre agentes, la maduración de la gobernanza y la preparación para la empresa. Esos son exactamente los puntos de presión que cabría esperar tras una adopción temprana: más tráfico, patrones más complejos de agente a agente, una toma de decisiones más clara y requisitos empresariales más estrictos.
Una entrada oficial del blog del 21 de mayo de 2026 publicó la versión candidata de la especificación MCP versión 2026-07-28, con la especificación final prevista para el 28 de julio de 2026. La versión candidata introdujo un núcleo de protocolo sin estado, un marco de Extensions, Tasks, MCP Apps, refuerzo de la autorización y una política formal de obsolescencia. También indicó que Roots, Sampling y Logging están obsoletos.
Si eso suena a muchos cambios, lo es. Los estándares tempranos suelen avanzar así: primero demuestran la demanda y luego reducen la deuda de diseño. Mi opinión es que MCP sigue siendo lo bastante joven como para exigir cautela, pero lo bastante maduro como para que los desarrolladores que crean integraciones serias de IA deban entenderlo ya.
Preguntas frecuentes
¿Es MCP un modelo?
No. MCP es un protocolo para conectar aplicaciones de LLM a contexto, fuentes de datos y herramientas. No sustituye a Claude, GPT, Gemini ni a ningún otro modelo.
¿El protocolo de contexto del modelo es solo para Claude?
No. Anthropic creó y publicó como código abierto MCP, pero la especificación describe un protocolo general para aplicaciones de LLM. Microsoft, OpenAI y Zendesk han anunciado soporte relacionado con MCP o pasos para su adopción.
¿Por qué usar MCP en lugar de API personalizadas?
MCP estandariza las integraciones para que los desarrolladores no tengan que crear conectores personalizados independientes para cada aplicación de IA y cada herramienta externa. El beneficio crece a medida que aumenta el número de aplicaciones y sistemas.
¿Cuáles son los casos de uso reales de MCP?
Los casos de uso habituales incluyen IDE con IA, interfaces de chat, flujos de trabajo de IA personalizados, repositorios de contenido, herramientas empresariales y entornos de desarrollo. Los servicios de asistencia y los asistentes internos de conocimiento son aplicaciones especialmente idóneas.
¿Es seguro usar MCP?
Puede serlo, pero solo con una implementación cuidadosa. Necesitas el consentimiento explícito del usuario, servidores de confianza, permisos limitados para las herramientas, una gestión segura de las credenciales y supervisión para detectar el envenenamiento de herramientas o rutas de ejecución local no seguras.
ES 
EN 
FR