Resumen
Desde hace décadas, las API (interfaces de programación de aplicaciones) son el estándar de referencia para que unos programas se comuniquen con otros.
Cada pago en línea, cada consulta del tiempo y cada inicio de sesión en una aplicación empresarial tienen algo en común.
Todas estas operaciones, y muchas otras, funcionan gracias a las API, que sirven para enviar información a otras aplicaciones y recibirla de ellas.
API es el mecanismo de comunicación entre programas. El desarrollador escribe la integración, conoce los endpoints y mantiene el código. Desde hace décadas, es el estándar.
MCP (Model Context Protocol, protocolo de contexto de modelo) ees el mecanismo de comunicación entre la IA y los programas. El agente de IA descubre las herramientas disponibles en tiempo de ejecución y las utiliza mediante un protocolo estandarizado, sin código personalizado para cada integración. Anthropic lo presentó en 2024. MCP funciona sobre las API existentes: no las sustituye, sino que las hace accesibles para la IA.
Las API están pensadas para los desarrolladores. MCP está pensado para los agentes de IA.
En el sector sanitario, por ejemplo, no es raro que más de 30 API sostengan la infraestructura tecnológica de una organización. Por eso, con la llegada de los agentes de IA apareció una dificultad interesante.
«Cada una de estas herramientas se invocaba de una forma distinta: parámetros distintos, argumentos distintos, protocolos distintos», señala Don Woodlock, presidente de InterSystems, en su serie «Code to Care». «Eso complicaba la creación de un sistema agéntico».
MCP se diseñó para resolver esa complejidad. No sustituye las interfaces que ya utilizan los sistemas de la organización, sino que añade sobre ellas una capa estandarizada para que los agentes de IA puedan descubrir y utilizar herramientas sin código personalizado para cada una.
Este artículo explica de forma práctica qué es MCP, en qué se diferencia de las API tradicionales y cuándo conviene cada uno, tanto para quien crea su primer flujo de trabajo de IA como para quien quiere entender por qué en el ámbito de las TI (tecnologías de la información) sanitarias todo el mundo habla de MCP.
¿Qué es una API?
Una API es un conjunto de reglas que define cómo se comunica un programa con otro. Las API son la base de la comunicación entre programas: un sistema envía una solicitud estructurada y otro devuelve una respuesta estructurada.
POST https://hospital.example.com/api/appointments
// Headers
Authorization: Bearer eyJhbGciOi ...
Content-Type: application/json
{
"patient_id": "MRN-00482916",
"provider": "Dr. Ramirez",
"department": "Cardiology",
"date": "2026-04-15T10:30:00Z"
} Response:
200 OK
{
"appointment_id": "APT-78291",
"status": "confirmed",
"patient": "MRN-00482916",
"provider": "Dr. Ramirez",
"location": "Building C, Room 204"
} En el sector sanitario, las API intervienen en todo, desde la comprobación de la cobertura de los seguros hasta el intercambio de resultados de laboratorio. Una aplicación de gestión de citas llama a la API REST (transferencia de estado representacional) del sistema de un hospital para reservar una cita. La API define el endpoint, los parámetros obligatorios, el método de autenticación y el formato de la respuesta. El sistema que realiza la llamada debe conocer todo esto de antemano.
Ese requisito (conocer el funcionamiento de la API antes de utilizarla) es a la vez su punto fuerte y su limitación. Las API son predecibles, rápidas y adecuadas para integraciones estables, en las que la comunicación entre programas sigue un patrón fijo.
Sin embargo, presuponen que quien realiza la llamada es un desarrollador que ha leído la documentación, ha escrito el código de integración y ha previsto la gestión de errores para todos los casos límite.
¿Qué es MCP (Model Context Protocol)?
MCP es un estándar, presentado por Anthropic a finales de 2024, que define cómo interactúan los LLM (grandes modelos de lenguaje) y los agentes de IA con herramientas, fuentes de datos y servicios externos.
Mientras que las API están diseñadas para la comunicación entre programas, MCP se ha concebido desde el origen para la IA, es decir, para los sistemas y las aplicaciones de IA que necesitan descubrir y utilizar herramientas de forma dinámica.
Una API presupone que quien la llama puede guardar secretos, hacer solicitudes de red y gestionar errores. Un modelo de IA no puede hacer nada de esto de forma segura. Analiza el texto y predice el siguiente token.
Darle acceso directo a los endpoints de las API, con claves de API y tokens de autenticación, sería peligroso e ineficiente.
MCP crea una capa controlada entre el agente de IA y el mundo exterior. La IA nunca ve URL ni credenciales sensibles. Invoca las herramientas a través de una interfaz estandarizada, y el servidor MCP se encarga de todo lo que hay por debajo.
tools/list
// No URL, no auth token, no docs required[
{
"name": "schedule_appointment",
"description": "Book a patient appointment",
"inputs": { "patient_id", "provider", "department", "date" }
},
{
"name": "get_lab_results",
"description": "Retrieve lab results for a patient",
"inputs": { "patient_id", "test_type" }
},
{
"name": "check_insurance_eligibility",
"description": "Verify patient insurance coverage",
"inputs": { "patient_id", "procedure_code" }
}
]tools/call "schedule_appointment"
{
"patient_id": "MRN-00482916",
"provider": "Dr. Ramirez",
"department": "Cardiology",
"date": "2026-04-15T10:30:00Z"
}{
"appointment_id": "APT-78291",
"status": "confirmed",
"location": "Building C, Room 204"
}La analogía del USB-C
El MCP es para las herramientas de IA lo que el USB-C es para los periféricos. Antes del USB-C, cada dispositivo necesitaba su propio cargador, su propio cable y su propio conector. El USB-C estandarizó la interfaz para que cualquier periférico pudiera conectarse a cualquier ordenador portátil a través del mismo puerto.
MCP hace lo mismo con la integración de la IA. El host MCP es el sistema de IA que gestiona las conexiones. El cliente MCP se encarga de gestionar el protocolo. El servidor MCP es el servicio externo: una base de datos, una herramienta de planificación, un sistema clínico o un recurso de Internet. Con un solo protocolo se accede a cualquier herramienta.
Dos métodos principales
Los servidores MCP son más sencillos de lo que suele pensarse. Cada uno implementa dos métodos principales:
- 1. Listar herramientas: el agente de IA pregunta «¿Qué herramientas hay disponibles?».
- 2. Invocar herramienta: el agente de IA indica «Ejecutar esta herramienta con estos argumentos».
«El LLM puede preguntar: “¿qué herramientas hay disponibles?”», explica Don. «Y más tarde puede indicar “ejecutar esta herramienta con estos argumentos”. Básicamente, eso es todo».
La comunicación se realiza mediante JSON-RPC (protocolo de llamada a procedimiento remoto basado en JSON), con conexiones persistentes y bidireccionales, a diferencia del patrón sin estado de solicitud y respuesta de las API REST.
El servidor MCP responde con una descripción de cada herramienta en un formato legible por máquina: su nombre, lo que hace, las entradas que acepta y los resultados que devuelve. El agente de IA puede adaptarse a nuevas capacidades sin que nadie tenga que escribir código de integración personalizado.
Las herramientas que hay detrás de un servidor MCP pueden desarrollarse en cualquier lenguaje. «La herramienta puede ser una aplicación de Node, de IRIS o de Java, y el cliente puede ser algo totalmente distinto», señala Don. Gracias a este diseño, independiente de la plataforma, los servidores MCP creados hoy seguirán funcionando a medida que evolucione la tecnología subyacente.
MCP vs API: principales diferencias
A simple vista, el MCP y las API parecen similares. Ambos transfieren datos entre sistemas y utilizan solicitudes y respuestas estructuradas. Las diferencias se aclaran al analizar qué presupone cada uno sobre quien realiza la llamada.
Característica | API tradicionales | MCP |
Arquitectura y comunicación
Las API REST siguen un patrón sin estado. Cada solicitud es independiente y el servidor no recuerda lo que ocurrió en la llamada anterior. Por eso, el contexto debe enviarse manualmente con cada solicitud.
MCP mantiene el estado entre interacciones, incluidos el historial de la conversación y los resultados anteriores de las herramientas. Un agente de IA que depura un flujo de trabajo clínico puede consultar el registro de un paciente, comprobar sus resultados de laboratorio y revisar los conflictos de agenda sin perder el contexto entre un paso y otro.
Descubrimiento dinámico frente a endpoints estáticos
Esta es la diferencia de mayor alcance. Las API tradicionales obligan a quien realiza la llamada a conocer de antemano todos los endpoints. Alguien lee la documentación, escribe el código y programa la integración de forma rígida. Cuando la API cambia, el código deja de funcionar hasta que alguien lo actualiza.
Los servidores MCP se describen a sí mismos en tiempo de ejecución. El agente de IA envía una solicitud de descubrimiento y recibe una lista estructurada de todas las herramientas disponibles, con sus nombres, descripciones, esquemas de entrada y formatos de salida. El agente no necesita conocerlas previamente, y ninguna herramienta requiere código personalizado.
Don lo plantea como una ventaja a largo plazo:
«En el primer proyecto no tiene demasiado sentido. Pero, si se piensa a unos años vista, puede haber 25, 75 o 100 herramientas distintas. Y cuando haga falta crear un nuevo flujo de trabajo agéntico, será posible recurrir a todas ellas, porque todas estarán escritas de la misma manera». "For your very first project, it's not going to make that much sense. Es el primer bucle agéntico, con tres herramientas que hay que conectar, y en realidad complica la vida. Pero, si se piensa a unos años vista, puede haber 25, 75 o 100 herramientas distintas. Y cuando haga falta crear un nuevo flujo de trabajo agéntico, será posible recurrir a todas ellas, porque todas estarán escritas de la misma manera».
El descubrimiento dinámico es lo que hace posible esa escala. Para la IA, usar la herramienta número 50 resulta tan fácil como usar la quinta. .
Para quién está pensada cada tecnología
Las API están pensadas para desarrolladores y sistemas de software capaces de hacer llamadas de red, guardar secretos y gestionar errores de forma segura. Quien realiza la llamada tiene el control total de lo que ocurre.
MCP está pensado para los modelos de IA y los LLM. Se trata de sistemas inteligentes en los que, sin embargo, no se puede confiar sin reservas. Razonan con lenguaje natural, pero no pueden custodiar claves de API, ejecutar código arbitrario ni hacer solicitudes de red por sí mismos. MCP ofrece a estos modelos una vía estructurada y gobernada para actuar sobre su entorno.
Seguridad y gobernanza
En las API, la seguridad se aplica en cada endpoint mediante tokens de autenticación, claves de API, flujos OAuth y límites de frecuencia de solicitudes. Cada integración gestiona sus propias credenciales.
MCP añade una capa de gobernanza por encima de cada API. El servidor MCP controla qué capacidades se ponen a disposición de los sistemas de IA, qué entradas se aceptan y qué registro de actividad se aplica. El agente de IA nunca maneja directamente las credenciales.
En entornos regulados, esta separación resulta valiosa: reduce la proliferación de credenciales, simplifica las auditorías y mantiene los sistemas de IA dentro de límites operativos explícitos.
La analogía de FHIR: por qué los equipos sanitarios comprenden al instante el MCP
Los equipos de TI sanitarios ya han vivido un cambio de estandarización de este tipo.
Don establece el paralelismo directamente: «En nuestro sector, podría pensarse en algo parecido a un servidor FHIR. Un servidor FHIR no es más que un servidor REST, pero con una manera concreta de solicitar y actualizar la información de los pacientes. Las respuestas tienen un formato determinado que se sabe interpretar. Es, por tanto, una forma estandarizada de tratar la información sanitaria. MCP es algo similar: una forma estandarizada de referirse a las herramientas y obtener resultados». Las respuestas que recibes siguen un formato concreto que sabes cómo interpretar.
El paralelismo es exacto:
- FHIRestandarizó el intercambio de datos clínic os entre sistemas sanitarios. Antes de FHIR, cada sistema de historia clínica electrónica tenía su propio formato de datos propietario, sus propias convenciones de API y sus propios requisitos de integración. FHIR añadió una capa estandarizada sobre REST para que cualquier sistema pudiera intercambiar datos de pacientes en un formato coherente.
MCP estandariza el descubrimiento y el uso de herramientas por parte de los agentes de IA. Antes de MCP, cada integración de IA requería código personalizado para cada servicio externo. MCP añade una capa estandarizada sobre las API existentes para que cualquier agente de IA pueda interactuar con cualquier herramienta mediante un protocolo coherente.
Tanto FHIR como MCP funcionan sobre la infraestructura existente. Ninguno de los dos sustituye lo anterior. Ambos hacen interoperables los sistemas subyacentes de un modo cuyo valor se multiplica con el tiempo. Para las organizaciones que ya tienen en producción una interoperabilidad basada en FHIR mediante plataformas como InterSystems HealthShare, el patrón de MCP resultará familiar. El mismo criterio arquitectónico se aplica a ambos: estandarizar la interfaz
y dejar que las implementaciones varíen por debajo.
¿Sustituye MCP a las API?
No. La mayoría de los servidores MCP encapsulan API ya existentes.
Un servidor MCP que ofrece una herramienta schedule_appointment podría llamar, por debajo, a la API REST de un hospital. Un servidor MCP de seguimiento de incidencias podría traducir las llamadas a herramientas en solicitudes a la API de Jira. Un servidor MCP de datos clínicos podría consultar internamente un endpoint FHIR. Las API siguen siendo la capa de ejecución, e
s decir, el mecanismo que realiza la operación. MCP se convierte en la capa de interfaz para la IA: el medio estandarizado con el que un agente descubre e invoca esas operaciones.Don describe las herramientas que hay detrás de los servidores MCP como «simples API, como “reservar una cita”. Pueden ser bases de datos en las que hay que leer y escribir. Pueden ser recursos de internet, sitiosweb. Puede obtenerse información de fuentes documentales internas, de un PDF o de lo que sea».
MCP y las API son capas complementarias de la pila tecnológica de IA, no tecnologías que compitan entre sí.
Cuándo utilizar MCP y cuándo utilizar una API
La elección depende de quién (o qué) realiza la llamada y del grado de dinamismo que deba tener el flujo de trabajo.
Conviene usar directamente las API cuando:
- el flujo de trabajo está predefinido, es estable y es poco probable que cambie;
- el rendimiento es fundamental (cada capa adicional añade cierta latencia);
- no intervienen agentes de IA y se trata de una comunicación entre sistemas;
- se recuperan datos guardados previamente en un repositorio, como un almacén de datos.
Conviene usar MCP cuando:
- • los agentes y las aplicaciones de IA necesitan orquestar acciones entre varios servicios externos; • los flujos de trabajo cambian con frecuencia por motivos normativos, procesos internos o actualizaciones tecnológicas; • se necesita descubrimiento dinámico, es decir, que la IA se adapte a nuevas herramientas sin escribir código personalizado; • importa crear prototipos con rapidez: con MCP, los equipos conectan agentes de IA a nuevas fuentes de datos y herramientas en poco tiempo, sin desarrollar integraciones personalizadas para cada una; • importa la gobernanza de la seguridad: se quiere controlar a qué puede acceder la IA sin exponer directamente los endpoints de las API.
Conviene usar ambos a la vez (el patrón más habitual):
La mayoría de las arquitecturas maduras combinarán el uso directo de API en las integraciones estables entre sistemas internos con servidores MCP en los flujos de trabajo orientados a la IA. Las API hacen el trabajo. Los servidores MCP lo ponen al alcance de los agentes de IA de forma controlada y estandarizada. Las API se encargan de todo.
Este enfoque por capas es donde
las plataformas de interoperabilidad sanitaria demuestran su valor. La misma infraestructura que armoniza los datos de sistemas dispares puede servir también de base a los servidores MCP en los que se apoyan los agentes de IA. Así, las integraciones existentes se convierten en capacidades preparadas para la IA sin necesidad de reconstruirlas desde cero.
Por qué MCP es importante para las grandes organizaciones sanitarias
El valor de MCP no resulta evidente en el primer proyecto, pero se vuelve indiscutible a gran escala. .
La apuesta a largo plazo: de 3 a 100 herramientas
Un primer flujo de trabajo agéntico podría conectar tres herramientas: una consulta a la historia clínica electrónica, una comprobación de la agenda y un sistema de notificaciones. Escribir código de integración personalizado para tres herramientas es sencillo.
Sin embargo, las organizaciones sanitarias acumularán herramientas rápidamente: verificación de la facturación, comprobación de la cobertura del seguro, sistemas de farmacia, peticiones de laboratorio, apoyo a la decisión clínica, diagnóstico por imagen, comunicación con los pacientes y gestión del ciclo de ingresos.
Cada nueva herramienta que sigue el estándar MCP es tan fácil de conectar como la anterior, porque todas utilizan el mismo protocolo.
«Se podrá recurrir a todas estas herramientas porque todas estarán escritas de la misma manera. Todas se comunicarán de la misma forma», explica Don.
El ecosistema de proveedores toma impulso
La adopción de MCP se extiende más allá de los pioneros. " «Si se usa Salesforce como CRM (gestión de las relaciones con los clientes) o Jira como sistema de seguimiento de incidencias, estos ya incluyen servidores MCP», indica Don. «Los sistemas que suministran los proveedores empezarán a distribuirse con servidores MCP, lo que facilitará su incorporación a los flujos de trabajo agénticos».
Los proveedores tecnológicos del sector sanitario seguirán la misma trayectoria. Las plataformas de historia clínica electrónica, los sistemas de salud poblacional, las herramientas de gestión del ciclo de ingresos y los servicios de análisis clínico incorporarán servidores MCP. Así resultará sencillo integrarlos en flujos de trabajo agénticos sin escribir código de integración personalizado para cada uno. .
InterSystems IRIS, por ejemplo, puede servir de base a servidores MCP que ofrezcan flujos de trabajo clínicos, consultas de pacientes o análisis en el lenguaje que prefiera el equipo de desarrollo. Gracias a la independencia entre el cliente MCP y la tecnología subyacente, las herramientas creadas hoy seguirán funcionando a medida que evolucione la pila tecnológica.
El patrón va más allá de los sistemas internos. Don menciona Context7, un servidor MCP que ofrece documentación sobre tecnologías adaptada a los LLM y que es un ejemplo de recurso MCP a escala de internet. En el ámbito sanitar io, el equi
valente podrían ser bases de datos de interacciones farmacológicas, guías de práctica clínica o información de formularios terapéuticos disponibles como herramientas compatibles con MCP, que cualquier agente de IA puede descubrir y utilizar. El protocolo facilita la creación rápida de prototipos de flujos de trabajo concebidos para la IA que conectan los LLM con fuentes reales de datos clínicos, sin escribir código personalizado para cada integración.
Preguntas frecuentes
Conclusión
Las API son la capa de ejecución. MCP es la capa de interfaz concebida para la IA. Las dos capas funcionan conjuntamente.
Para los equipos sanitarios, el paralelismo más cercano es el paso de los formatos de datos propietarios a FHIR. Las organizaciones que adoptaron FHIR pronto no solo resolvieron un problema de interoperabilidad: construyeron una base cuyo valor creció a medida que se incorporaban más sistemas. MCP sigue el mismo patrón, aplicado a la integración de la IA.
El valor no está en el primer proyecto agéntico con tres herramientas, sino en lo que ocurre cuando hay cien herramientas y todas utilizan el mismo protocolo. Las organizaciones que estandaricen ahora la interacción de sus agentes de IA con los sistemas externos obtendrán una ventaja estructural que crecerá con cada herramienta que añadan.
