4Geeks chosen to deliver AI education in the Bahamas alongside Harvard, Oxford, and Columbia.See more
8 min read

Qué es un MCP (Model Context Protocol) y cómo funciona

Qué es un MCP: el protocolo abierto de Anthropic que conecta apps de IA con herramientas y datos. Diferencia con una API, cómo crear uno y cómo lo usamos en 4Geeks.

¿Qué es un MCP? MCP (Model Context Protocol, o Protocolo de Contexto de Modelo) es el protocolo abierto que Anthropic publicó en noviembre de 2024 para conectar aplicaciones de IA con herramientas y datos. Gracias a él, un asistente como Claude o ChatGPT puede leer tus archivos, consultar una base de datos o enviar un correo sin que alguien programe una integración distinta para cada caso.

Un aviso antes de seguir: aquí hablamos de inteligencia artificial. Si buscabas MCP en medicina (la articulación metacarpofalángica, en la base de los dedos), es otro tema.

La documentación oficial lo compara con un puerto USB-C para aplicaciones de IA. USB-C es un solo conector para muchos aparatos. MCP es una sola forma de conectar cualquier app de IA compatible con cualquier sistema preparado para él.

¿Quién está detrás de MCP?

Anthropic, la empresa que crea Claude, lo presentó el 25 de noviembre de 2024 como un estándar abierto. El 9 de diciembre de 2025 lo donó a la Agentic AI Foundation, un fondo de la Linux Foundation que cofundaron Anthropic, Block y OpenAI.

Hoy no es cosa de una sola empresa. Según Anthropic, en esa fecha ya había más de 10.000 servidores MCP públicos activos. Lo habían adoptado ChatGPT, Cursor, Gemini, Microsoft Copilot y Visual Studio Code, entre otros.

¿Para qué sirve un MCP?

Piensa en un agente de IA, un asistente que no solo responde sino que también hace cosas por ti. Para actuar necesita entrar en otros sistemas: tu correo, tu calendario, tu base de datos.

Antes de MCP, cada conexión era un trabajo a medida. Diez sistemas y cinco aplicaciones de IA daban cincuenta integraciones distintas. Y cada una se podía romper con cualquier cambio.

MCP reduce eso a un solo trabajo por sistema. Lo describes una vez, siguiendo el protocolo, y cualquier aplicación compatible puede usarlo.

MCP, cliente y servidor MCP: no son lo mismo

Vas a ver tres palabras juntas, así que conviene separarlas.

  • MCP es el protocolo: las reglas de cómo se hablan dos programas.
  • Un servidor MCP es el programa que aplica esas reglas para ofrecer un sistema concreto, como tu calendario o tu base de datos.
  • Un cliente MCP es la aplicación de IA que se conecta a ese servidor, como Claude, ChatGPT o Cursor.

Un servidor MCP ofrece tres tipos de cosas que el modelo lee directamente:

  • Herramientas: acciones con nombre, una descripción en lenguaje claro y la lista exacta de datos que esperan.
  • Recursos: datos que el agente puede leer, como un archivo o una tabla.
  • Prompts: plantillas de instrucciones que el servidor pone a disposición del cliente.

¿Cuál es la diferencia entre una API y un MCP?

Es la duda más común, y tiene sentido, porque un servidor MCP muchas veces se apoya en una API por dentro.

Una API (interfaz de programación de aplicaciones) es una puerta para que un programa pida datos o acciones a otro. Pero está pensada para personas que programan. Da por hecho que quien la usa ya leyó la documentación y sabe qué llamar, en qué orden y qué hacer si algo falla.

Un MCP está pensado para que lo lea el modelo de IA. Cada herramienta trae una descripción que el modelo usa para decidir si la llama, con qué datos y qué hacer con el resultado. Y el protocolo es el mismo para todos los servidores, así que el agente no tiene que aprender un formato nuevo cada vez.

APIMCP
Quién la leeUna persona que programaEl modelo de IA
Cómo se conecta un agente nuevoCon una integración a medidaCon la misma conexión estándar
Dónde viven las instrucciones de usoEn la documentación o en tu códigoEn la descripción de cada herramienta
FormatoCambia de un proveedor a otroUn protocolo abierto y común

Dicho de forma simple: la API es el motor y el MCP es el tablero que el agente sabe leer. No se reemplazan, se complementan.

¿Cómo se crea un MCP?

Lo que creas es un servidor MCP. Este es el ejemplo mínimo con el SDK oficial de Python, siguiendo la guía oficial para construir un servidor. Necesitas Python 3.10 o superior y el gestor de paquetes uv.

Paso 1. Crea el proyecto e instala el SDK.

bash
uv init saludos
cd saludos
uv add "mcp[cli]"

Paso 2. Escribe el servidor en un archivo saludos.py.

python
from mcp.server import MCPServer
 
mcp = MCPServer("saludos")
 
@mcp.tool()
def saludar(nombre: str):
    """Devuelve un saludo para la persona indicada."""
    return f"Hola, {nombre}. Te saluda tu primer servidor MCP."
 
if __name__ == "__main__":
    mcp.run(transport="stdio")

El SDK lee el nombre de la función, sus tipos y el texto entre comillas triples para crear la descripción que verá el modelo. Por eso esa frase importa tanto: es lo que el agente lee para decidir cuándo usar la herramienta.

Paso 3. Conéctalo a un cliente. En Claude Desktop, por ejemplo, añades el servidor en su archivo de configuración claude_desktop_config.json:

json
{
  "mcpServers": {
    "saludos": {
      "command": "uv",
      "args": ["--directory", "/RUTA/ABSOLUTA/A/saludos", "run", "saludos.py"]
    }
  }
}

Cómo comprobar que funciona: reinicia Claude Desktop y pídele que salude a alguien por su nombre. Debería usar la herramienta saludar y responder con el texto de tu función.

Hay SDKs oficiales para TypeScript, Python, C#, Go, Rust, Ruby, Java, Swift, PHP y Kotlin, según la página de SDKs del protocolo.

Del ejemplo mínimo a un servidor útil

Ese servidor funciona, pero es solo una función envuelta. El valor de un buen servidor MCP está en explicar cómo se relacionan sus herramientas.

Imagina tres: buscar_contacto, redactar_correo y enviar_correo. Si las expones sin más, el agente tiene que adivinar el orden y qué hacer si hay dos contactos con el mismo nombre. Mira cómo cambia si las descripciones lo dicen:

python
@mcp.tool()
def buscar_contacto(consulta: str):
    """Busca un contacto por nombre o correo. Si hay varias coincidencias,
    pide al usuario que elija una antes de llamar a redactar_correo."""
    ...
 
@mcp.tool()
def redactar_correo(contacto_id: str, intencion: str):
    """Crea un borrador y devuelve su borrador_id. Muestra el texto al
    usuario y llama a enviar_correo solo cuando lo apruebe."""
    ...
 
@mcp.tool()
def enviar_correo(borrador_id: str):
    """Envía un borrador ya aprobado. Si falla, vuelve a redactar_correo
    en lugar de reintentar."""
    ...

Son las mismas tres funciones. Pero ahora el orden, la aprobación y qué hacer ante un error viajan con el servidor. Cualquier agente que se conecte recibe esas reglas sin que tengas que escribirlas en su prompt.

Cómo llevamos el sitio de 4Geeks con un solo servidor MCP

En 4Geeks esto no es teoría. Nuestro sitio web lo mantienen agentes de IA conectados a un único servidor MCP, el de nuestro propio CMS (el sistema donde guardamos las páginas). Lo usan agentes de distintos proveedores, y todos reciben las mismas reglas del servidor.

Así funciona en la práctica:

  • La sesión empieza pidiendo las reglas. La primera llamada devuelve las normas vigentes del sitio. El agente no necesita traerlas aprendidas.
  • Cada respuesta indica el siguiente paso. Junto al resultado, el servidor dice qué herramienta conviene llamar después y con qué datos.
  • Nada se publica directamente. Un agente que escribe no cambia la página en vivo. Crea una propuesta con un borrador, y otro rol la revisa antes de publicarla.
  • El servidor frena errores. Antes de proponer un cambio, revisa si alguien editó la página hace poco. Y si un agente intenta trabajar algo que otro ya tiene en curso, el servidor lo rechaza y no deja duplicarlo.

Este mismo artículo pasó por ese circuito. Un agente de redacción lo propuso como borrador a través del servidor MCP. Se publica solo después de la revisión.

En septiembre de 2026 contamos los resultados de cinco días de ese sistema en nuestro artículo en inglés. Entre el 2 y el 6 de septiembre, los agentes resolvieron 229 problemas de validación en un sitio de 606 páginas activas. El servidor volvió a revisar cada uno y confirmó que había desaparecido. Diez se reabrieron después, un 4,4%.

Lo importante no son las cifras, sino dónde vive el conocimiento. Las reglas del sitio están en el servidor, no repartidas en las instrucciones de cada agente. Si una regla cambia, se cambia en un solo lugar.

Profundiza

¿Quieres aprender a construir agentes y servidores como estos con una ruta guiada? AI Flex te deja avanzar a tu ritmo, con un tutor de IA y mentorías 1:1. Mira cómo funciona y decide si encaja contigo.

Da el siguiente paso en tech

Compara nuestros programas y elige tu ruta.

Preguntas Frecuentes