“¿Y para qué quiero MCP si OpenAI ya tiene function calling?” Es la pregunta más frecuente entre devs que llegan al ecosistema. La respuesta corta: function calling resuelve el contrato modelo↔código; MCP resuelve el contrato cliente↔servidor de herramientas. No compiten — operan en capas distintas.
Function calling: el contrato modelo↔código
Cuando llamas a la API de OpenAI o Anthropic con un parámetro tools, el modelo decide invocar una función y devuelve un JSON estructurado. Tu código (en tu app, en tu lenguaje, en tu proceso) ejecuta la función real y devuelve el resultado.
Es elegante para apps a medida: total control del execution, debugging local, sin overhead de procesos extra. Pero la herramienta vive dentro de tu app. Si quieres reutilizarla en otra app, copy-paste o publicas una librería.
MCP: el contrato cliente↔servidor
MCP estandariza cómo un cliente (Claude Desktop, Cursor, Cline, etc.) descubre, configura y consume herramientas servidas por un proceso aparte. La pieza nueva no es cómo el modelo invoca la tool — eso pasa por function calling igual. Es cómo el cliente y el servidor se ponen de acuerdo.
Internamente, los clientes MCP usan function calling debajo. La diferencia visible: el mismo servidor MCP funciona con cualquier cliente compatible. Cambiar de Claude Desktop a Cursor: cero cambios en el servidor.
Tabla rápida
| Aspecto | Function calling solo | MCP |
|---|---|---|
| Lugar donde vive la tool | En tu app | Proceso aparte (servidor) |
| Reutilización entre clientes | Reescribes | Mismo binario |
| Aislamiento | Mismo proceso | Out-of-process |
| Distribución | npm/PyPI de tu librería | npm/PyPI estándar MCP |
| Ideal para | Apps custom, agentes backend | Asistentes, productos al usuario final |
| Overhead | Mínimo | Stdio/IPC por invocación |
Cuándo function calling solo es suficiente
- Construyes un agente backend con orchestración compleja (LangGraph, CrewAI).
- Las tools acceden a estado interno de tu app (cache compartido, conexiones DB pooled).
- Tu producto es la app, no una integración con un cliente externo.
- Iteración rápida en notebook donde proceso aparte añade fricción.
Cuándo MCP claramente gana
- Tu producto se distribuye a usuarios con Claude Desktop, Cursor o similar.
- Quieres aprovechar el catálogo existente (mira los servidores MCP en español).
- Aislamiento por seguridad: la herramienta no debe acceder a la memoria de tu app principal.
- Equipo que comparte herramientas: una vez publicado el servidor, todos lo instalan idéntico.
El caso “ambos a la vez”
El patrón más interesante en 2026: usas LangChain o un orquestador propio (con function calling) en tu backend, y ese orquestador a su vez actúa como cliente MCP consumiendo servidores estándar. Lo mejor de los dos mundos: control total del flujo + reutilización del catálogo.
Ejemplo: tu backend tiene 5 functions custom (lógica de negocio interna) + se conecta como cliente MCP a postgres-mcp y stripe-mcp del catálogo público. No tuviste que escribir un wrapper a Stripe.
Lo que decidirá la pregunta en 2027
Si los proveedores de modelos (OpenAI, Google, Meta) adoptan oficialmente el spec MCP — Anthropic ya lo lidera — function calling y MCP terminan siendo dos APIs del mismo contrato. Por ahora, function calling sigue siendo el standard de bajo nivel y MCP el standard de capa de aplicación. Aprende ambos; no son sustitutos.