Model Context Protocol (MCP) explicado: el estándar que conecta LLMs con todo

En noviembre de 2024, Anthropic publicó la primera versión de Model Context Protocol (MCP) como especificación abierta. En 18 meses ha pasado de ser un experimento a convertirse en el estándar que adopta Anthropic, OpenAI, Microsoft y Google para conectar LLMs con herramientas externas.

Si llevas meses viendo "MCP" en release notes y no tienes claro qué es exactamente, qué resuelve y por qué debería importarte, este artículo lo pone a nivel técnico pero accesible.

En 30 segundos:

MCP es un protocolo abierto que estandariza cómo un LLM descubre y usa herramientas externas (llamadas a APIs, lectura de archivos, ejecución de consultas, autenticación OAuth). Es a los LLMs lo que USB fue a los periféricos: un único cable para todo.

Lo que cubro:

1. Por qué MCP existe (el problema real antes de 2024).

2. Arquitectura: host, cliente, servidor, primitivas (tools, resources, prompts).

3. MCP vs function calling vs APIs REST vs plugins.

4. Transports: stdio, SSE, HTTP streamable.

5. Quién lo adopta en 2026 y cuál es el estado real.

6. Qué significa para developers, empresas y usuarios finales.

Por qué existe MCP: el problema antes de 2024

Function calling fue el primer intento de conectar LLMs con herramientas. OpenAI lo popularizó en 2023: el modelo emite una llamada estructurada (function_name(arg1, arg2)), tú la ejecutas en tu código y le devuelves el resultado. Funciona. Pero tiene tres problemas que solo se ven al construir algo serio:

Problema 1: cada integración es custom. Si quieres que Claude lea de Notion y que GPT-4 también lea de Notion, escribes el glue code dos veces. Cada herramienta y cada LLM se pegan con cinta adhesiva específica.

Problema 2: el LLM no descubre lo que puedes hacer. El modelo ve las funciones que tú le pongas en el system prompt. No hay forma estándar de que el LLM pregunte "¿qué más hay disponible?", ni de que una herramienta publique sus capacidades para ser autodescubierta.

Problema 3: no hay portabilidad. Los plugins de ChatGPT, los tools de Claude.ai, las skills de Cowork… cada proveedor inventó su formato. Un "plugin ChatGPT" no funciona en Claude. Querías mover a tu equipo de un modelo a otro y tenías que reescribir todas las integraciones.

MCP resuelve los tres. Define un protocolo estándar tal que cualquier herramienta se conecta a cualquier cliente con cualquier LLM. Escribes el servidor MCP de Gmail una vez; funciona en Claude Desktop, en GPT Enterprise, en Gemini, en Levante y en cualquier cliente que implemente MCP.

La analogía "USB para LLMs" no es marketing. Es literalmente el mismo patrón: una spec pública, cualquiera puede fabricar un periférico (servidor) y cualquiera puede fabricar un host (cliente) que lo consuma.

La arquitectura MCP

Tres piezas. Distinguirlas bien es la diferencia entre entender MCP y seguir confundido.

Host

La aplicación de usuario: Claude Desktop, Cursor, Zed, Levante, ChatGPT Enterprise. El host tiene la UI, gestiona las conversaciones, controla qué LLM se usa y aplica las políticas de seguridad (permisos, sandboxing).

Cliente MCP

El componente dentro del host que implementa el protocolo. Se encarga del handshake con el servidor, descubrimiento de capabilities, envío de tool calls y recepción de respuestas. Un host puede tener varios clientes MCP abiertos a la vez (uno por cada servidor que conectes).

En la conversación informal "cliente MCP" se usa como sinónimo de "app que soporta MCP". Es abuso útil de lenguaje: cuando alguien pregunta "¿qué clientes MCP hay?", normalmente pregunta por apps. Si esa distinción te interesa, la desarrollo en qué es un cliente MCP.

Servidor MCP

El proceso que expone capacidades. Un servidor puede vivir localmente (proceso que lanza el host vía stdio) o remoto (endpoint HTTP al que el host se conecta). Ejemplos:

• filesystem: expone tools para leer/escribir/listar archivos en una ruta.

• gmail: expone tools list_emails, send_email, search.

• github: expone tools para issues, PRs, branches.

• postgres: expone resources (schemas, tables) y tools (ejecutar queries).

Cada servidor declara qué expone al conectarse, el cliente cachea esa lista y el LLM la ve como parte de sus herramientas disponibles.

Las tres primitivas: tools, resources, prompts

Un servidor MCP puede exponer tres tipos de capabilities:

Tools

Son funciones que el LLM puede invocar. Cada tool tiene nombre, descripción, schema de parámetros JSON. El modelo decide cuándo y con qué argumentos llamarla. Las tools pueden tener efectos laterales: mandar un email, crear un ticket, ejecutar código.

Ejemplo abstracto:

Tool: send_email
Description: Envía un email desde la cuenta autorizada
Parameters:
  to: string (email del destinatario)
  subject: string
  body: string
Returns: {id: string, sent_at: timestamp}

Las tools son el 80% de lo que usan los MCPs en la práctica.

Resources

Son datos que el LLM puede leer. A diferencia de tools, resources son declarativos: el servidor publica una URI (gmail://inbox/123) y el cliente la recupera cuando el LLM la cita. Pensado para documentos, snippets, contenido consultable.

Ejemplo: un servidor Notion expone cada página como un resource. El LLM puede referenciar notion://page/abc123 y el cliente devuelve el contenido.

En la práctica, la adopción de resources ha sido más lenta que la de tools porque muchos servidores modelan "lectura" como una tool (get_page) en vez de como resource. Es legítimo: las dos formas funcionan.

Prompts

Son plantillas reutilizables. Un servidor puede publicar prompts predefinidos ("resume estos emails", "genera un informe con estos datos") que el usuario invoca desde el cliente (típicamente con un / command). Útil para flujos repetitivos.

Adopción: moderada. Los prompts son la primitiva menos usada, pero ganan tracción en clientes con UX tipo command palette.

MCP vs function calling vs APIs REST vs plugins

Esta es la comparativa que todo el mundo necesita y pocos explican bien. Cada uno resuelve un problema distinto:

REST API: óptimo para comunicación máquina-a-máquina (un backend llama a otro). No pensada para que un LLM descubra y use tools. Cuando quieres que un LLM use una REST API, tienes que envolverla en function calling o MCP.

Function calling: el mecanismo primitivo por el que el LLM emite una llamada estructurada. MCP usa function calling por debajo: el cliente convierte una tool MCP en un function definition para el LLM. La diferencia es que function calling por sí solo no resuelve portabilidad ni descubrimiento estandarizado.

Plugins cerrados: cada uno era un ecosistema vendor. ChatGPT plugins funcionaban solo en ChatGPT. Ya casi nadie los mantiene.

MCP: la capa que estandariza "cómo un LLM habla con herramientas externas" independientemente del modelo, del host y del servidor. Resuelve el 100% de lo que los plugins propietarios intentaron.

La regla práctica:

• Código habla con código → REST/gRPC.

• LLM en una app → tool → function calling.

• LLM en cualquier app → cualquier tool → MCP.

Los transports de MCP

Un servidor MCP y un cliente MCP se comunican por un transport. En 2026 hay tres opciones:

stdio

El cliente lanza el servidor como proceso local y se comunican por stdin/stdout. Es el transport más común y el más simple de auditar: el servidor corre en tu máquina, los datos no salen de ella, no hay network en medio.

Ejemplo mental: el host lanza npx @gongrzhe/server-gmail-autoauth-mcp, captura su stdout y le escribe requests JSON por stdin. Igual que un shell pipe.

Pros: simple, local, auditable, sin latencia de red.
Contras: el servidor tiene que poder instalarse y ejecutarse en la máquina del usuario. No sirve para servidores que realmente tengan que vivir en un servicio remoto.

SSE (Server-Sent Events)

El servidor expone un endpoint HTTP; el cliente abre una conexión persistente de eventos server-to-client y envía requests por HTTP POST paralelo. Era el primer transport "remoto" de MCP en 2024-2025.

Pros: permite servidores remotos (SaaS), compatible con infra HTTP estándar.
Contras: dos canales (POST + SSE) añade complejidad.

HTTP streamable (nueva spec 2025-03)

Substituye a SSE unificando el transport en HTTP con streaming bidireccional. Es el presente-futuro del transport remoto para MCP.

Pros: un solo canal, más simple, compatible con balanceadores.
Contras: aún no todos los servidores se han migrado; convivirá con SSE durante 2026.

Cuándo elegir cada uno

• Servidor pensado para correr local → stdio.

• Servidor hospedado como SaaS → HTTP streamable (o SSE si es legacy).

• No te decidas tú: la inmensa mayoría de servidores en catálogos como el MCP Store de Levante eligen el transport adecuado según su naturaleza. Tú instalas, el cliente se encarga.

El ciclo de vida de una conexión MCP

Para tener una intuición técnica de qué pasa bajo el capó:

1. Handshake: el cliente conecta con el servidor y ambos intercambian la versión de spec (initialize request). Si no son compatibles, cortan.

2. Negociación de capabilities: el servidor declara qué tools, resources y prompts expone. El cliente los cachea.

3. Registration en el LLM: el host toma las tools expuestas y las inyecta como functions disponibles para el LLM en su system prompt o API call.

4. Invocación: el LLM emite un tool call. El cliente lo enruta al servidor correspondiente vía el transport.

5. Ejecución: el servidor ejecuta (llama a la API real, lee un fichero, ejecuta SQL) y responde.

6. Return al LLM: el cliente devuelve el resultado al LLM, que genera la respuesta final para el usuario.

7. Close: cuando se cierra la sesión, cliente y servidor desconectan limpio.

En un cliente robusto, los pasos 4-6 se repiten decenas de veces durante una conversación con agente. Cada tool call son unos milisegundos si es stdio, cientos de milisegundos si es HTTP remoto.

Qué adoptan los principales proveedores en 2026

La señal más importante de adopción no son las declaraciones de marketing; es qué realmente soportan los productos.

Anthropic

Inventor. Soporte completo en Claude Desktop, Claude Code y Claude API (vía tools + gateway MCP remoto). Publican su spec oficialmente. Primer productor y primer implementador.

OpenAI

Integración oficial en ChatGPT Enterprise (MCP remoto) y en su API de responses. Han publicado SDKs oficiales para TypeScript y Python. Han adoptado la spec upstream sin fork.

Microsoft

Copilot Studio integra MCP como extensión de capacidades. Azure AI Foundry lo soporta en agents. Visual Studio Code ha añadido MCP en sus extensiones de Copilot.

Google

Gemini CLI y Gemini Code Assist soportan MCP desde 2025. Adoption en Vertex AI anunciada en agentes gestionados.

Mistral, Cohere, otros

Soporte creciente pero no unificado. Muchos llegan vía los SDKs estándar de TypeScript/Python.

Ecosistema open-source

Donde MCP vive más fuerte. Clientes open-source (Levante, Cherry Studio, Jan AI, Cline, Zed) y cientos de servidores publicados por la comunidad. En 2026 hay catálogos con 800-1.200 servidores (Smithery, Glama, MCP Store de Levante, Composio).

Señal clave: todos los grandes lo adoptaron sin forkearlo. En tech, cuando cuatro vendors dominantes implementan la misma spec upstream, ha ganado.

Qué significa para distintos perfiles

Para developers

Si construyes agentes o apps con LLMs, MCP es la capa por la que deberías diseñar tus integraciones externas. Tres beneficios concretos:

• Un servidor, múltiples hosts: construyes servidor MCP interno y tu equipo lo usa desde Claude Desktop, Cursor, Levante o lo que prefieran.

• Ecosistema pre-built: cientos de servidores listos para Gmail, Slack, GitHub, Notion, Stripe, AWS… sin reinventar.

• Portabilidad futura: el día que cambies de modelo (Claude → GPT → Gemini), no tocas las integraciones.

Construir un servidor MCP básico son menos de 100 líneas con los SDKs oficiales (Python o TypeScript). Documentación oficial en modelcontextprotocol.io.

Para empresas

Tres cosas cambian cuando MCP es tu layer de integración:

• Gobernanza: puedes aprobar qué servidores MCP usa tu equipo centralmente (en lugar de 10 empleados con 10 configs distintos). Levante Platform introduce MCP Control con esa responsabilidad.

• Auditoría: cada tool call es una operación trazable. En entornos regulados (finanzas, salud, sector público), esto es obligatorio. En IA y RGPD para empresas desarrollo por qué la auditoría granular es parte del cumplimiento.

• Vendor-agnostic: si hoy construyes sobre OpenAI y mañana quieres mover a Claude por privacidad, no rehaces el stack de integraciones. MCP aísla esa decisión.

Para usuarios finales

Si no eres developer pero usas apps de IA, MCP significa que cada vez que ves "conectar con Gmail" o "integrar con Notion" en una app de IA, por debajo es probable que haya un servidor MCP. Concretamente: la experiencia de decirle a tu IA "lee mis últimos emails y hazme un resumen" pasa por un servidor MCP. Tú no lo ves, pero es lo que hace que funcione sin que cada app reinvente la integración.

Y para ti cambia una cosa práctica: puedes cambiar de app (Claude Desktop → Levante → Cursor) y llevarte las mismas integraciones contigo.

Limitaciones honestas de MCP en 2026

Para no sonar a brochure, dónde MCP no es perfecto todavía:

• Discovery entre servidores no está resuelto. El cliente descubre lo que le conectas, pero no hay un "buscar todos los servidores MCP públicos" estandarizado en el propio protocolo. Los catálogos (Smithery, Glama, Levante MCP Store) cubren ese hueco externamente.

• Permisos granulares todavía son del host. La spec define capabilities pero las políticas de "esto sí, esto no" las aplica el host. Hosts serios lo hacen; los menos maduros no.

• Streaming de respuestas largas: la spec lo soporta pero no todos los servidores lo implementan. Usar MCP para un servidor que devuelve PDFs de 100MB puede ser frustrante.

• Spec todavía evoluciona. 2024-11 → 2025-03 → 2025-11 → 2026-03. La buena noticia es que hay process público; la otra noticia es que servidores mal mantenidos se quedan en versiones antiguas.

Nada bloqueante. El protocolo es suficientemente maduro para producción, con los matices que se esperan de algo con 18 meses de vida y adopción masiva.

Preguntas frecuentes

¿MCP es una API?

No exactamente. MCP es un protocolo: define cómo cliente y servidor negocian capacidades y se comunican. Las APIs REST tienen endpoints fijos; MCP tiene descubrimiento dinámico. Se parecen en que ambos son contratos entre software, pero MCP está diseñado específicamente para consumo por LLM.

¿Necesito saber MCP para usar una IA como Claude o ChatGPT?

No para uso básico. Si usas ChatGPT o Claude en el navegador, estás consumiendo features que internamente pueden usar MCP sin que tú lo veas. Si construyes con LLMs o usas un cliente desktop con integraciones (Claude Desktop, Levante), entender MCP te ahorra mucho tiempo.

¿Cuánto tarda aprender MCP?

Leer la spec completa: 2-3 horas. Entender conceptos (host/cliente/servidor, transports, primitivas): 1 hora. Construir tu primer servidor MCP con el SDK oficial: una tarde. Dominar casos avanzados (permisos, streaming, resources dinámicos): semanas de práctica.

¿MCP va a sustituir function calling?

No. MCP usa function calling por debajo. Function calling seguirá existiendo como mecanismo primitivo por el que el LLM emite una llamada. MCP es la capa por encima que estandariza de dónde vienen esas funciones y cómo se comunican.

¿MCP funciona offline?

Depende del servidor. Un servidor MCP de filesystem es 100% local. Un servidor MCP de Gmail obviamente necesita conexión a Google. El protocolo en sí no exige network; los servidores sí, según lo que hagan.

¿Puedo usar MCP en producción?

Sí, ya se usa en producción a escala. Anthropic, OpenAI, Microsoft y muchas startups lo tienen corriendo en productos live. Las empresas con requisitos de cumplimiento lo despliegan con gobernanza centralizada (ver Levante Platform).

¿MCP es seguro?

Tan seguro como el host + el servidor que uses. El protocolo en sí no te protege: si instalas un servidor MCP malicioso, puede hacer daño (borrar archivos, exfiltrar datos). Los hosts serios piden confirmación para tools peligrosas y guardan secrets en keychain del sistema. Un Store curado reduce el riesgo de instalar basura.

¿MCP tiene competidor?

Hay propuestas menores (algunos intentos de OpenAI pre-adopción, plugins específicos de vendors) pero ninguna con tracción comparable. A 2026 es el estándar de facto. La presión en contra solo vendría si Anthropic hiciese algo muy raro con la governance; hasta ahora el proceso es público y abierto.

¿Dónde encuentro servidores MCP listos para usar?

Catálogos principales: MCP Store de Levante (integrado en cliente desktop), Smithery, Glama, Composio. Lo desarrollo en MCP Store: qué es y cómo elegir servidores MCP.

¿Cómo construyo mi propio servidor MCP?

Instala el SDK oficial (pip install mcp o npm install @modelcontextprotocol/sdk), define tus tools como funciones Python/TypeScript y el SDK se encarga del protocolo. Un servidor básico son menos de 100 líneas. Documentación en modelcontextprotocol.io.

Conclusión

Model Context Protocol resolvió un problema real que bloqueaba la escalabilidad de agentes con LLMs: cómo conectar cualquier modelo con cualquier herramienta sin reescribir glue code cada vez. En 2026 lo adoptan todos los proveedores relevantes, tiene catálogos con cientos de servidores y SDKs maduros.

Para developers, es la capa por la que diseñar integraciones externas. Para empresas, la base para gobernar el uso de IA a escala. Para usuarios finales, lo que hace que las apps de IA "simplemente funcionen" con sus herramientas.

Si quieres dar el siguiente paso concreto: prueba el MCP Store en Levante para ver MCP en acción sin configurar nada, o lee qué es un cliente MCP si quieres profundizar en el lado del host. Si construyes para empresa, Levante Platform añade la capa de gobernanza que la spec sola no da.

MCP no se va a ningún sitio. Construye asumiendo que lo tendrás ahí los próximos cinco años.