MCP vs function calling: la diferencia que sí importa para tu agente
Si construyes con LLMs en 2026 te has topado con dos términos: function calling (OpenAI lo popularizó en 2023) y MCP — Model Context Protocol (Anthropic abrió el estándar en noviembre 2024). En tutoriales mal escritos los presentan como alternativas. No lo son.
Function calling es la conversación entre tú y el modelo. MCP es la infraestructura entre tu agente y el mundo exterior. Resuelven capas distintas. Y los agentes serios usan ambos. Encaja en el cluster Cliente MCP.
TL;DR
Function calling: cómo el LLM expresa "quiero ejecutar esta tool con estos parámetros".
MCP: cómo tu agente descubre, conecta y ejecuta tools desde servidores externos de forma estándar.
Trabajan juntos: el LLM hace function calling; tu cliente MCP enruta esa llamada al servidor MCP correcto.
Cómo funciona function calling (la base)
Cuando defines una tool en function calling clásica, le pasas al LLM un schema:
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "Obtiene el tiempo actual de una ciudad",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string"}
},
"required": ["city"]
}
}
}]El LLM, ante una pregunta del usuario, decide si llamar get_weather, con qué parámetros. Devuelve un JSON estructurado:
{"name": "get_weather", "arguments": {"city": "Madrid"}}Tu código ejecuta la función y devuelve el resultado al modelo, que sigue razonando.
Function calling es el lenguaje que el modelo habla para invocar tools. Lo soportan OpenAI, Anthropic, Google, Mistral, todos los grandes LLMs.
Cómo funciona MCP
Model Context Protocol es un protocolo cliente-servidor que estandariza cómo un agente:
Descubre qué tools, recursos y prompts hay disponibles en un servidor.
Se conecta a ese servidor (stdio, HTTP, SSE).
Ejecuta acciones de forma estándar.
Un servidor MCP expone:
Tools: acciones ejecutables (
create_issue,query_database).Resources: datos contextuales (documentos, registros).
Prompts: plantillas de interacción reutilizables.
Tu agente (cliente MCP) se conecta al servidor sin saber a priori qué tools tiene. Las descubre en runtime y las pone a disposición del LLM.
Detalle clave: el LLM no sabe que está usando MCP. Para él, son tools normales que llama por function calling. Es tu cliente MCP el que traduce entre el function calling del LLM y el protocolo MCP del servidor.
La diferencia visual
SIN MCP:
[LLM] ←function calling→ [tu código] ←lib/SDK→ [servicio externo]
(custom integration por servicio)
CON MCP:
[LLM] ←function calling→ [tu cliente MCP] ←protocolo MCP→ [servidor MCP] ←lib→ [servicio]
(descubre tools) (un servidor por servicio,
reutilizable)La diferencia: con MCP, la integración con cada servicio se hace una vez (en el servidor MCP) y la reutilizan todos los agentes. Sin MCP, cada agente reimplementa la integración.
Por qué función calling sin MCP no escala
Imagina un agente que necesita 15 tools: GitHub, Slack, Postgres, Stripe, Notion, Linear, AWS, Sentry, Mixpanel, Zendesk, Intercom, HubSpot, Calendly, Gmail, Google Drive.
Sin MCP:
Defines 15 schemas en tu código.
Implementas la lógica de cada llamada (auth, rate limit, parsing).
Si cambias de modelo (GPT → Claude → Gemini), revisas las 15 integraciones.
Si quieres compartir esto con otro agente, copias y pegas o publicas un SDK propio.
Si el API de Slack cambia, actualizas tu código de agente.
Con MCP:
Cada servicio tiene un servidor MCP (público en registry MCP o privado).
Tu cliente MCP enchufa los 15 servidores.
El LLM descubre las tools automáticamente.
Si Slack saca una versión nueva, el servidor MCP de Slack se actualiza una vez y todos los agentes que lo usan ya lo tienen.
Otro agente del equipo conecta los mismos servidores en 1 línea.
MCP convierte integraciones en infraestructura compartida.
Cuándo elegir solo function calling
No siempre necesitas MCP. Si:
Tu agente tiene 2-5 tools muy específicas y custom.
No vas a compartir esas tools con otros agentes.
Las tools tienen lógica de negocio entrelazada con tu app.
Function calling clásico te da más control y menos overhead. Para un script puntual, MCP es overkill.
Ejemplo: un agente interno que solo lee tu base de datos y emite reportes. 3 tools custom. No hace falta MCP.
Cuándo MCP gana claramente
Agente con 5+ tools de servicios distintos.
Varios agentes comparten infraestructura.
Quieres cambiar de modelo sin reescribir tools (LLM-agnostic).
Equipos distintos mantienen tools distintas.
Necesitas resources y prompts, no solo tools (ej: cargar docs como contexto).
Casos típicos: agentes de soporte interno, Claude Code, copilotos empresariales, agentes que tocan productividad (Calendly + Gmail + Drive + Notion).
Cómo se usan juntos
Patrón típico en producción:
from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions
options = ClaudeAgentOptions(
mcp_servers={
"slack": {"command": "npx", "args": ["-y", "@modelcontextprotocol/server-slack"]},
"postgres": {"command": "uvx", "args": ["mcp-server-postgres"]},
"filesystem": {"command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data"]}
},
allowed_tools=["mcp__slack__send_message", "mcp__postgres__query", "Read", "Write"]
)
async with ClaudeSDKClient(options=options) as agent:
await agent.query("Lee la última query del log y mándala a #data-alerts")El cliente MCP (ClaudeSDKClient) descubre las tools de los 3 servidores. Las expone al LLM como function calls normales. El LLM hace function calling sobre mcp__slack__send_message. El cliente MCP enruta al servidor de Slack. El servidor ejecuta. Resultado vuelve.
El LLM nunca "sabe" que usó MCP. Solo hace function calling. La magia está en la capa MCP.
Resources: lo que function calling no tiene
Function calling solo expone tools (acciones). MCP además expone resources (datos) y prompts (templates).
Resources: datos a los que el agente accede como contexto. Ej: un servidor MCP de tu wiki interna expone artículos como resources. El agente puede pedirle "lee el artículo /onboarding" sin tener que ejecutar una tool de búsqueda — los resources viven en el contexto del agente.
Prompts: plantillas reutilizables. Ej: un servidor MCP de PostgreSQL puede exponer prompts como "analyze_query_performance" con plantillas pre-validadas.
Estas dos primitivas no tienen equivalente en function calling clásico. Para casos complejos, son lo que separa un agente "que ejecuta cosas" de un agente "que entiende su entorno".
El cambio que MCP introduce: tools como infraestructura
Antes de MCP, tools eran código de tu app. MCP las convierte en infraestructura externa:
Compartibles entre equipos.
Versionables independientemente del agente.
Actualizables sin tocar el agente.
Sustituibles (cambias el servidor sin avisar al agente).
Es el mismo cambio mental que hubo cuando los APIs internos pasaron a ser microservicios: la lógica deja de vivir mezclada con el cliente.
Errores comunes
"Voy a meter MCP porque está de moda"
Si tu agente tiene 2 tools custom muy específicas, MCP te añade complejidad sin valor. Empieza con function calling. Migra a MCP cuando las tools se multipliquen o necesites compartir.
"MCP reemplaza function calling"
No. MCP usa function calling por debajo. La diferencia es dónde vive la lógica de la tool (tu código vs servidor MCP) y cómo se descubre (hardcoded vs runtime).
"Todos los servidores MCP son seguros"
Un servidor MCP de terceros puede leer tus datos o exfiltrar credenciales. Trata cada servidor MCP como cualquier dependencia externa: revisa, audita, restringe permisos. Anthropic publica buenas prácticas en sus docs MCP.
"MCP solo funciona con Claude"
MCP es un estándar abierto. Funciona con cualquier LLM si tienes un cliente MCP. Anthropic lidera, pero hay clientes MCP para OpenAI, modelos locales con Ollama, agentes con LangGraph, etc.
Cómo decidir hoy
Pregúntate:
¿Cuántas tools tendrá mi agente?
<5 → function calling clásico basta.
5-15 → MCP empieza a tener sentido.
15+ → MCP es la única forma sostenible.
¿Compartiré tools con otros agentes / equipos?
No → function calling clásico.
Sí → MCP gana.
¿Voy a cambiar de modelo o tener multi-modelo?
No → function calling clásico vale.
Sí → MCP te abstrae del modelo.
¿Necesito resources y prompts además de tools?
No → function calling clásico.
Sí → MCP es la única opción nativa.
Para profundizar
Qué es un cliente MCP — pillar del cluster.
Model Context Protocol explicado — la base del protocolo.
Cómo configurar MCP — setup paso a paso.
MCP de Anthropic en Claude — implementación oficial.
Claude Code MCP configuración — caso real.
Conclusión
Function calling y MCP no son rivales. Son capas. Function calling es cómo el modelo habla. MCP es dónde viven las tools. Un agente puede usar function calling sin MCP (válido para casos simples). Un agente con MCP siempre usa function calling por debajo.
Si construyes algo simple, function calling. Si construyes algo que va a crecer, MCP desde el día 1 te ahorra reescribir luego.
Fuentes verificadas
MCP especificación oficial — protocolo y registry.
LLM Function-Calling vs MCP (Gentoro) — análisis técnico.
MCP vs Function Calling (Descope) — comparativa.
Anthropic MCP announcement — anuncio noviembre 2024.
Datos verificados el 28 de abril de 2026.
