Guías de IA · 13 min de lectura

Tool Calling vs MCP: diferencias y cuándo usar cada uno

Tool Calling permite pedir funciones y MCP estandariza cómo compartirlas. Descubre sus diferencias, cómo se combinan y cuándo usar cada uno.

Ilustración de un núcleo de IA que entrega una solicitud sellada a una caja de herramientas a la izquierda y se conecta a la derecha a un centro universal conectado a múltiples herramientas

Tool Calling es una función de las API de modelos de lenguaje en la que el modelo solicita una llamada a una función y la aplicación ejecuta el código. Model Context Protocol (MCP) es un estándar abierto de JSON-RPC que permite a las aplicaciones de IA descubrir e invocar herramientas expuestas por servidores externos. MCP se apoya en Tool Calling, no lo sustituye.

Los desarrolladores que crean agentes de IA o backends basados en LLM encuentran ambos términos con frecuencia en la documentación de los proveedores. Para entender Tool Calling frente a MCP hay que distinguir cómo decide un modelo ejecutar una función de cómo se conecta una aplicación al sistema donde reside esa función.

¿Qué es Tool Calling en las API de LLM?

Tool Calling (también llamado function calling) es una función de las API de modelos que convierte un prompt en lenguaje natural en una invocación estructurada de una función. En la solicitud a la API se envían definiciones de funciones con un nombre, una descripción y parámetros JSON Schema, y el modelo decide si devuelve una llamada estructurada que contiene el nombre de la función y sus argumentos.

El modelo no ejecuta la función por sí mismo. Tool Calling funciona como una conversación de varios pasos entre la aplicación y el modelo:

  1. Enviar declaraciones de herramientas: la aplicación solicita una respuesta al modelo e incluye las definiciones JSON Schema de las herramientas que este puede llamar.
  2. Recibir una llamada estructurada: el modelo responde con una llamada que contiene el nombre de la función elegida y argumentos JSON (por ejemplo, Anthropic devuelve un motivo de parada y un bloque tool_use).
  3. Ejecutar código en la aplicación: el backend valida los argumentos y ejecuta la función local o la solicitud a una API interna.
  4. Devolver el resultado de la herramienta: la aplicación envía una segunda solicitud al modelo con el resultado (por ejemplo, un bloque tool_result).
  5. Recibir la respuesta final: el modelo usa el resultado para responder al usuario o solicita más llamadas a herramientas.

Una definición de función de OpenAI usa parameters de JSON Schema y admite strict: true para exigir el cumplimiento del esquema:

{
  "type": "function",
  "name": "get_weather",
  "description": "Get the current weather for a given location.",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string"
      }
    },
    "required": ["location"],
    "additionalProperties": false
  }
}

Las principales API de modelos ofrecen un control detallado sobre cómo selecciona funciones el modelo. En las API de OpenAI y Google Gemini, tool_choice permite dejar la selección en auto (valor predeterminado), forzar una o más llamadas (required en OpenAI, any en Gemini), desactivar las herramientas (none), limitar el modelo a un subconjunto con allowed_tools o usar el modo validated de Gemini para garantizar el cumplimiento del esquema de función. Tanto OpenAI como Gemini admiten llamadas paralelas a funciones, de modo que un modelo puede invocar varias en un mismo turno. OpenAI permite establecer parallel_tool_calls en false si se desea como máximo una llamada por turno. Gemini también admite llamadas composicionales para ejecuciones secuenciales de varios pasos.

Anthropic distingue el uso de herramientas según dónde se ejecuta el código. Las herramientas de cliente (que incluyen funciones personalizadas y herramientas con el esquema de Anthropic como bash y text_editor) se ejecutan dentro de la aplicación. Las herramientas de servidor (como web_search, web_fetch, code_execution y tool_search) se ejecutan directamente en la infraestructura de Anthropic.

¿Qué es Model Context Protocol (MCP)?

Model Context Protocol (MCP) es un estándar de código abierto para conectar aplicaciones de IA a sistemas externos mediante JSON-RPC 2.0. Inspirada en Language Server Protocol, la especificación MCP (versión 2026-07-28) actúa como un puerto USB-C para las aplicaciones de IA, de forma que una sola integración de servidor puede funcionar con ChatGPT, Claude, Visual Studio Code, Cursor y agentes personalizados.

MCP divide las responsabilidades entre tres roles:

  • Anfitriones (Hosts): aplicaciones LLM (como un IDE o una interfaz de chat) que inician conexiones.
  • Clientes (Clients): conectores del protocolo que se ejecutan dentro de la aplicación anfitriona.
  • Servidores (Servers): servicios externos que exponen capacidades y contexto al cliente.

En la especificación 2026-07-28, el protocolo base usa solicitudes JSON-RPC 2.0 autónomas y sin estado, con negociación de capacidades en cada solicitud. MCP define dos transportes estándar: stdio, que transmite mensajes delimitados por saltos de línea a través de la entrada y salida estándar de un subproceso iniciado por el cliente, y Streamable HTTP, donde cada mensaje es un POST HTTP a un único endpoint MCP. Los desarrolladores también pueden implementar transportes personalizados.

Mientras que Tool Calling en LLM solo gestiona funciones, los servidores MCP pueden exponer tres capacidades principales:

  • Tools: funciones que puede ejecutar el modelo de IA.
  • Resources: contexto y datos que la aplicación puede leer.
  • Prompts: plantillas de mensajes y flujos de trabajo para los usuarios.

En el cliente, MCP admite Elicitation, que permite a un servidor solicitar información adicional al usuario. La especificación 2026-07-28 también incluye extensiones opcionales negociadas para Tasks (operaciones asíncronas de larga duración), Skills over MCP y MCP Apps (elementos de interfaz interactivos mostrados en línea).

Para ejecutar herramientas, un cliente MCP descubre las disponibles llamando a tools/list, que admite paginación y almacenamiento en caché. Los servidores que declaran la capacidad listChanged pueden avisar a los clientes cuando cambian las herramientas disponibles. Cada definición de herramienta MCP incluye un name que distingue mayúsculas y minúsculas (se recomiendan de 1 a 128 caracteres), un title opcional, una description, icons opcionales, un inputSchema (por defecto JSON Schema 2020-12), un outputSchema opcional y anotaciones opcionales.

Cuando el modelo decide usar una herramienta MCP, el cliente envía al servidor una solicitud JSON-RPC tools/call:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "San Francisco, CA"
    }
  }
}

Si falla la ejecución de una herramienta en el servidor, MCP devuelve el error dentro del resultado con isError: true, para que el modelo de lenguaje pueda leer el fallo y corregirse.

Tool Calling vs MCP: comparación

Comparar directamente Tool Calling en LLM con MCP muestra que operan en distintas capas de la arquitectura. En noviembre de 2026, estas son las diferencias entre Tool Calling nativo y Model Context Protocol en siete aspectos arquitectónicos:

Aspecto Tool Calling (Function Calling) Model Context Protocol (MCP)
Qué es Función de la API de un modelo en la que un LLM emite argumentos estructurados para una función Protocolo abierto JSON-RPC 2.0 que conecta anfitriones y clientes de IA con servidores externos
Quién define las herramientas El código de la aplicación (o las herramientas de servidor del proveedor) en la solicitud a la API del modelo Un servidor MCP que expone Tools, Resources y Prompts
Dónde se ejecuta el código El backend de la aplicación (o la nube del proveedor del LLM para herramientas de servidor) Un subproceso local (stdio) o un servicio remoto (Streamable HTTP)
Descubrimiento Estático en cada solicitud a la API; el código fija o selecciona los esquemas antes de llamar al modelo Dinámico en tiempo de ejecución mediante tools/list y notificaciones listChanged
Transporte API HTTPS del proveedor (OpenAI, Anthropic, Google Gemini) stdio, Streamable HTTP o transportes personalizados
Portabilidad entre clientes Ligada a la aplicación y al formato de esquema del proveedor concreto de LLM Portable entre anfitriones compatibles con MCP (Claude, ChatGPT, VS Code, Cursor y aplicaciones personalizadas)
Coste Tokens de entrada para definiciones, tokens de salida para llamadas y cargos adicionales por herramientas de servidor del proveedor Tokens de entrada por cada esquema de herramienta cargado e infraestructura para alojar o ejecutar el servidor MCP

¿Sustituye MCP a Function Calling?

MCP no sustituye a Function Calling, porque el modelo de lenguaje sigue usando Tool Calling para seleccionar e invocar cada herramienta MCP. Tool Calling y MCP son capas complementarias de un mismo ciclo de vida de solicitud.

Cuando una aplicación de IA se conecta a un servidor MCP, el flujo combina ambos sistemas:

  1. Descubrimiento mediante MCP: el cliente MCP de la aplicación anfitriona envía una solicitud tools/list al servidor MCP y recibe los nombres, descripciones y objetos inputSchema de JSON Schema de sus herramientas.
  2. Formato para el LLM: el anfitrión traduce esas definiciones de herramientas MCP al array tools nativo del proveedor del LLM y las envía junto con el prompt del usuario.
  3. Selección mediante Tool Calling: el modelo de lenguaje evalúa el prompt y emite una llamada estándar con el nombre y los argumentos de la herramienta elegida.
  4. Ejecución mediante MCP: el anfitrión intercepta la llamada del modelo, la convierte en una solicitud MCP tools/call y la envía al servidor MCP mediante stdio o Streamable HTTP.
  5. Finalización: el servidor MCP devuelve el resultado (con isError: true si falló la ejecución), el anfitrión lo transmite al modelo como resultado de herramienta y el modelo genera su respuesta final.

Sin Tool Calling en la API del modelo, el LLM no tendría ningún mecanismo para activar una herramienta MCP. Sin MCP, la aplicación debe conectar manualmente cada esquema de herramienta y cada controlador de ejecución.

¿Cómo admiten MCP directamente OpenAI, Anthropic y Google?

OpenAI, Anthropic y Google permiten ahora pasar servidores MCP remotos directamente a sus API de modelos como un tipo de herramienta integrado. En vez de escribir un bucle de cliente MCP propio para conectar tools/list y tools/call, la API del proveedor del modelo se conecta al servidor MCP por ti.

En noviembre de 2026, cada proveedor implementa las conexiones directas a servidores MCP con capacidades específicas y límites documentados:

OpenAI Responses API

En OpenAI Responses API se puede añadir un servidor MCP especificando "type": "mcp" en el array de herramientas junto con server_label y server_url. OpenAI incluye dos controles clave para producción:

  • allowed_tools: importa solo un subconjunto concreto de herramientas del servidor MCP para no sobrecargar el contexto del modelo.
  • require_approval: configura si las invocaciones se ejecutan automáticamente o esperan la aprobación explícita de una persona.

Para servicios locales o privados, OpenAI ofrece Secure MCP Tunnel, que permite conectar servidores MCP internos sin exponerlos a Internet.

Anthropic MCP Connector

Anthropic ofrece un MCP connector en fase beta en Messages API (mcp_servers y mcp_toolset) que conecta servidores MCP remotos sin requerir una implementación de cliente independiente. Conviene tener en cuenta cuatro limitaciones documentadas:

  • Solo herramientas: el conector solo admite llamadas a herramientas de la especificación MCP (no Resources ni Prompts de MCP).
  • Se requiere HTTP público: el servidor MCP debe estar expuesto públicamente mediante HTTP (con soporte para Streamable HTTP y SSE).
  • Sin stdio local directo: los servidores stdio locales no pueden conectarse directamente a Messages API, aunque los SDK de Anthropic ofrecen utilidades del lado del cliente para servidores locales.
  • Exclusiones de cumplimiento: el MCP connector beta no es apto para cargas de trabajo con Zero Data Retention (ZDR) o HIPAA.

Google Gemini Interactions API

Gemini Interactions API de Google acepta servidores MCP externos con la declaración "type": "mcp_server", configurada mediante name, url, headers y allowed_tools. Google impone dos reglas estrictas a esta integración:

  • Solo Streamable HTTP: Gemini Interactions API admite servidores Streamable HTTP y no admite transportes SSE.
  • Sintaxis de nombres: los nombres de servidor deben usar snake_case y no pueden contener guiones.

¿Cuándo usar Tool Calling o MCP?

La elección entre MCP y Tool Calling depende de quién mantiene las integraciones y de cuántas aplicaciones deben compartirlas. Examina las restricciones de tu proyecto a partir de tres patrones comunes.

Cuándo basta con Tool Calling simple

Usa Tool Calling nativo del LLM cuando las herramientas estén en el backend de una sola aplicación y ningún cliente externo necesite llamarlas. Si estoy creando una aplicación web con cinco consultas internas a bases de datos y una acción de pago con Stripe, escribir un servidor MCP añade un salto de red o un subproceso innecesario.

Tool Calling simple es más adecuado cuando:

  • Solo tienes un pequeño número de funciones que consultan tu propia base de datos o microservicios internos.
  • Controlas todo el código y quieres baja latencia y validación directa dentro del proceso.
  • Ningún otro asistente de IA, IDE o equipo necesita descubrir o reutilizar esas funciones.

Cuándo compensa un servidor MCP

Crea o adopta un servidor MCP cuando las mismas herramientas deban funcionar con varios clientes de IA o cuando otro equipo sea responsable del sistema subyacente. Si tu plataforma de ingeniería expone el seguimiento de incidencias y los registros de despliegue mediante MCP, los desarrolladores pueden conectar exactamente el mismo servidor a Claude, ChatGPT, Visual Studio Code, Cursor y tu agente interno sin reescribir esquemas.

MCP compensa cuando:

  • Quieres escribir una vez y lograr portabilidad entre varios anfitriones de IA e IDE de desarrollo.
  • Un proveedor externo u otro equipo interno mantiene la integración.
  • Tu agente depende del descubrimiento dinámico de herramientas (tools/list y listChanged) cuando las capacidades cambian durante la ejecución.
  • Tu flujo de trabajo necesita Resources de MCP, plantillas de prompts para usuarios o solicitudes de información al usuario además de la ejecución de funciones.

La configuración híbrida

Un patrón común para los equipos que llevan agentes de IA del piloto a producción es combinar ambos enfoques. Una aplicación típica define en el código unas pocas herramientas de funciones nativas sensibles a la latencia y conecta uno o dos servidores MCP externos para integraciones SaaS de terceros, usando allowed_tools para filtrar endpoints innecesarios.

Compensaciones de seguridad, latencia y coste en tokens

Añadir herramientas a una aplicación LLM, mediante declaraciones nativas o servidores MCP, introduce costes de tokens, consideraciones de caché y límites de seguridad que hay que gestionar con cuidado.

Costes de tokens de entrada y caché de prompts

Cada definición de herramienta enviada a una API de modelo cuenta como tokens de entrada. Anthropic documenta que las definiciones en el parámetro tools cuentan como tokens de entrada, y OpenAI señala que algunos servidores MCP exponen decenas de herramientas a la vez, lo que puede aumentar tanto el coste como la latencia.

Para mantener predecible el gasto en tokens:

  • Filtra las herramientas importadas: OpenAI y Google usan allowed_tools, mientras que el MCP connector de Anthropic permite incluir, excluir o configurar herramientas individuales en mcp_toolset.
  • Mantén un orden determinista en la lista de herramientas. La especificación MCP señala que un orden determinista en tools/list ayuda a los clientes a almacenar la lista en caché y mejora la tasa de aciertos de la caché de prompts del LLM cuando las definiciones están en el contexto del modelo.

Límites de confianza y aprobación humana

Las herramientas implican la ejecución de código arbitrario, una preocupación aún mayor si también despliegas agentes de IA que usan ordenadores e interactúan con sistemas operativos completos. Al conectar un servidor MCP de terceros, cruzas un límite de confianza: las descripciones de herramientas o respuestas del servidor que no son fiables pueden ser un vector de inyección de prompts.

La especificación MCP advierte explícitamente que las anotaciones de herramientas deben tratarse como no fiables salvo que procedan de un servidor de confianza. Como MCP no puede imponer la seguridad en el nivel del protocolo de comunicación, la especificación indica que las aplicaciones anfitrionas deben obtener el consentimiento explícito del usuario antes de invocar cualquier herramienta y deberían mantener siempre a una persona involucrada que pueda denegar las invocaciones. Al usar integraciones directas de API como Responses API de OpenAI, activa require_approval en herramientas sensibles para que una persona pueda revisar los argumentos antes de la ejecución.

FAQ

¿Es MCP lo mismo que Function Calling?

No. Function Calling (Tool Calling) es el mecanismo de la API de un modelo por el que un LLM emite una solicitud JSON estructurada para ejecutar una función con nombre. Model Context Protocol (MCP) es un estándar abierto de comunicación que permite a las aplicaciones de IA descubrir e invocar Tools, Resources y Prompts alojados en servidores externos.

¿Se puede usar MCP sin Tool Calling?

Puedes usar Resources y plantillas de prompts de MCP sin Tool Calling del modelo, ya que la aplicación anfitriona o el usuario lee o activa esas funciones. Sin embargo, cada vez que un modelo de IA invoca autónomamente una herramienta MCP mediante tools/call, utiliza su capacidad nativa de Tool Calling para seleccionarla.

¿Consume MCP más tokens que Tool Calling nativo?

Una definición de herramienta individual cuesta el mismo número de tokens de entrada tanto si la aplicación la carga desde código local como desde un servidor MCP. En la práctica, las configuraciones MCP suelen consumir más tokens porque un solo servidor MCP puede exponer decenas de herramientas a la vez, a menos que filtres la lista con allowed_tools.

¿Qué proveedores de LLM admiten servidores MCP de forma nativa en sus API?

En noviembre de 2026, OpenAI, Anthropic y Google aceptan directamente servidores MCP remotos en sus API. OpenAI admite "type": "mcp" en Responses API, Anthropic ofrece el MCP connector beta (mcp_servers y mcp_toolset) en Messages API y Google admite "type": "mcp_server" en Gemini Interactions API.

¿Puede la API de Anthropic conectarse directamente a un servidor MCP stdio local?

No. El MCP connector beta de Anthropic en Messages API solo se conecta a servidores MCP remotos expuestos públicamente mediante HTTP (Streamable HTTP y SSE). Para usar un servidor MCP stdio local con Claude, debes ejecutar la conexión en el cliente usando las utilidades del SDK de Anthropic.

Sources

Escrito por

Chunyu Cai

Chunyu Cai es el director ejecutivo de Lotook, LLC y un emprendedor que escribe sobre modelos de IA, agentes y cómo cambian el trabajo cotidiano. Chunyu Cai tiene un título de máster de Imperial College London.