La confusión entre MCP y la llamada a funciones surge porque ambos aparecen cerca del mismo punto en la arquitectura: el momento en que un modelo necesita dejar la generación de texto y usar alguna capacidad externa. Pero no resuelven exactamente el mismo problema. La llamada a funciones, o llamada a herramientas, es principalmente un mecanismo para que el modelo elija una herramienta y produzca argumentos estructurados. MCP, el protocolo de contexto modelo, es un protocolo para conectar una aplicación de IA a servidores que exponen herramientas, recursos y avisos de forma estandarizada.
La distinción más útil es esta: la función que llama responde "¿qué herramienta quiere usar el modelo y con qué argumentos?". MCP responde "¿cómo encuentra, describe, accede y gobierna la aplicación capacidades externas de forma interoperable?". En una arquitectura real, estas respuestas pueden aparecer en la misma ejecución. El host descubre una herramienta a través de MCP, presenta esta capacidad al modelo a través de una abstracción de herramientas y, cuando el modelo decide usarla, la llamada viaja a través del cliente MCP hasta el servidor. En otras situaciones, la herramienta es una función local de la propia aplicación y no hay MCP.
La primera diferencia: la decisión del modelo no es lo mismo que la integración
En la llamada a funciones, la aplicación proporciona al modelo una descripción de la herramienta, generalmente con nombre, descripción y parámetros estructurados por esquema. Ante una solicitud, el modelo puede responder no con la respuesta final, sino con una llamada indicando la herramienta y los argumentos. En el flujo de autofunción clásico, la aplicación recibe esta intención, ejecuta el código correspondiente y devuelve el resultado al modelo para que continúe.
Esto es importante porque la llamada a la función no significa, en sí misma, que el modelo ejecutó la función. La documentación actual de OpenAI separa explícitamente la decisión de la ejecución en el caso de funciones controladas por el cliente: la aplicación recibe la llamada, ejecuta la función y devuelve el resultado. El proveedor puede alojar otros tipos de herramientas, pero este es otro acuerdo de ejecución.
MCP pasa a una capa diferente. La especificación 2026-07-28 define una arquitectura host-cliente-servidor basada en JSON-RPC. El anfitrión es la aplicación que coordina la experiencia con el
modelo. Cada cliente MCP se conecta a un servidor específico. El servidor anuncia capacidades que pueden incluir herramientas, recursos e indicaciones. Por lo tanto, el protocolo no es sólo para “llamadas a funciones”: también estandariza aspectos de descubrimiento, lectura de contexto, negociación de capacidades, transporte y autorización.
Qué funciones funcionan bien
La llamada a funciones es especialmente sencilla cuando la herramienta pertenece a la aplicación misma. Imaginemos un sistema interno con la función consult_status_pedido, que recibe un order_id. El equipo ya conoce el código, controla la autenticación, sabe dónde se ejecuta la función y no necesita que otros hosts de IA puedan reutilizar esta integración.
En este caso, simplemente declare la herramienta para el modelo, defina el esquema de entrada y maneje la llamada. El contrato es pequeño y predecible. Si la aplicación tiene cinco o diez funciones estables, esta solución suele tener menos partes operativas que introducir un protocolo adicional.
Las API modernas han ampliado este diseño. OpenAI, por ejemplo, ofrece hoy motores de búsqueda de herramientas para cargar herramientas bajo demanda en ciertos modelos, y los proveedores también tienen herramientas alojadas. Esto significa que el "descubrimiento dinámico" no es absolutamente exclusivo de MCP. La diferencia es que sin MCP, este mecanismo tiende a pertenecer a la API o marco específico del proveedor. MCP intenta estandarizar la interfaz entre el host y los servidores de capacidad independientemente de un único proveedor de modelo.
Qué añade MCP
MCP gana valor cuando la integración deja de ser solo una función conocida por su aplicación y se convierte en una capacidad que diferentes aplicaciones de IA pueden descubrir y utilizar a través de un contrato común.
En la especificación actual, los servidores pueden exponer herramientas para acciones y consultas, recursos para datos contextuales identificados por URI y solicitudes de plantillas reutilizables. El protocolo también define cómo el cliente descubre las capacidades del servidor. Esto separa la lógica de integración de la API específica del modelo y facilita que diferentes hosts consuman el mismo servidor, siempre que ambos implementen la versión y las capacidades compatibles.
Esta ganancia de portabilidad no elimina el trabajo de integración. Alguien todavía necesita implementar el servidor MCP, la autenticación, las políticas, la observabilidad y el manejo de errores. El beneficio aparece cuando esta capa compartida reemplaza múltiples adaptadores propietarios, o cuando la capacidad necesita ser descubierta por más de un agente, IDE, asistente o plataforma.
Un ejemplo único, del esquema al resultado
Considere la herramienta query_status_order. Recibe el ID del pedido y el estado de las devoluciones, la previsión de entrega y, cuando corresponda, el código de seguimiento. El objetivo del usuario es simple: "¿Dónde está el pedido 84521?".
Paso 1: El esquema describe la capacidad
En la ruta de llamada a la función, la aplicación incluye la herramienta consulta_status_pedido entre las herramientas que puede utilizar el modelo. El esquema le indica qué order_id se requiere y qué tipo de valor se espera. La descripción debe dejar claro cuándo la herramienta es apropiada y qué devuelve.
En la ruta MCP, el servidor también describe la herramienta con nombre, metadatos y esquema. La diferencia es que esta descripción es parte de una interfaz de servidor que puede ser descubierta por el cliente MCP. No es necesario que el anfitrión haya codificado cada herramienta individualmente antes de la conexión.
Paso 2: El modelo decide si necesita la herramienta
Después de leer la pregunta, el modelo concluye que no puede responder de manera confiable solo con el contexto disponible. Selecciona query_status_order y genera el argumento order_id igual a 84521.
Este es el punto en el que las arquitecturas parecen iguales para alguien que sólo observa el comportamiento del modelo. En ambos se describe una herramienta y una decisión de llamada. La divergencia aparece poco después: quién es el propietario de la herramienta, cómo fue descubierta y por qué camino llega la llamada al ejecutor.
Paso 3: ejecución local con llamada a función
Si query_status_order es una función de la aplicación misma, el orquestador recibe la llamada del modelo y ejecuta su código local o su integración directa con el backend. Luego, envía el resultado al modelo. El modelo transforma el feedback técnico en una respuesta para el usuario.
Aquí, el contrato entre el modelo y la aplicación es el centro de la solución. La aplicación ya sabe dónde está el albacea y cómo llamarlo. No es necesario que el host, el cliente y el servidor MCP sean protocolos separados.
Paso 4: ejecución por MCP
Si un servidor MCP publica la misma capacidad, el host mantiene un cliente conectado a ese servidor. El cliente puede descubrir que query_status_order existe, obtener su esquema y ponerlo a disposición en la capa de herramientas del agente. Cuando se autoriza la llamada, el cliente envía la solicitud MCP al servidor, que ejecuta la operación y devuelve el resultado.
En la versión 2026-07-28, el núcleo de MCP no tiene estado: cada solicitud lleva los metadatos de la versión y las capacidades necesarias, en lugar de depender del estado implícito de la sesión. El transporte predeterminado puede ser stdio para procesos locales o Streamable HTTP para servidores a los que se accede a través de HTTP. En ambos casos, la semántica del protocolo permanece separada de la decisión del modelo.
Paso 5: Arquitectura híbrida
Ahora supongamos que el agente tiene dos clases de capacidad. Una función local calcula la fecha límite prometida de acuerdo con las reglas internas, mientras que un servidor MCP de logística proporciona el estado del envío más reciente. El modelo puede utilizar la función local y la herramienta MCP en el mismo flujo.
Ésta es precisamente la razón por la que “¿MCP o llamada a función?” A menudo es una pregunta incompleta. En un sistema híbrido, la llamada a funciones puede seguir siendo la forma en que el modelo expresa la decisión de utilizar una herramienta controlada por la aplicación, mientras que MCP proporciona una superficie estandarizada para herramientas externas. En las API que ofrecen MCP como un tipo de herramienta alojada, el proveedor puede ocultar parte de este ciclo; En los SDK que conectan sesiones de MCP a la lista de herramientas, la implementación puede usar el mismo bucle de llamada de herramienta para reenviar las llamadas. Los detalles cambian según la plataforma, pero las responsabilidades conceptuales siguen siendo distintas.
MCP no reemplaza el razonamiento de llamada de herramientas
Un servidor MCP generalmente no decide por sí solo qué herramienta debe utilizar el modelo para satisfacer la intención del usuario. Describe y ofrece capacidades. La conductora y la modelo siguen participando en la selección y orquestación.
También es incorrecto tratar a MCP como “un catálogo de funciones”. Las herramientas son una parte importante, pero el protocolo incluye recursos e indicaciones, así como funciones para descubrimiento, transporte, autorización y otras interacciones entre el host, el cliente y el servidor. Esta amplitud es una de las razones por las que MCP tiene sentido como protocolo y no sólo como convención de esquema.
La llamada a funciones no resuelve la portabilidad por sí sola
La definición de una función en el esquema JSON puede ser muy similar entre proveedores, pero la forma de registrar herramientas, recibir llamadas, devolver resultados, solicitar aprobación y mantener el ciclo de ejecución varía según la API. Un equipo puede escribir adaptadores para cada plataforma y esto puede ser perfectamente aceptable en un producto cerrado.
MCP intenta colocar la integración externa detrás de un contrato común. Un servidor puede exponer la misma capacidad y consumirla en diferentes hosts. Esto reduce el acoplamiento en escenarios de gran cantidad de clientes, pero agrega una capa operativa que debe justificarse.
Matriz de decisión: compara la capa que realmente cambia
Portabilidad
La llamada a funciones simples tiende a estar asociada a la forma en que la aplicación o el proveedor define y entrega las herramientas. Es una buena opción cuando el producto controla ambos extremos y no es necesario reutilizar la integración en varios hosts.. MCP es más atractivo cuando diferentes aplicaciones, agentes o proveedores deben consumir la misma capacidad, porque existe un protocolo común entre el host y el servidor.
Descubrimiento dinámico
En la llamada a función tradicional, la aplicación envía un conjunto conocido de herramientas al modelo. Las API modernas pueden cargar herramientas bajo demanda con sus propios mecanismos, por lo que este límite se ha vuelto menos rígido. MCP, sin embargo, estandariza el descubrimiento de capacidades a nivel de servidor. El cliente puede consultar lo que ofrece el servidor y reaccionar a los cambios sin que cada herramienta tenga que estar codificada individualmente en el host.
Ejecución
En funciones controladas por el cliente, el modelo solicita la llamada y la aplicación la ejecuta. Esto le brinda control directo sobre el código, las redes y el manejo de errores. Con MCP, la ejecución normalmente pertenece al servidor MCP, aunque la conexión puede ser local vía stdio o remota vía HTTP. Algunas plataformas también ejecutan el acceso MCP como herramienta alojada, lo que reduce la carga de trabajo del cliente. Entonces, "¿dónde corre?" debe ser respondido por la implementación concreta, no por el nombre de la técnica.
Autenticación y aprobación
La llamada a función define la intención estructurada de la llamada, pero no autentica mágicamente el servicio externo. La aplicación aún necesita proteger las credenciales, verificar la autorización y decidir cuándo pedir confirmación al usuario. MCP tiene un marco de autorización para transportes HTTP y asigna responsabilidades de consentimiento y políticas al host. Las plataformas que ofrecen MCP alojado también pueden agregar controles de aprobación. En operaciones de escritura o de alto impacto, la existencia del protocolo no elimina la necesidad de un límite humano claro.
Latencia
Una función local puede tener el camino más corto: modelo, aplicación, ejecutor, resultado. Un servidor MCP remoto puede agregar descubrimiento, transporte y otro límite de red. Esto no significa que MCP siempre será más lento. Las listas de descubrimiento y capacidad se pueden almacenar en caché, y la especificación actual introduce señales de caché y mecanismos de notificación para evitar consultas innecesarias. La decisión debe medirse en el flujo real, especialmente cuando la integración remota ya requeriría una API externa de todos modos.
Gobernanza
La llamada a funciones le da a la aplicación un punto explícito para validar argumentos, aplicar listas permitidas, registrar llamadas y bloquear acciones. MCP amplía la superficie de gobernanza porque el host puede controlar qué servidores y herramientas están expuestos, mientras que cada servidor mantiene su propia política y autenticación. En entornos de varios equipos, esta separación puede ayudar; en un sistema pequeño, puede aumentar la complejidad sin un retorno proporcional.
Cuándo usar solo llamadas a funciones
Elija una solución centrada en llamadas a funciones cuando las herramientas sean pocas, estables, pertenezcan a su aplicación y no necesiten ser reutilizadas en varios hosts. También tiene sentido cuando la ejecución debe permanecer estrictamente dentro de su backend y desea minimizar las capas de protocolo.
Una buena señal es poder responder claramente: “estas funciones solo existen para este agente, este producto controla al ejecutor y cualquier herramienta nueva será agregada por el mismo equipo”. En este escenario, MCP puede ser una abstracción prematura.
Cuando MCP vale la pena
MCP comienza a ser más atractivo cuando hay muchas integraciones, cuando diferentes equipos o empresas mantienen los servidores de capacidad, cuando las herramientas deben descubrirse dinámicamente o cuando la misma integración debe funcionar en múltiples hosts de IA.
También es útil cuando el dominio implica más que acciones. Un servidor que ofrece recursos de contexto, plantillas de mensajes y herramientas bajo el mismo protocolo está resolviendo un problema mayor que las llamadas a funciones por sí solas.
Cuándo usar ambos
Utilice una arquitectura híbrida cuando algunas capacidades sean locales y específicas del producto, mientras que otras provienen de servidores MCP reutilizables. El agente puede contar con funciones nativas para operaciones internas de baja latencia y al mismo tiempo acceder a herramientas MCP de socios, bases de datos, sistemas empresariales o servicios especializados.
La documentación actual de los principales ecosistemas muestra esta coexistencia de diferentes maneras. OpenAI le permite combinar MCP remoto con otras herramientas en la misma solicitud. Anthropic ofrece uso de herramientas y un conector MCP para servidores remotos. El SDK de Gemini puede conectar una sesión de MCP al motor de herramientas y realizar llamadas en bucle automáticamente en escenarios compatibles. Esto refuerza la lectura arquitectónica: MCP y la llamada a funciones son piezas que pueden encajar, no sustitutos obligatorios.
El error arquitectónico más común
El error más común es elegir en función de la novedad de la tecnología, y no por la frontera que hay que estandarizar. Si el problema es simplemente permitir que el modelo llame a tres funciones desde su backend, comience con el mecanismo de herramientas de la plataforma. Si el problema es distribuir una integración reutilizable a múltiples hosts, descubrir capacidades y reducir adaptadores específicos, MCP resuelve una necesidad concreta.
El segundo error es suponer que MCP transfiere automáticamente la seguridad y la gobernanza al protocolo. No se transfiere. El host aún necesita decidir qué expone al modelo, el usuario debe tener control sobre las acciones confidenciales y el servidor debe autenticar y autorizar lo que ejecuta. La especificación MCP exige explícitamente el consentimiento, los límites de seguridad y la posibilidad de negar las invocaciones.
Una regla general para decidir
Primero pregunte quién es el propietario de la herramienta y cuántos consumidores independientes tendrá. Si la respuesta es "mi aplicación, un solo agente", la llamada a funciones tiende a ser suficiente. Si la respuesta es "una capacidad compartida por múltiples hosts o clientes", MCP merece una evaluación. Si hay herramientas de ambos tipos en el mismo producto, no fuerce una sola opción: mantenga las funciones locales donde sean más simples y use MCP donde la portabilidad y la capacidad de descubrimiento justifiquen la capa adicional.
Luego, mida lo que realmente cambia: cantidad de adaptadores, tiempo para agregar una integración, costo de autenticación, latencia, facilidad de aprobación, trazabilidad y mantenimiento. La arquitectura correcta no es la que utiliza más protocolos; es el que sitúa cada responsabilidad en la capa adecuada.
