MCP (Model Context Protocol)

Definición

MCP (Model Context Protocol) es un protocolo abierto creado por Anthropic y publicado en noviembre de 2024 que estandariza cómo los modelos de IA se conectan a herramientas externas, fuentes de datos y entornos. Es, en esencia, el USB-C de los LLMs: un mismo "conector" estandarizado por el que cualquier herramienta puede enchufarse a cualquier cliente compatible.

Antes de MCP, conectar un LLM a herramientas requería implementaciones custom por cada combinación cliente-herramienta. Cursor tenía su forma de definir tools, Claude Desktop la suya, ChatGPT la suya, agents internos cada uno reinventaba la rueda. MCP propone un protocolo común: las herramientas se exponen como servidores MCP, y cualquier cliente MCP (Claude Desktop, Cursor, Zed, agents custom, etc.) los puede consumir.

A 2026 la adopción es muy amplia: Anthropic Claude Code, Cursor, Zed, Continue, Sourcegraph Cody, Replit, Goose y decenas de IDEs y agents soportan MCP nativamente. Los servidores MCP públicos cubren GitHub, Slack, GDrive, Notion, Postgres, Sentry, Figma, Linear y muchísimos más.

Cómo funciona

MCP es un protocolo cliente-servidor sobre JSON-RPC. Tres conceptos clave:

1. Server MCP: un proceso que expone capacidades (tools, resources, prompts) a clientes. Puede ser un script local, un binario, un servicio remoto.

2. Cliente MCP: la aplicación que quiere usar esas capacidades, normalmente un IDE o agent (Claude Code, Cursor). Se conecta al servidor por stdio, HTTP o SSE.

3. Tres tipos de capacidades que un servidor MCP puede ofrecer:

   • Tools: funciones que el LLM puede invocar (similar a function calling clásico). Ej: create_github_issue, run_sql_query.
   • Resources: contenido que el cliente puede leer y dar al modelo como contexto. Ej: contenido de archivos, registros de DB, snippets.
   • Prompts: plantillas de prompts que el cliente puede ofrecer al usuario como atajos. Ej: "/review-pr", "/summarize-document".

El cliente descubre dinámicamente qué ofrece cada servidor conectado, y el LLM puede usar tools/resources de cualquiera de ellos según necesite.

Ejemplo práctico

Imagina configurar Claude Code para que ayude con un proyecto de AE Works. Sin MCP, cada integración era custom. Con MCP, basta añadir servidores en la configuración:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_xxx" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgres://localhost/aeworks"]
    },
    "notion": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-notion"],
      "env": { "NOTION_API_KEY": "secret_xxx" }
    }
  }
}

Resultado: en una sola conversación con Claude Code, el modelo puede:

• Leer issues abiertos en GitHub.
• Consultar la base de datos del proyecto.
• Leer documentación en Notion.
• Crear PRs, ejecutar SQL, actualizar tareas.

Todo de forma transparente. Cuando pides "revisa el ticket 1234 y dime si la query SQL en él es correcta", Claude:

1. Llama al servidor GitHub MCP → obtiene el ticket.
2. Llama al servidor Postgres MCP → ejecuta la query en sandbox.
3. Compara, razona, responde con análisis.

Y como MCP es un estándar, el mismo set de servidores funciona en Claude Code, Cursor, Zed... sin reescribir nada.

Por qué fue necesario

Antes de MCP, el ecosistema de agents tenía un problema crónico de fragmentación:

• Cada IDE o agent definía su propio formato de tools (OpenAI functions, Anthropic tools, custom).
• Cada integración (GitHub, Slack, Notion) había que reimplementarla por cada cliente.
• Imposible compartir tools entre productos.
• Los desarrolladores de tools tenían que mantener N implementaciones.

MCP propone resolver esto como lo resolvieron LSP (Language Server Protocol) en IDEs, o USB en hardware: un protocolo abierto que todos implementan una vez.

Servidores MCP populares a 2026

El ecosistema crece rápido. Algunos servidores típicos:

• Desarrollo: GitHub, GitLab, Sentry, PagerDuty, Sourcegraph.
• Datos: Postgres, MySQL, MongoDB, SQLite, BigQuery.
• Productividad: Notion, Google Drive, Slack, Linear, Asana.
• Cloud: AWS, Cloudflare, Vercel.
• Personal: Filesystem local, navegador, calendar.

Además de los oficiales, hay miles de comunidad. Y crear uno propio es manejable: hay SDKs en TypeScript, Python, Go, Rust.

Diferencia con function calling clásico

Function calling sigue siendo el mecanismo subyacente (cuando MCP "expone una tool" al LLM, técnicamente se usa function calling). MCP es una capa por encima que estandariza cómo se proveen y se descubren esas tools.

Errores comunes al hablar de MCP

• Confundir MCP con tools genéricas: MCP es un protocolo específico. No todo "tool calling" es MCP.
• Pensar que sustituye function calling: lo complementa. MCP usa function calling por debajo.
• Asumir que es solo para Anthropic: aunque lo creó Anthropic, es abierto y adoptado en todo el ecosistema.
• Esperar magia de seguridad: MCP no resuelve seguridad por sí solo. Tu servidor MCP debe gestionar autenticación, autorización, validación.
• Crear servidores MCP demasiado granulares o genéricos: el equilibrio es complicado. Tools claras > tools "do everything".
• No considerar el coste de tokens: cada servidor MCP añade tokens al contexto (descripciones de tools). 10 servidores con 20 tools cada uno = mucho overhead.
• Mezclar muchos servidores sin orquestar: el modelo puede saturarse con cientos de tools. Filtra/agrupa dinámicamente.

Cuándo usar MCP

Sí, integra MCP cuando:

• Construyes agents IA serios sobre múltiples sistemas.
• Quieres que tus tools sean reutilizables en distintos clientes (Claude Code, Cursor, otros).
• Operas en un ecosistema donde hay servidores MCP existentes que te valen out-of-the-box.
• Eres consumidor de IDEs/agents que soportan MCP (Claude Code, Cursor, Zed).

Es menos crítico si:

• Tu producto es propietario y cerrado, sin necesidad de interoperabilidad.
• Function calling clásico de tu proveedor te cubre y no necesitas cross-cliente.
• Tu integración es muy simple y MCP añade overhead innecesario.

El futuro probable

MCP a 2026 está donde LSP estaba en 2018: adopción amplia, ecosistema en construcción, estándar de facto. Apuestas razonables:

• Más clientes: prácticamente todos los IDEs serios soportarán MCP.
• Más servidores oficiales: cada SaaS importante tendrá su servidor MCP.
• Servidores enterprise gestionados: con auth, audit logs, governance.
• MCP en producción server-side: no solo desktop, también backends de agents.
• Iteraciones del protocolo: capabilities nuevas (sampling, notifications, multimodal).

Referencias

• Model Context Protocol · Sitio oficial — documentación y especificación oficial
• Anthropic · Announcing MCP — el anuncio fundacional
• Awesome MCP Servers (GitHub) — directorio de servidores MCP de la comunidad