El 25 de noviembre de 2024, Anthropic publicó Model Context Protocol (MCP), un estándar abierto para conectar modelos de lenguaje con fuentes de datos y herramientas externas. A primera vista puede parecer una especificación más dentro del catálogo de piezas alrededor de los LLMs, pero merece una lectura atenta. Lo que Anthropic propone no es un framework ni una librería: es un protocolo de interoperabilidad pensado para que cualquier cliente (Claude Desktop, un IDE, un agente propio) pueda hablar con cualquier servidor que exponga datos o acciones. MCP aspira a ser para el contexto lo que Language Server Protocol es para los editores de código.
El problema real que intenta resolver
Cualquiera que haya integrado un LLM en una aplicación seria reconoce el patrón. Conectar el modelo a la base de datos interna, al wiki, a Slack, a un repositorio de Git o al sistema de tickets implica escribir un adaptador a medida cada vez. El código que parsea resultados, inyecta contexto en el prompt, expone funciones invocables y gestiona errores termina duplicándose entre proyectos y proveedores. Conectar Claude a una base de datos requiere un puente. Conectar GPT-4 a la misma base requiere otro distinto. Y cada vez que cambia el modelo, el esquema o el formato de las funciones, el pegamento se rompe.
Esa fricción no es accidental: es la manifestación de una capa de integración que nunca se ha estandarizado. Si el servidor que expone la base de datos habla MCP y el cliente que aloja al modelo también, la integración deja de ser un proyecto y pasa a ser una configuración.
Arquitectura en una frase
MCP define dos roles. Los servidores exponen tres primitivas: recursos (datos legibles identificados por URI), herramientas (acciones invocables con parámetros) y prompts (plantillas reutilizables). Los clientes —aplicaciones que alojan al modelo— descubren esas primitivas por introspección, las presentan al LLM y ejecutan las llamadas que este decide realizar. La comunicación viaja sobre JSON-RPC 2.0 y puede transportarse por stdio, SSE sobre HTTP o WebSocket. El cliente no sabe nada del dominio del servidor: aprende lo que hay disponible preguntando al arrancar.
Un ejemplo mínimo en Python
El SDK oficial incluye una fachada llamada FastMCP que reduce la implementación de un servidor a unas pocas líneas. El siguiente fragmento define un servidor con una herramienta y un recurso, suficiente para que Claude Desktop lo detecte y lo use:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("demo")
@mcp.tool()
def add(a: int, b: int) -> int:
"""Suma dos números enteros."""
return a + b
@mcp.resource("config://app")
def get_config() -> str:
"""Devuelve la configuración activa."""
return "production"
mcp.run()El resto de la integración es declarativa. En el fichero claude_desktop_config.json se registra el servidor indicando el comando y los argumentos necesarios para lanzarlo, Claude Desktop lo arranca como subproceso mediante stdio al iniciar la aplicación, descubre las primitivas expuestas y las pone a disposición del modelo en cada conversación. No hay código específico del cliente: la misma definición de servidor funciona con cualquier aplicación que hable MCP.
En qué se diferencia del function calling
Aquí está la parte que no se suele explicar bien. Function calling, tal como lo implementan OpenAI, Anthropic y el resto de proveedores en sus APIs, es una característica del modelo: el LLM emite una respuesta estructurada que representa una llamada a función y la aplicación decide cómo ejecutarla. Es un contrato entre el modelo y el desarrollador de la aplicación, pero no dice nada sobre quién expone esas funciones ni cómo se descubren.
MCP opera un nivel por encima. No sustituye al function calling: lo complementa estandarizando el lado del servidor. Cuando un cliente MCP arranca, descubre las herramientas que ofrece un servidor, las traduce al formato de function calling que exige el modelo y enruta la invocación de vuelta al servidor cuando el LLM decide llamarla. El modelo sigue haciendo function calling como siempre; lo que cambia es que las herramientas ya no están acopladas al código del cliente. Se despliegan, se versionan y se reutilizan de forma independiente.
La diferencia con frameworks como LangChain o LlamaIndex es del mismo tipo. Esos frameworks definen herramientas dentro del proceso de la aplicación; MCP las saca fuera, las convierte en servicios con ciclo de vida propio y permite que varios clientes las compartan. No compiten: un agente construido con LangChain puede perfectamente consumir servidores MCP como una fuente más de herramientas.
Por qué importa como estándar
El valor de MCP no está en resolver un problema técnico inédito. Está en que estandariza la frontera correcta. Cuando aparece un estándar de integración, el ecosistema se reorganiza: equipos que antes duplicaban integraciones invierten ese esfuerzo en mejorar un único servidor que cualquiera puede usar; los clientes dejan de competir por quién soporta más herramientas y pasan a competir por la calidad de la experiencia; los autores de servicios (un CRM, un gestor documental, una plataforma de monitorización) pueden exponer su producto a los LLMs sin apostar por un proveedor concreto.
Para los agentes, las implicaciones son más profundas. Un agente útil necesita un conjunto amplio, evolutivo y auditable de capacidades. Hoy esas capacidades viven dentro del código del agente, lo que convierte cada incorporación en un despliegue. Con MCP, un agente puede conectarse a un servidor nuevo sin recompilar nada, y el operador puede añadir, retirar o actualizar servidores sin tocar el agente. Es el mismo patrón que llevó a los IDEs modernos a soportar decenas de lenguajes sin necesidad de tener un parser nativo para cada uno.
Qué queda por madurar
El protocolo nace con los frenos típicos de cualquier estándar recién publicado. La autenticación y la autorización se definen a nivel de responsabilidad pero no de esquema; quedan a criterio de cada servidor. La inyección de prompts a través de recursos o respuestas de herramientas es un vector real que los servidores tienen que mitigar por su cuenta. Los patrones de despliegue a gran escala (versionado, descubrimiento dinámico, permisos granulares) están todavía por acordar. Y el soporte de clientes distintos de Claude Desktop es, en el momento del lanzamiento, inexistente.
Nada de esto es raro. LSP pasó por una fase equivalente antes de que Visual Studio Code lo hiciera hegemónico, y OpenAPI tardó años en convertirse en la lingua franca de las APIs REST. Lo interesante de MCP es que Anthropic ha publicado la especificación, los SDKs (Python y TypeScript) y una colección inicial de servidores oficiales (sistema de ficheros, GitHub, GitLab, Slack, Postgres, SQLite, Brave Search, Puppeteer, Google Drive) al mismo tiempo, lo que reduce el coste de adoptar el protocolo a algo menor que escribir la siguiente integración propietaria.
Una lectura honesta del momento
MCP puede convertirse en el estándar dominante para la capa de herramientas de los modelos de lenguaje, o puede quedarse como una apuesta interesante que otros proveedores ignoran. Ambos desenlaces son plausibles. Lo que no lo es, es sostener el statu quo: cada equipo reescribiendo el mismo adaptador para que el mismo LLM lea el mismo tipo de fuente. Esa fricción es demasiado grande cuando existe una alternativa con SDKs funcionales y una especificación pública. El valor de MCP, incluso si el nombre termina cambiando, es que deja claro dónde debe vivir la frontera y cómo debería verse. Los próximos meses dirán si Anthropic ha adivinado el corte correcto; la forma del problema, desde luego, la ha leído bien.
