is
Todos los posts
MCPMCPfunction callingingeniería

MCP vs function calling: cuándo cambiar (y cuándo no)

Function calling es el patrón in-app de declarar herramientas dentro de una sola conversación de SDK LLM; MCP (Model Context Protocol) es el patrón cross-app de correr herramientas como un servicio JSON-RPC separado que cualquier cliente MCP-aware (Claude Desktop, Code, SDKs, agents) descubre y llama.

inite2 min de lectura

Usa function calling cuando tienes una sola app SDK, tus herramientas son simples y controlas cliente y servidor. Usa MCP cuando quieres que el mismo toolchain funcione en Claude Desktop, Claude Code, agents y CI sin reescribir la integración; cuando las herramientas tienen side effects que quieres centralizar; o cuando construyes un producto cuyos usuarios lo conectarán en su propio cliente LLM. El árbol de decisión es 90% conteo-de-clientes: 1 cliente = function calling, 2+ = MCP.

Datos clave

  • Function calling se envió en la API de OpenAI en junio 2023; Anthropic lo agregó en mayo 2024.
  • MCP llegó a GA en Claude Desktop en noviembre 2024.
  • Servidores MCP pre-construidos para filesystem, GitHub, Slack, Postgres y 50+ surfaces (abril 2026).
  • Migrar una app SDK a MCP toma 80-200 LOC para una superficie de 5 herramientas (ports reales que medimos).

Function calling y MCP resuelven el mismo problema raíz (deja que los LLMs llamen tu código) en alcances diferentes. Elegir el incorrecto te cuesta semanas; elegir el correcto es mostly contar clientes.

La regla simple

Un cliente LLM → function calling. Dos o más clientes → MCP.

Eso es 90% de la decisión. El 10% restante son edge cases.

Dónde function calling aún gana

Tres escenarios:

  1. Builds SDK single-app. Estás enviando un chatbot dentro de una app Next.js. Las herramientas viven al lado de los route handlers. El usuario nunca ve el LLM directamente — habla con tu UI. MCP agrega overhead sin payoff.
  2. Herramientas con requirements de latencia sub-ms. Function calling es in-process. MCP agrega overhead JSON-RPC — usualmente invisible, pero si optimizas tail latency en token-streaming, in-process gana.
  3. Herramientas tightly coupled a tu auth/sesión. Si la herramienta necesita la sesión logueada para hacer cualquier cosa, MCP hace el handoff de auth awkward.

Dónde MCP gana

Cinco escenarios, en orden de cuánto se apoyan en las fortalezas de MCP:

  1. Quieres la misma herramienta desde múltiples clientes. Claude Desktop, Code, SDK, script CI, agent de colega — todos pegan al mismo servidor MCP. Escribe una vez, conecta en todos lados.
  2. El usuario elige el cliente LLM. Envías un producto (como ideaudit). Los usuarios tienen Claude Desktop, Code u otro cliente MCP-aware. MCP es cómo los alcanzas a todos.
  3. Quieres auditing centralizado de tool calls. Los servidores MCP loguean cada llamada en un lugar. Function calling esparce logs por N apps consumidoras.
  4. Las herramientas tienen side effects en infra compartida. Database writes, rate limits de API, billing meters. Centralizarlos en un servidor MCP te da un chokepoint en lugar de N.
  5. Quieres herramientas pre-construidas. Filesystem, GitHub, Slack, Postgres — el ecosistema MCP envía docenas.

Patrón de migración

Si tienes una app SDK existente y quieres exponer sus herramientas a Claude Desktop también:

  1. Saca las definiciones de herramienta de la llamada SDK a un módulo standalone.
  2. Wrappea ese módulo en un servidor MCP (TypeScript o Python — boilerplate es ~50 LOC).
  3. Mantén la app SDK llamando al mismo módulo localmente para herramientas in-app.
  4. Registra el servidor MCP en la config de Claude Desktop.

El mismo código ahora sirve a ambos clientes. Costo de migración en ports reales: 80-200 LOC para superficie de 5 herramientas.

Qué eligió ideaudit

MCP, end to end. Razón: los usuarios tienen Claude Desktop, Claude Code y apps SDK. Queríamos un servidor, un modelo de auth, un rate limiter. Function calling por cliente habría significado reimplementar 103 herramientas tres veces y rezar para que se mantuvieran en sync.

curl -fsSL https://inite.studio/install.sh | sh

Las 103 herramientas son las mismas hables con ideaudit desde Claude Desktop, Code o SDK. Esa es la victoria del MCP, en una oración.

FAQ

Preguntas frecuentes

  1. ¿Puedo usar ambos?

    Sí — y muchas apps lo hacen. Usa function calling para herramientas in-app que el usuario nunca ve (auth, lookups internos). Usa MCP para herramientas que el usuario quiere acceder desde otros clientes también. Los dos coexisten en la misma sesión Claude.

  2. ¿MCP es más lento que function calling?

    Marginalmente. Function calling es in-process; MCP es JSON-RPC sobre stdio o HTTP-SSE. La latencia añadida es single-digit ms para stdio, ~50-100ms para HTTP. Para flujos LLM-bound el costo es invisible — el modelo toma 2-30s de todos modos.

  3. ¿MCP funciona con modelos no-Anthropic?

    Sí. MCP es model-agnostic — el protocolo no le importa qué LLM uses. Goose, Continue y la capa MCP-compat de OpenAI corren servidores MCP contra modelos no-Claude. Anthropic envió MCP primero porque invirtió temprano; el protocolo en sí es abierto.

  4. ¿Debería migrar mi app function-calling existente a MCP?

    Sólo si quieres las herramientas disponibles fuera de la app — para un pipeline CI, Claude Desktop, el agent de un colega. Si las herramientas son app-internas para siempre, function calling está bien.

Lee a continuación