latent
Cada framework de IA tiene su propia manera de definir herramientas. MCP es el intento de convertir eso en un problema resuelto.
El problema que resuelve MCP
Si has construido agentes que utilizan herramientas, te has topado con este muro. LangChain tiene un formato de herramientas. OpenAI tiene function calling con su propio JSON schema. Anthropic tiene una API de uso de herramientas diferente. Cada framework inventa su propia convención. Las herramientas en sí —buscar en una base de datos, llamar a una API, leer un archivo— son las mismas. El cableado es diferente cada vez.
Por lo tanto, las implementaciones de las herramientas no son portables. Una herramienta creada para LangChain tiene que ser reescrita para la Assistants API de OpenAI, y reescrita de nuevo para cualquier framework de agentes personalizado que estés usando este trimestre. Multiplica eso por cada herramienta en tu stack y cada proveedor de modelos que quieras soportar, y la superficie de integración se vuelve inmanejable.
El Model Context Protocol, introducido por Anthropic, estandariza la interfaz. Define cómo los modelos de IA descubren, describen e invocan herramientas externas, independientemente de qué modelo o framework esté realizando la llamada.
Arquitectura
MCP sigue una arquitectura cliente-servidor:
Un servidor MCP es un proceso que expone herramientas (y opcionalmente recursos y prompts) a través de una interfaz estandarizada. El servidor declara qué herramientas tiene, qué parámetros aceptan y qué devuelven.
Un cliente MCP es el runtime del modelo de IA, o el framework que lo envuelve, que se conecta a los servidores MCP, descubre las herramientas disponibles y las invoca cuando el modelo decide usar una.
El transporte es JSON-RPC, típicamente sobre stdio para procesos locales o HTTP con Server-Sent Events para servidores remotos. El protocolo es agnóstico al transporte.
El punto es la separación de responsabilidades. El implementador de la herramienta no necesita saber qué modelo llamará a su herramienta. El modelo no necesita saber cómo está implementada la herramienta. MCP es el contrato entre ellos.
Construyendo un servidor MCP
Un servidor MCP en Python es corto. Aquí tienes un ejemplo mínimo que expone una herramienta de consulta climática:
from mcp.server import Server
from mcp.types import Tool, TextContent
import mcp.server.stdio
server = Server("weather-server")
@server.list_tools()
async def list_tools() -> list[Tool]:
return [
Tool(
name="get_weather",
description="Get current weather for a city",
inputSchema={{
"type": "object",
"properties": {{
"city": {{
"type": "string",
"description": "City name, e.g. 'San Francisco'"
}}
}},
"required": ["city"]
}}
)
]
@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
if name == "get_weather":
city = arguments["city"]
# Your actual weather API call here
weather = await fetch_weather(city)
return [TextContent(type="text", text=f"Weather in {{city}}: {{weather}}")]
raise ValueError(f"Unknown tool: {{name}}")
async def main():
async with mcp.server.stdio.stdio_server() as (read, write):
await server.run(read, write, server.create_initialization_options())El SDK de TypeScript sigue el mismo patrón:
import {{ Server }} from "@modelcontextprotocol/sdk/server/index.js";
import {{ StdioServerTransport }} from "@modelcontextprotocol/sdk/server/stdio.js";
const server = new Server({{ name: "weather-server", version: "1.0.0" }}, {{
capabilities: {{ tools: {{}} }}
}});
server.setRequestHandler(ListToolsRequestSchema, async () => ({{
tools: [{{
name: "get_weather",
description: "Get current weather for a city",
inputSchema: {{
type: "object",
properties: {{
city: {{ type: "string", description: "City name" }}
}},
required: ["city"]
}}
}}]
}}));
server.setRequestHandler(CallToolRequestSchema, async (request) => {{
if (request.params.name === "get_weather") {{
const weather = await fetchWeather(request.params.arguments.city);
return {{ content: [{{ type: "text", text: weather }}] }};
}}
}});
const transport = new StdioServerTransport();
await server.connect(transport);Schemas de herramientas
MCP utiliza JSON Schema para describir las entradas de las herramientas, lo que proporciona a los clientes información de tipos real para la validación de parámetros y ayuda a los modelos a determinar qué argumentos proporcionar.
Un schema de herramienta bien diseñado necesita descripciones claras en cada propiedad (el modelo las lee para decidir cómo usar la herramienta), restricciones de tipo adecuadas (string, number, array, valores enum), parámetros obligatorios frente a opcionales para que el modelo sepa qué debe proporcionar, y ejemplos en las descripciones para que el modelo pueda formatear los argumentos correctamente.
{{
"name": "search_database",
"description": "Search the product database with filters. Returns up to 20 results.",
"inputSchema": {{
"type": "object",
"properties": {{
"query": {{
"type": "string",
"description": "Natural language search query"
}},
"category": {{
"type": "string",
"enum": ["electronics", "clothing", "home", "books"],
"description": "Product category to filter by"
}},
"max_price": {{
"type": "number",
"description": "Maximum price in USD"
}},
"in_stock": {{
"type": "boolean",
"description": "If true, only return items currently in stock",
"default": true
}}
}},
"required": ["query"]
}}
}}La calidad de las descripciones de tus herramientas decide qué tan bien las utilizan los modelos. Las descripciones vagas producen argumentos incorrectos. Sé específico.
Más allá de las herramientas: recursos y prompts
Los servidores MCP pueden exponer más que herramientas.
Los recursos (resources) son fuentes de datos de solo lectura que el cliente puede integrar en el contexto. Piensa en ellos como archivos, registros de bases de datos o respuestas de API que el modelo puede referenciar. Un recurso tiene un URI, una descripción y contenido.
@server.list_resources()
async def list_resources():
return [
Resource(
uri="docs://api-reference",
name="API Reference",
description="Complete API documentation",
mimeType="text/markdown"
)
]Los prompts son plantillas de prompts reutilizables que el servidor proporciona. Un cliente puede listar los prompts disponibles y renderizarlos con argumentos. Esto permite a los proveedores de herramientas ofrecer prompts optimizados junto con sus herramientas.
Las herramientas manejan acciones, los recursos portan contexto y los prompts contienen instrucciones. Juntos, le dan a los servidores MCP un vocabulario completo para la integración de IA.
Cómo se compara con OpenAI function calling
El function calling de OpenAI y MCP resuelven problemas relacionados pero diferentes.
Function calling es una característica a nivel de modelo. Describes las funciones en la solicitud de la API y el modelo genera un JSON estructurado para llamarlas. La ejecución ocurre de tu lado. Es un patrón de solicitud-respuesta vinculado a una sola llamada de API.
MCP es un estándar a nivel de protocolo. Define cómo un runtime descubre e invoca herramientas a través de límites de procesos. El modelo no necesita saber que está usando MCP; el cliente se encarga del protocolo. MCP soporta conexiones persistentes, streaming y notificaciones iniciadas por el servidor.
Otra forma de pensarlo: function calling define el formato de una sola llamada a una herramienta. MCP define todo el ciclo de vida —descubrimiento, invocación, streaming de resultados, manejo de errores— a través de múltiples herramientas y servidores.
En la práctica, son complementarios. Un cliente MCP podría traducir los schemas de herramientas de MCP al formato de function calling de OpenAI cuando habla con GPT-4, y al formato de uso de herramientas de Anthropic cuando habla con Claude. Al servidor MCP no le importa qué modelo está al otro lado.
Por qué esto es importante para los sistemas multi-agente
Los sistemas agénticos donde múltiples agentes colaboran en tareas complejas necesitan una interfaz de herramientas común más que los sistemas de un solo agente. Sin un estándar, cada conexión de agente a herramienta es una integración personalizada. Así es como los backlogs de integración devoran los proyectos.
MCP te ofrece marketplaces de herramientas. Construye una herramienta una vez, publícala como un servidor MCP y cualquier agente compatible con MCP podrá usarla. La comunidad ya cuenta con servidores MCP para bases de datos, sistemas de archivos, navegación web, GitHub, Slack y docenas de otras integraciones.
Te brinda descubrimiento dinámico de herramientas. Un agente puede conectarse a servidores MCP en runtime y descubrir qué herramientas están disponibles, en lugar de tener las herramientas prefijadas (hardcoded) en el momento del desarrollo.
Te ofrece composibilidad. Un agente orquestador puede conectarse a varios servidores MCP a la vez —uno para acceso a bases de datos, uno para correo electrónico, uno para ejecución de código— y el modelo razona sobre la unión de todas las herramientas disponibles.
Despliegue práctico
Los servidores MCP ya son compatibles con Claude Desktop (configúralos en los ajustes de la aplicación), Claude Code (añádelos a la configuración de tu proyecto para herramientas con conocimiento del código) e integraciones de IDE como Cursor, Windsurf y Cline. LangChain y LlamaIndex tienen integraciones de framework para pipelines de agentes existentes.
Para el despliegue en producción, el transporte HTTP+SSE permite que los servidores MCP funcionen como servicios remotos bajo autenticación. Despliegas el servidor en tu infraestructura, lo colocas detrás de un API gateway y permites que los clientes autorizados se conecten a él.
El protocolo es joven y aún está evolucionando. Pero la trayectoria es clara. Si estás construyendo herramientas que los modelos de IA deberían poder usar, MCP es la interfaz que le da a tu herramienta el mayor alcance.