Qué es MCP (Model Context Protocol) y cómo funciona, explicado sin rodeos

Digamos que tienes una distribuidora de refacciones en Guadalajara. El inventario vive en un sistema que te hizo un proveedor hace años, los clientes están en un CRM y las cotizaciones salen de un Excel que solo entiende una persona de la oficina. Un día pruebas ChatGPT o Claude, te gusta, y se te ocurre lo obvio: “¿y si le pudiera preguntar directo cuántas balatas me quedan?”.

Hasta hace poco la respuesta honesta era: se puede, pero alguien tiene que programar esa conexión. A mano. Para ese asistente en específico. Y si mañana cambias de asistente, vuelta a empezar.

De eso se trata MCP. Suena a sigla de ingenieros (lo es), pero la idea de fondo se entiende en cinco minutos.

El problema de conectar cada IA con cada sistema

Piensa en cuántas aplicaciones de IA hay hoy: asistentes de chat, editores de código, agentes metidos dentro de otros programas. Ahora piensa en cuántos sistemas tiene una empresa normal: ERP, CRM, base de datos, carpetas compartidas, correo, facturación. Si cada asistente necesita su propia integración con cada sistema, las conexiones se multiplican. Entre ingenieros le decimos un problema de “M por N”.

En la práctica eso se traducía en integraciones hechas a la medida, frágiles, que se rompían cuando alguien actualizaba una API y que nadie quería mantener. La neta, mucha de la “IA conectada a tu negocio” que se vendía hace un par de años era eso: un script pegado con cinta.

MCP propone otra cosa. Un idioma común. Si tu sistema habla MCP una vez, cualquier aplicación de IA que también lo hable se puede conectar sin reescribir la integración.

Qué es MCP, entonces

MCP significa Model Context Protocol. La documentación oficial lo describe como un estándar de código abierto para conectar aplicaciones de IA con sistemas externos: fuentes de datos (archivos locales, bases de datos), herramientas (un buscador, una calculadora) y flujos de trabajo.

Y usan una comparación que, por una vez, sí ayuda: piensa en MCP como un puerto USB-C para aplicaciones de IA. Igual que el USB-C te deja conectar el cargador, el disco duro o el monitor con el mismo tipo de cable, MCP da una forma estándar de conectar la IA con lo que sea que tenga tus datos.

Ojo con estirar la analogía de más. El USB-C no decide qué hace el aparato que conectas, y MCP tampoco decide qué hace la IA con la información. Es el conector, no el cerebro. La propia documentación lo aclara: el protocolo se enfoca solo en cómo se intercambia el contexto y no dicta cómo la aplicación usa el modelo de lenguaje ni cómo maneja lo que recibe.

De dónde salió y quién lo controla hoy

Lo publicó Anthropic (la empresa detrás de Claude) como proyecto de código abierto el 25 de noviembre de 2024. El anuncio incluía la especificación con sus SDKs, soporte para servidores locales en la app de escritorio de Claude y un repositorio con servidores ya hechos para Google Drive, Slack, GitHub, Git, Postgres y Puppeteer. Como primeros en adoptarlo mencionaron a Block y Apollo, y a herramientas de desarrollo como Zed, Replit, Codeium y Sourcegraph.

Lo interesante vino un año después. El 9 de diciembre de 2025 Anthropic donó MCP a la Agentic AI Foundation (AAIF), un fondo dirigido dentro de la Linux Foundation, que es la organización que cuida proyectos como el kernel de Linux, Kubernetes o Node.js. La AAIF la cofundaron Anthropic, Block y OpenAI, con el apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg.

¿Por qué te debería importar esto si no eres programador? Porque un estándar que controla una sola empresa es un riesgo: si mañana cambia de rumbo, te quedas colgado. Uno que vive en una fundación neutral, con competidores directos sentados en la misma mesa, es una base bastante más segura para construir encima.

La adopción ya es real, además. En ese mismo anuncio Anthropic reportó más de 10,000 servidores MCP públicos activos y dijo que ChatGPT, Cursor, Gemini, Microsoft Copilot y Visual Studio Code lo habían adoptado. OpenAI, por su parte, documenta cómo conectar servidores MCP tanto en ChatGPT como en su API.

Las piezas: host, cliente y servidor

Aquí se pone un poquito técnico, pero vale la pena, porque estos nombres te los van a mencionar en cualquier propuesta.

• Host: la aplicación de IA que usas. La documentación pone como ejemplos a Claude Desktop, Claude Code o Visual Studio Code. Es la que coordina todo.
• Cliente: un componente dentro del host que mantiene la conexión con un servidor específico. El host crea un cliente por cada servidor al que se conecta.
• Servidor: el programa que pone a disposición tus datos o acciones. Puede ser el de tu CRM, el de tu base de datos o uno hecho a la medida para tu sistema. Puede correr en tu computadora o en internet.

El ejemplo de la documentación: si en VS Code conectas el servidor de Sentry y el de tu sistema de archivos, VS Code (el host) crea dos clientes, uno para cada servidor. Cada conexión va por su lado.

De las tres, la que más le importa a un dueño de negocio es el servidor. Ahí decides qué puede ver y qué puede hacer la IA. Si el servidor no expone algo, la IA simplemente no lo tiene a su alcance. Eso, bien usado, es una ventaja enorme.

¿Qué puede ofrecer un servidor?

La especificación define tres cosas básicas que un servidor puede exponer. Les llaman primitivas.

Las herramientas (tools) son acciones: funciones que el modelo puede ejecutar, como consultar una base de datos, llamar una API o crear un registro. Son las que hacen que un asistente pase de platicar a hacer cosas, y por lo mismo son las que hay que cuidar más.

Los recursos (resources) son datos de contexto: el contenido de un archivo, registros de una base de datos, la respuesta de una API. Información para leer, no para actuar.

Los prompts son plantillas reutilizables para estructurar la interacción con el modelo. Piensa en un “arma una cotización” que ya trae los pasos y el formato que usa tu empresa.

La documentación da un ejemplo que se entiende bien: un servidor de base de datos puede ofrecer herramientas para hacer consultas, un recurso con el esquema de la base y un prompt con ejemplos de cómo usar esas herramientas. Las tres juntas.

Del otro lado, el cliente también le puede ofrecer cosas al servidor. La más útil para un negocio se llama elicitation: el servidor le pide al usuario información adicional o la confirmación de una acción antes de seguir. (En la versión más reciente de la especificación, otra función del cliente llamada sampling quedó marcada como obsoleta, por si alguien te la presenta como novedad.)

Local o remoto: cómo viajan los mensajes

Por debajo, MCP usa mensajes JSON-RPC 2.0. No necesitas saber qué es eso. Lo que sí conviene entender es que hay dos formas de transportar esos mensajes, y cada una tiene implicaciones distintas.

La primera es stdio (entrada y salida estándar). El servidor corre en la misma computadora que la aplicación de IA, como un proceso local. No pasa por la red y normalmente atiende a un solo cliente. Sirve, por ejemplo, para que un asistente lea carpetas de tu equipo.

La segunda se llama Streamable HTTP. El servidor vive en internet o en tu red, recibe peticiones HTTP y puede atender a muchos clientes. Es lo que usan los servicios que ofrecen su propio servidor MCP remoto, y lo que querrías para que todo un equipo use la misma conexión. Aquí entra la autenticación, y la documentación recomienda OAuth para obtener los permisos.

Mi recomendación práctica: para pruebas personales, local. Para algo que va a usar tu equipo con datos reales, remoto y con autenticación bien hecha. Lo desarrollo más en MCP para empresas, con casos de uso y el tema de seguridad a fondo.

¿Ya puedo conectar la IA a todo?

Cada vez más, sí. Hay servidores ya hechos para muchas herramientas populares y el ecosistema crece rápido. Pero conviene separar dos situaciones.

Si tu negocio corre sobre software comercial conocido, es probable que ya exista un servidor MCP, oficial o de la comunidad. Revisa quién lo publica antes de instalarlo. OpenAI, por ejemplo, recomienda preferir los servidores oficiales del proveedor del servicio y no conectarte a uno si no conoces y confías en la aplicación que hay detrás.

Si corre sobre software propio o algo muy de nicho, nadie te va a regalar ese servidor. Hay que construirlo. Lo bueno es que existen SDKs oficiales y un servidor bien diseñado suele ser una capa delgada sobre tu sistema, no un proyecto gigante. Es justo el tipo de trabajo que hacemos en agentes a la medida.

Y si todavía no tienes claro si te conviene un servidor MCP, una integración directa con la API de un modelo o algo más sencillo, échale un ojo a cómo integrar IA en tu software antes de decidir. No todo necesita MCP.

MCP no es magia. Es plomería. Pero es buena plomería, y por primera vez es la misma para todos.