"¿Por qué usaría MCP si el servicio ya tiene una API?" es la pregunta que más recibimos de los desarrolladores que consultan nuestro directorio por primera vez. Es una pregunta válida, y la respuesta es corta: no usarías MCP en lugar de la API. Lo usarías sobre la API, para un tipo de cliente muy específico.
Ese cliente es un modelo de IA. Una vez que comprendes lo que un modelo necesita y que un programa normal no requiere, la diferencia entre MCP y una API deja de ser confusa. Esta guía te lo explica con un ejemplo concreto, una tabla comparativa y los casos en los que deberías omitir MCP por completo.
Puntos clave
- MCP no reemplaza a una API. La mayoría de los MCP servers son una capa ligera sobre una API que ya existe.
- La diferencia es el cliente: una API sirve a código escrito por un desarrollador; MCP sirve a un modelo que descubre herramientas en tiempo de ejecución.
- El function calling es la parte orientada al modelo; MCP estandariza cómo se describen, encuentran y acceden a las herramientas a través de distintas aplicaciones.
- Usa la API directamente cuando ningún modelo tome decisiones; usa function calling para una funcionalidad específica en una sola aplicación; usa MCP cuando muchas aplicaciones o agentes necesiten la herramienta.
La respuesta en un párrafo
Una API, ya sea REST, GraphQL o gRPC, es la forma en que un software le pide algo a otro. Se asume que quien realiza la llamada ya sabe a qué endpoint dirigirse, qué enviar y cómo autenticarse, porque un desarrollador escribió ese código. MCP es un protocolo para que las aplicaciones de IA descubran herramientas en tiempo de ejecución y las llamen en nombre de un modelo. Un MCP server publica una lista de herramientas con descripciones en lenguaje natural y esquemas de entrada; el modelo elige una y el servidor realiza las llamadas a la API correspondientes. La mayoría de los MCP servers que encontrarás en HostedMCP son exactamente eso: una capa ligera sobre una API que ya existía.
Un ejemplo concreto: reembolsos en Stripe
Imagina que quieres que un asistente de IA gestione la tarea "reembolsa el último cargo de este cliente".
Usando solo la API, alguien tiene que escribir esa integración para el asistente. Define un esquema de función que el modelo entienda, con nombres y descripciones. Gestiona la API key. Busca al cliente, lista los cargos, selecciona el más reciente, crea el reembolso y convierte los códigos de error de Stripe en algo sobre lo que el modelo pueda actuar. Después, lo despliega dentro de una aplicación. Cuando el equipo de soporte quiere lo mismo en Claude y los desarrolladores lo quieren en Cursor, ese trabajo se repite, en un formato distinto y en una base de código diferente.
Con MCP, ese código de integración se traslada a un único servidor. Este anuncia herramientas como list_charges y create_refund, con descripciones escritas para un modelo. El servidor gestiona la clave o el token de OAuth. Cualquier cliente MCP, ya sea Claude, Cursor, ChatGPT o VS Code, puede conectarse a él y obtener el mismo comportamiento. La API de Stripe no cambió en absoluto. Lo que cambió es quién tiene que escribir las partes específicas para la IA y cuántas veces se hace.
Comparativa
| API tradicional | MCP | |
|---|---|---|
| Quién la llama | Código escrito por un desarrollador | Un modelo de IA, a través de una app host |
| Cómo el cliente descubre qué hay disponible | Leyendo documentación en tiempo de compilación | Preguntándole al servidor en tiempo de ejecución (tools/list) |
| Las descripciones están escritas para | Desarrolladores | Modelos: qué hace la herramienta y cuándo usarla |
| Formato de mensajes | Varía: REST, GraphQL, gRPC | JSON-RPC 2.0 para cada servidor |
| Auth | API keys, OAuth, lo que el servicio elija | Env vars para servidores locales, OAuth 2.1 para remotos |
| Alcance de las acciones | Todo lo que la API expone | Solo las herramientas que el servidor decide ofrecer |
| Una integración funciona en | Una sola app | Todos los clientes MCP |
| Latencia típica | Un salto de red | Un salto extra a través del servidor |
Dos filas merecen más atención de la que suelen recibir.
El descubrimiento es la verdadera diferencia. Un programa que llama a una API nunca pregunta "¿qué puedes hacer?" en tiempo de ejecución; el desarrollador ya lo sabía. Un modelo sí necesita preguntar, en cada sesión, y necesita la respuesta en palabras con las que pueda razonar. Por eso, la descripción de una herramienta MCP se lee como un consejo ("Usa esto para encontrar pull requests abiertos que afecten a una ruta específica") en lugar de como documentación de referencia.
El alcance es una función de seguridad. Una API key para un servicio suele otorgar todo lo que esa clave tiene permitido hacer. Un MCP server decide qué acciones existen siquiera. Un servidor de analíticas de solo lectura puede simplemente no incluir una herramienta delete. No puedes obtener la misma garantía diciéndole a un modelo "por favor, no borres nada".
MCP vs function calling
El function calling, o uso de herramientas (tool use) como lo llaman algunos proveedores, es una funcionalidad de la API de un modelo: enumeras funciones en tu solicitud y el modelo puede responder con un "llama a esta función con estos argumentos". A menudo se confunde con MCP porque, al final, MCP lo utiliza.
Así es como encajan ambos. Tu aplicación host, por ejemplo Claude Code, se conecta a los MCP servers y recopila sus herramientas. Cuando envía una solicitud al modelo, pasa esas herramientas como definiciones de funciones. Cuando el modelo pide llamar a una, el host redirige esa llamada al MCP server correspondiente y le devuelve el resultado. Por lo tanto, el function calling es la parte orientada al modelo, y MCP es el estándar para todo lo que ocurre al otro lado: cómo se describen, descubren, autorizan y alcanzan las herramientas entre distintos proveedores.
Si estás construyendo una sola funcionalidad, en una sola aplicación y con un solo modelo, el function calling simple requiere menos trabajo y es perfectamente válido. MCP vale la pena cuando la misma herramienta debe funcionar en muchas aplicaciones o cuando quieres que los usuarios utilicen su propio cliente de IA.
| Function calling | MCP | |
|---|---|---|
| Qué es | Una funcionalidad de una API de modelo | Un protocolo entre aplicaciones de IA y servidores de herramientas |
| Dónde se definen las herramientas | En la solicitud de tu app al modelo | En un servidor separado al que cualquier cliente puede conectarse |
| Funciona en | La aplicación que escribiste | Cualquier cliente MCP |
| Descubrimiento | Pasas la lista en cada solicitud | El cliente le pregunta al servidor en tiempo de ejecución |
| Ideal para | Una funcionalidad, una app, un modelo | Herramientas compartidas entre apps, agentes y proveedores |
Cuándo elegir una API
No uses MCP cuando no haya un modelo de por medio. Un frontend web, una app móvil, un proceso de sincronización nocturna o una integración con un partner deben comunicarse directamente con tu API. Añadir una capa de MCP en esos casos no aporta nada y solo añade un salto adicional.
No lo uses cuando necesites un control preciso sobre cada llamada. Las capturas de pagos, los borrados masivos o cualquier proceso donde prefieras una ruta de código escrita por un humano con tests y pistas de auditoría, deben ir en el código normal que llama a la API, incluso si una IA te ayudó a escribir ese código.
Y no lo uses cuando el modelo solo necesite datos que ya tienes a mano. Si tu app obtiene el registro de un cliente y lo pega en el prompt, eso no es una herramienta, es contexto, y no necesita un servidor.
| Situación | Uso |
|---|---|
| Un frontend web o móvil llama a tu backend | La API |
| Una sincronización nocturna o integración con un partner | La API |
| Pagos, borrados masivos o cualquier cosa que requiera auditoría | La API, desde código testeado |
| Tu app ya tiene los datos y los pega en el prompt | Ninguna; eso es contexto, no una herramienta |
| Una función de IA dentro de una app que tú controlas | Function calling |
| Un modelo debe decidir qué buscar o qué hacer | MCP |
| Tus clientes usan Claude, Cursor y ChatGPT | MCP, idealmente un servidor hosted |
| Varios agentes internos necesitan el mismo sistema | Un MCP server compartido |
Cuándo elegir MCP
Usa MCP cuando un modelo deba decidir qué hacer. Los agentes que buscan información, abren tickets, consultan bases de datos o verifican un despliegue necesitan herramientas, y MCP es el estándar para proporcionárselas.
También es la opción correcta si quieres que tu producto funcione en las herramientas de IA de otras personas. Si tus clientes usan Claude, Cursor y ChatGPT, un solo MCP server les sirve a todos. Por eso empresas como GitHub, Linear, Notion y Stripe publican los suyos. En HostedMCP puedes explorar servidores oficiales por producto y ver cuáles están alojados frente a los que se ejecutan localmente.
Además, es de gran ayuda cuando gestionas varios agentes internamente. Tener un MCP server por sistema, compartido por cada agente, es mucho más fácil de asegurar y actualizar que copiar el código de las herramientas en cada agente.
La seguridad también es distinta
Las API y los MCP server enfrentan amenazas diferentes, principalmente porque hay un modelo en el proceso.
Con una API, quien realiza la llamada es tu código y hace lo que tú escribiste. Con MCP, quien realiza la llamada es un modelo que lee texto no confiable: páginas web, correos electrónicos o comentarios en issues. Un comentario en un issue cuidadosamente redactado puede intentar convencer al modelo para que llame a una herramienta que no debería. Eso es prompt injection, y es la razón por la que los buenos hosts piden confirmación antes de ejecutar herramientas que modifican datos, y por la que los servidores deben exponer el conjunto más pequeño y útil de herramientas.
La especificación de MCP también es estricta con los tokens. Bajo sus mejores prácticas de seguridad, un servidor no debe aceptar tokens que no hayan sido emitidos para ese servidor, y no debe pasar el token de un usuario a otro servicio. Este antipatrón tiene un nombre, token passthrough, y es una de las primeras cosas que vale la pena revisar en el código de un servidor antes de confiar en él. Para servidores remotos, la autorización sigue OAuth 2.1, y la revisión del 2026-07-28 traslada el registro de clientes a Client ID Metadata Documents. Puedes encontrar más información en nuestra guía de seguridad de MCP.
Atención
Trata cada argumento que reciba una herramienta de MCP como una entrada no confiable. El modelo que la eligió pudo haber leído una página web o un comentario en un issue diseñado para manipularlo.
Rendimiento y costo
A veces existe la preocupación de que MCP sea lento. Un servidor local añade una llamada a un proceso en la misma máquina, y un servidor remoto añade un viaje de ida y vuelta por HTTP. Ambos son insignificantes comparados con los segundos que un modelo tarda en redactar su respuesta.
El costo que realmente importa es el contexto. Cada herramienta que el host carga incluye una descripción y un esquema que el modelo debe leer, y cada resultado de herramienta se integra en la conversación. Un servidor con ochenta herramientas muy detalladas puede consumir una parte considerable de la ventana de contexto incluso antes de que hayas preguntado nada. Esa es una de las razones por las que mostramos la lista completa de herramientas en cada página de servidor en HostedMCP: puedes ver qué tan grande es un servidor antes de instalarlo y elegir uno más pequeño si un servidor especializado hace el trabajo.
Cómo convertir una API en un buen MCP server
El atajo tentador es generar una herramienta por cada endpoint a partir de un archivo OpenAPI. Existen herramientas que hacen exactamente eso, y son útiles para un prototipo rápido. Sin embargo, rara vez logran crear un buen servidor. Si abres algunos listados con cientos de herramientas casi idénticas, verás el problema: el modelo tiene que leer cada una de ellas, y la mayoría corresponden a endpoints que nadie pediría en una conversación.
Un modelo no piensa en endpoints. Piensa en tareas. "Busca al cliente que envió un correo sobre la factura 1042 y muéstrame sus últimos tres cargos" es una tarea que abarca varios endpoints. Un buen servidor ofrece herramientas a ese nivel: find_customer que acepte un email, un número de factura o un nombre, y recent_charges que devuelva un resumen corto y legible en lugar del JSON crudo con cuarenta campos.
| Herramienta basada en endpoints | Herramienta basada en tareas |
|---|---|
GET /customers?email= |
find_customer que acepta un email, número de factura o nombre |
GET /charges?customer= que devuelve 40 campos |
recent_charges que devuelve un resumen corto y legible |
| Una herramienta por endpoint, cientos en total | Un puñado de herramientas que coinciden con lo que la gente pide |
| Descripciones copiadas de la documentación de referencia | Descripciones que indican cuándo usar la herramienta |
Algunos hábitos marcan una gran diferencia.
-
Escribe descripciones para el modelo. Explica para qué sirve la herramienta y cuándo usarla, no solo qué devuelve. "Usa esto antes de crear un reembolso para confirmar que el cargo pertenece al cliente" es más útil para un modelo que una lista de campos.
-
Devuelve menos información. Recorta las respuestas a los campos que una persona realmente consultaría y utiliza paginación con un cursor claro. Cada campo extra consume contexto y le da al modelo más elementos que puede interpretar mal.
-
Haz que las herramientas peligrosas sean obvias. Nómbralas claramente, como
delete_project, y utiliza las indicaciones de lectura o de acción destructiva que proporciona la especificación, para que los hosts puedan solicitar confirmación. Mejor aún, deja las acciones destructivas fuera de la primera versión. -
Valida todo. Los argumentos provienen de un modelo que leyó texto no confiable. Verifica tipos, rangos y propiedad en el servidor, de la misma manera que lo harías para cualquier endpoint público.
Entonces, ¿cuál deberías construir?
Si aún no tienes una API, construye la API primero. Tu propia aplicación, tus scripts y tus socios la necesitarán de todos modos, y un MCP server sin una API sólida que lo respalde tiende a convertirse en una segunda API, y peor todavía.
Si ya tienes una API y quieres que las herramientas de IA utilicen tu producto, añade un MCP server frente a ella. Empieza con un puñado de herramientas que coincidan con lo que la gente pide realmente, escribe descripciones pensadas para un modelo en lugar de para un desarrollador, y ofrécelo tanto como un paquete local como un endpoint alojado si puedes. Nuestra guía para construir un MCP server te explica el proceso paso a paso en TypeScript y Python con los SDK actuales.
Si solo necesitas una función de IA dentro de una aplicación que tú controlas, hoy en día basta con el function calling, y más adelante puedes convertir esas funciones en un MCP server sin necesidad de cambiar la API subyacente.
Qué hacer a continuación
Para ver cómo funciona esto en la práctica, abre algunos servidores que envuelvan APIs conocidas, como el GitHub server o cualquiera de los Postgres servers, y compara sus listas de herramientas con la documentación de la API subyacente. Notarás cuánto omiten, y lo hacen a propósito. Si eres nuevo en el protocolo, empieza por qué es MCP, y si solo quieres probar uno, nuestras guías de clientes muestran la configuración exacta para tu editor.