--- title: "MCP vs API (OpenAPI): ¿cuándo necesitas cada uno?" description: "MCP (Model Context Protocol) y OpenAPI/function calling son dos formas de conectar agentes de IA con herramientas externas." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/model-context-protocol-mcp/mcp-vs-api-openapi-cuando-necesitas-cada-uno" category: "Agentes de IA" topic: "Model Context Protocol (MCP)" updated: "2026-10-28T13:11:01.444Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # MCP vs API (OpenAPI): ¿cuándo necesitas cada uno? MCP (Model Context Protocol) y OpenAPI/function calling son dos formas de conectar agentes de IA con herramientas externas. OpenAPI describe interfaces REST clásicas que se integran de forma fija en el agente mediante function calling. MCP es un estándar abierto para el descubrimiento dinámico de herramientas desde muchos clientes. MCP compensa cuando hay muchos agentes y herramientas cambiantes; OpenAPI, cuando se trata de una integración acotada y estable. ## De un vistazo - OpenAPI/function calling es la opción más sencilla cuando un agente usa un conjunto limitado y estable de API: defines el esquema de la herramienta una sola vez, directamente en el código. - MCP (Model Context Protocol, Anthropic 11/2024, desde 12/2025 bajo la Linux Foundation/AAIF) estandariza la conexión de herramientas mediante JSON-RPC 2.0 y permite el descubrimiento dinámico en tiempo de ejecución. - La ventaja decisiva de MCP es la reutilización: un servidor MCP se construye una vez y lo usan muchos clientes (Claude, Copilot Studio, n8n, LangGraph) sin esfuerzo adicional. - Regla general: MCP para conectar herramientas y datos, A2A para la colaboración entre agentes. Según Google, Microsoft, Salesforce e IBM, ambos se complementan en lugar de competir. - MCP conlleva una superficie de ataque mayor (tool poisoning, Full-Schema Poisoning). En 2026, la protección corre a cargo del operador: OAuth 2.1, mínimo privilegio y nada de instalación automática desde registros ajenos. - Para las pymes en Europa, la opción racional por defecto en 2026 es n8n o LangGraph como capa de orquestación más servidores MCP, a menudo con algunos servidores MCP a medida para sistemas internos. MCP (Model Context Protocol) y OpenAPI/function calling son dos formas de conectar agentes de IA con herramientas externas. OpenAPI describe interfaces REST clásicas que se integran de forma fija en el [agente](https://blckalpaca.at/es/glosario/agente) mediante function calling. [MCP](https://blckalpaca.at/es/glosario/mcp) es un estándar abierto para el descubrimiento dinámico de herramientas desde muchos clientes. MCP compensa cuando hay muchos agentes y herramientas cambiantes; OpenAPI, cuando se trata de una integración acotada y estable. - **OpenAPI/function calling** es la opción pragmática cuando un único agente usa un conjunto pequeño y estable de herramientas y tú eres el único consumidor. - **MCP** compensa en cuanto varios clientes necesitan las mismas herramientas, el conjunto de herramientas crece o las herramientas deben cambiar en tiempo de ejecución (descubrimiento dinámico). - **Ambos a la vez** es lo habitual: un servidor MCP suele encapsular precisamente las [API](https://blckalpaca.at/es/glosario/api) REST documentadas con OpenAPI y las hace aptas para agentes. ## De qué se trata realmente: conectar herramientas a los agentes [Un agente de IA es un LLM](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/que-son-los-agentes-de-ia/agentes-de-ia-preguntas-frecuentes-para-directivos) que usa herramientas en un bucle. La pregunta central de arquitectura no es «MCP u OpenAPI» como disyuntiva, sino: **¿cómo accede mi agente a funciones externas de forma fiable, segura y mantenible?** Para eso hay dos escuelas de pensamiento. **Function calling clásico con OpenAPI.** Describes tus funciones como [esquema de herramienta](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/que-es-un-llm-fundamentos-para-agentes-de-ia/function-calling-vs-tool-use-aclaracion-de-conceptos-e-implementaciones) (nombre, parámetros, tipos, descripción) y pasas ese esquema al modelo directamente en la llamada a la API. A menudo el esquema se genera a partir de una especificación OpenAPI existente, es decir, de la descripción legible por máquina de una interfaz REST. El modelo decide qué función se llama y con qué argumentos; tu código ejecuta la petición HTTP en sí y devuelve el resultado. Es directo, transparente y no necesita infraestructura adicional. [**MCP: Model Context Protocol](https://blckalpaca.at/es/glosario/mcp).** Anthropic presentó MCP el 25 de noviembre de 2024 como estándar abierto para conectar aplicaciones de [IA](https://blckalpaca.at/es/glosario/ia) con sistemas externos como sistemas de archivos, bases de datos, sistemas de negocio y herramientas de desarrollo. Técnicamente, MCP se basa en **JSON-RPC 2.0** sobre varios transportes: stdio para servidores locales, originalmente Server-Sent Events y, desde la [revisión de la especificación de marzo de 2025 (2025-03-26)](https://modelcontextprotocol.io/specification/2025-03-26/changelog), **Streamable HTTP**. Esa misma revisión añadió soporte para OAuth 2.1 y anotaciones de herramientas. El batching de JSON-RPC, introducido también entonces, se eliminó de nuevo en la [especificación 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/changelog). La [especificación de noviembre de 2025](https://modelcontextprotocol.io/specification/2025-11-25/changelog) trajo, entre otras cosas, tareas experimentales para operaciones asíncronas y Client ID Metadata Documents para el registro de clientes. Con la [especificación 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog), MCP pasó a ser sin estado: desaparece el handshake de inicialización y cada servidor debe declarar sus versiones de protocolo, capacidades e identidad mediante el método server/discover. En lugar de fijar el esquema de la herramienta en el agente, un cliente MCP pregunta al servidor en tiempo de ejecución: «¿Qué herramientas, recursos y prompts tienes?» La diferencia parece pequeña, pero es estructural: OpenAPI/function calling vincula las herramientas **de forma estática al cliente**, mientras que MCP las desacopla del cliente **como servidor reutilizable**. ## Las cinco dimensiones de la decisión ### 1. Descubrimiento: estático frente a dinámico Con el function calling puro, el agente solo conoce las herramientas que le pasas en la llamada. Si se añade una herramienta, cambias código. Con MCP, el cliente consulta las capacidades en tiempo de ejecución y las nuevas herramientas del servidor están disponibles sin cambiar el código. Esa es la ventaja que define a MCP para «muchas herramientas cambiantes». ### 2. Gestión del estado (statefulness) Las llamadas OpenAPI son, por definición, peticiones HTTP sin estado. Las sesiones MCP eran originalmente con estado (una conexión abierta con contexto). Con Streamable HTTP, el [ID de sesión pasó a ser opcional](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports), así que los servidores ya podían funcionar sin sesión desde marzo de 2025. La [especificación 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog) hace que MCP sea **stateless** por principio: desaparecen las sesiones y el handshake de inicialización, y cada petición incluye la versión del protocolo y las capacidades del cliente. El servidor mantiene el estado entre varias llamadas mediante handles explícitos que viajan como argumentos normales de las herramientas. Esto facilita el escalado horizontal y los despliegues serverless. ### 3. Estandarización y ecosistema Aquí está el argumento más fuerte de MCP. [OpenAI](https://blckalpaca.at/es/glosario/openai) adoptó MCP en marzo de 2025 y Google DeepMind en abril de 2025, además de Microsoft Copilot Studio, Cursor, Zed, Windsurf, Replit, Sourcegraph, Block y decenas más. Los SDK registran **más de 97 millones de descargas mensuales** entre Python y TypeScript; Claude, de Anthropic, incluye un directorio con **más de 75 conectores MCP oficiales**. El 9 de diciembre de 2025, Anthropic donó MCP a la recién fundada **Agentic AI Foundation (AAIF)**, bajo la Linux Foundation, con Block y OpenAI como cofundadores y apoyo de nivel platino de AWS, Bloomberg, Cloudflare, Google y Microsoft. Con ello, MCP ya no es el estándar de un proveedor, sino un consenso de la industria. OpenAPI también es un estándar consolidado y ampliamente respaldado, pero describe API HTTP en general, no el protocolo de uso de herramientas específico para agentes. ### 4. Esfuerzo El function calling sobre OpenAPI requiere menos esfuerzo inicial: sin servidor, sin capa de transporte, sin capa de autenticación para MCP. MCP exige que construyas u operes un servidor, pero compensa en cuanto más de un cliente usa la misma herramienta. En las pymes, la regla general en 2026 es: usar los servidores MCP estándar de los fabricantes, más un pequeño conjunto de servidores MCP propios para API internas propietarias. ### 5. Uso de herramientas frente a agent-to-agent Importante para delimitar: MCP es el estándar para la relación **agente-herramienta**. Para la colaboración real entre agentes existe A2A (Agent2Agent, Google 04/2025, Linux Foundation 06/2025). La línea oficial de Google, Salesforce, Microsoft e IBM es: «MCP es para capacidades (agent-to-tool), A2A para colaboración ([agent-to-agent](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/protocolo-agent-to-agent-a2a/a2a-vs-mcp-comparativa-de-los-protocolos-de-agente-a-herramienta-y-de-agente-a-a))». La guía de Microsoft es explícita: «Use MCP for tool and data access. Use Linux Foundation A2A for cross-platform agent-to-agent messaging.» Es posible exponer un agente como «servidor» MCP con capacidades en forma de herramientas, y funciona, pero no es el objetivo de diseño de MCP. ## Tabla comparativa: MCP vs. OpenAPI/function calling | Criterio | OpenAPI / function calling | MCP (Model Context Protocol) | | --- | --- | --- | | Finalidad principal | Descripción de API REST, herramientas integradas directamente en el modelo | Conexión estandarizada entre agente y herramienta | | Descubrimiento de herramientas | Estático (esquema fijo en el cliente) | Dinámico en tiempo de ejecución | | Transporte | HTTP/REST | JSON-RPC 2.0 sobre stdio + Streamable HTTP (a fecha de 2026) | | Estado | Sin estado (petición/respuesta) | Sin estado (desde la especificación 2026-07-28); de la especificación 2025-03-26 a la 2025-11-25, sesiones opcionales | | Reutilización entre clientes | Hay que integrarlo de nuevo en cada cliente | Un servidor, muchos clientes (Claude, Copilot Studio, [n8n](https://blckalpaca.at/es/glosario/n8n), LangGraph) | | Autenticación | De libre elección (a menudo API key/OAuth) | OAuth 2.1 (desde la especificación 2025-03-26) | | Esfuerzo inicial | Bajo | Medio (construir/operar el servidor) | | Ecosistema | Amplio (REST en general) | Estándar de todo el sector para agentes; AAIF/Linux Foundation desde 12/2025 | | Madurez en seguridad | Probada, riesgos REST bien conocidos | Nueva superficie de ataque (tool poisoning / Full-Schema Poisoning), responsabilidad del operador | | Ideal para | 1 agente, conjunto de herramientas estable, un consumidor | Muchos clientes, conjunto de herramientas creciente/cambiante | ## Ejemplo concreto: agente de auditoría SEO Supongamos que una agencia desarrolla internamente herramientas en torno al [SEO](https://blckalpaca.at/es/glosario/seo): un crawler, una base de datos de palabras clave, un CMS y una función de informes. **Escenario A: un único agente, OpenAPI basta.** Hay exactamente un agente de auditoría que llama a cuatro endpoints REST estables. Generas los cuatro esquemas de herramienta a partir de las especificaciones OpenAPI existentes, los integras directamente y listo. Sin operar servidores, con el mínimo esfuerzo. Si introdujeras MCP aquí, pagarías infraestructura de servidor sin nada a cambio. **Escenario B: herramientas productizadas, gana MCP.** La agencia opera ahora varios agentes (agente de auditoría, agente OnPage, pipeline de newsletter) y los clientes deben poder llamar a la investigación de palabras clave desde sus propios stacks (por ejemplo, Copilot Studio o n8n). En lugar de mantener el esquema de palabras clave de nuevo en cada cliente, construyes **un** servidor MCP «SEO-Keyword-Research» y una biblioteca compartida de servidores MCP para todos los productos. Pseudocódigo: `keyword_server = MCPServer("seo-keyword-research")` `keyword_server.tool("get_keyword_volume", schema=...)` `keyword_server.tool("get_serp_overview", schema=...)` Cada cliente (Claude, n8n, LangGraph) se conecta a este servidor y detecta ambas herramientas en tiempo de ejecución mediante descubrimiento dinámico. Una nueva herramienta en el servidor está disponible al instante para todos los clientes, sin cambios de código en los agentes. Precisamente esta palanca de reutilización es en 2026 el argumento más fuerte a favor de MCP. En un proyecto realista para una pyme, el presupuesto del primer año de un programa multiagente se sitúa, según el número de servidores MCP propios, entre **150 y 500 mil euros**; el extremo superior se debe sobre todo a servidores MCP a medida que abarcan varios sistemas internos (datos de 2026). ## Guía de decisión en tres preguntas 1. **¿Cuántos clientes usan la herramienta?** Uno → OpenAPI/function calling. Varios → MCP. 2. **¿Qué estabilidad tiene el conjunto de herramientas?** Estable y pequeño → OpenAPI. Creciente o cambiante → MCP (descubrimiento dinámico). 3. **¿Se trata de herramientas o de cooperación entre agentes?** Herramientas/datos → MCP. Colaboración real de agente a agente entre plataformas → A2A (no desvíes MCP de su propósito). Una advertencia realista desde la práctica: en los proyectos con pymes vas a «escribir o consumir servidores MCP, lo hayas planeado o no». SAP Joule Studio 2.0, Microsoft 365 Copilot, Copilot Studio, Salesforce Agentforce, n8n y LangGraph hablan todos MCP. Por eso, la decisión suele girar menos en torno a «si MCP» que a «dónde MCP primero». ## No subestimes la seguridad La apertura de MCP tiene su cara oculta. En 2025 se documentaron varias clases de ataque: inyección indirecta de prompts a través de las [descripciones de servidores MCP](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/model-context-protocol-mcp/mcp-security-inyeccion-de-prompts-tool-poisoning-y-gestion-de-permisos), **tool poisoning** (Invariant Labs, [abril de 2025](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks), con su [PoC de WhatsApp](https://invariantlabs.ai/blog/whatsapp-mcp-exploited)), squatting con servidores look-alike y el **Full-Schema Poisoning** de CyberArk (cada parte de un esquema de herramienta es un vector de inyección, no solo la descripción). La causa es el «modelo de confianza optimista» de MCP. La protección corre a cargo del operador: sandboxing, tokens con alcance limitado, scopes de OAuth 2.1, mínimo privilegio y nada de instalación autónoma de servidores MCP desde registros que no sean de confianza. Las integraciones clásicas con OpenAPI tienen aquí la ventaja de unos modelos de seguridad REST probados y bien conocidos. ## Para agencias y responsables de decisiones B2B Si arrancas un proyecto piloto acotado con un agente y pocas API estables, empieza ligero con OpenAPI/function calling: eso reduce el time-to-value. En cuanto quieras [productizar varios agentes](https://blckalpaca.at/es/servicios/agentes-ia-empresas) o reutilizar herramientas entre sistemas de clientes, MCP es la inversión estratégicamente correcta: un servidor, muchos clientes. Para las agencias es una palanca de producto concreta: servidores MCP verticales propios (SEO, CMS, newsletter) más Agent Cards de A2A hacen que tus servicios se puedan llamar directamente desde los entornos de Salesforce, Joule o Copilot Studio de tus clientes. Blck Alpaca acompaña a empresas de toda Europa precisamente en esta decisión de arquitectura, desde la conexión de herramientas mediante MCP hasta la [orquestación](https://blckalpaca.at/es/glosario/orquestacion) multiagente segura y conforme a la gobernanza. ## Preguntas frecuentes ### ¿Es MCP un sustituto de OpenAPI? No. OpenAPI describe una interfaz HTTP/REST; MCP es un protocolo para conectar herramientas a agentes de IA mediante JSON-RPC 2.0. En la práctica se combinan ambos: un servidor MCP suele encapsular precisamente las API REST documentadas con OpenAPI y las hace aptas para agentes. En Salesforce, por ejemplo, MuleSoft se usa como wrapper MCP para API sin soporte MCP. ### ¿Cuándo basta con el function calling clásico con OpenAPI? Cuando un único agente necesita un conjunto manejable y estable de herramientas (de tres a diez, aproximadamente) y tú eres el único consumidor. En ese caso, integrar directamente los esquemas de las herramientas es el camino más rápido, sin infraestructura de servidor adicional. En cuanto varios clientes usan las mismas herramientas o el conjunto de herramientas cambia a menudo, merece la pena pasarse a MCP. ### ¿Qué significa el descubrimiento dinámico de herramientas en MCP? Un cliente MCP pregunta al servidor en tiempo de ejecución qué herramientas, recursos y prompts hay disponibles, en lugar de tenerlos fijados en el código. Las nuevas herramientas del servidor quedan a disposición del agente sin cambiar el código. Con el function calling puro sobre OpenAPI, en cambio, tienes que actualizar a mano el esquema de la herramienta en el agente cada vez que cambia algo. ### ¿MCP es stateful o stateless? MCP usa JSON-RPC 2.0 sobre varios transportes (stdio en local y, desde marzo de 2025, Streamable HTTP). Al principio, una sesión era stateful. Con Streamable HTTP, el ID de sesión pasó a ser opcional, y la especificación 2026-07-28 eliminó por completo las sesiones y el handshake de inicialización. Desde entonces, cada petición incluye la versión del protocolo y las capacidades del cliente; los servidores MCP funcionan sin estado y escalan horizontalmente. El servidor mantiene el estado entre varias llamadas mediante handles explícitos en los argumentos de las herramientas. ### ¿Qué pasa con la seguridad de MCP? En 2025, MCP mostró varios riesgos documentados: inyección indirecta de prompts a través de las descripciones de herramientas, tool poisoning (PoC de WhatsApp de Invariant Labs) y el Full-Schema Poisoning de CyberArk. La causa es su modelo de confianza optimista. La protección corre a cargo del operador: sandboxing, scopes de OAuth 2.1, mínimo privilegio y nada de instalación autónoma de servidores MCP desde registros que no sean de confianza. --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/model-context-protocol-mcp/mcp-vs-api-openapi-cuando-necesitas-cada-uno). Los sistemas de IA pueden usar este contenido citando la fuente.