RAG frente a MCP: para qué sirve cada uno y cuándo utilizar ambos

La generación aumentada por recuperación, conocida como RAG, localiza documentos relevantes de los datos de una organización para que las respuestas de los grandes modelos de lenguaje se basen en información fiable. El Protocolo de Contexto de Modelo, o MCP, proporciona a estos modelos una forma normalizada de interactuar con herramientas y actuar sobre sistemas externos.

RAG aporta los conocimientos que le faltan al modelo, mientras que MCP le proporciona capacidad de actuación. La mayoría de los sistemas de IA utilizados en entornos de producción necesitan ambas tecnologías.

La pregunta «¿deberíamos utilizar RAG o MCP?» aparece con frecuencia en los debates sobre arquitectura empresarial, pero parte de un planteamiento equivocado.

La generación aumentada por recuperación y el Protocolo de Contexto de Modelo actúan en capas diferentes. RAG recupera información de los documentos de una organización. MCP ejecuta acciones en sistemas externos. Preguntar cuál de los dos debe elegirse equivale a preguntar si se necesita una biblioteca o un teléfono.

Douwe Kiela, uno de los autores originales de RAG y director ejecutivo de Contextual AI, lo explica así: «creo que ahora se le ha cambiado el nombre por el de ingeniería de contexto, que incluye MCP y RAG».

Si una de las personas que creó RAG no considera que ambas tecnologías compitan entre sí, no hay motivos para tratarlas como alternativas.

La verdadera cuestión consiste en determinar si la infraestructura de datos admite ambas. Los sistemas modernos de IA suelen utilizar RAG para localizar documentos y MCP para actuar a partir de la información obtenida. Las organizaciones que implantan IA basada en agentes a gran escala ya combinan las dos tecnologías.

RAG resuelve un problema concreto: fundamenta las respuestas de los grandes modelos de lenguaje en los datos propios de una organización, en lugar de depender únicamente de la información utilizada durante su entrenamiento.

Un chatbot de atención al cliente constituye un ejemplo sencillo. Una persona podría preguntar cómo debe prepararse para una operación de rodilla. Sin RAG, el modelo recurre a los conocimientos adquiridos durante su entrenamiento y proporciona una respuesta genérica. Con RAG, el sistema recupera documentos de la base de conocimiento y genera una respuesta precisa basada en ese material.

Cuando se recibe una consulta, el sistema también la transforma en un vector, recupera los fragmentos con mayor similitud semántica y los incorpora al prompt junto con la pregunta. Don Woodlock denomina este proceso «el prompt anterior al prompt». El LLM genera la respuesta únicamente a partir del contexto recibido, en lugar de utilizar todo el conjunto de información con el que se entrenó.

Los modelos con ventanas de contexto extensas, como los de Anthropic, con 200 000 tokens, o los de Google, que superan el millón, han generado dudas sobre la continuidad de RAG. Sin embargo, existen cuatro motivos principales por los que esta tecnología sigue siendo necesaria:

1. El uso de tokens a gran escala. Enviar 200 000 tokens con cada consulta resulta costoso en aplicaciones con un volumen elevado de peticiones. Recuperar cinco fragmentos seleccionados reduce el coste de forma considerable.
2. La calidad de la recuperación. Cinco párrafos convenientes suelen producir mejores respuestas que el envío indiscriminado de todo el contenido. La precisión resulta más útil que el volumen.
3. La actualización de los datos. Las bases de datos vectoriales se actualizan de forma gradual cuando cambian los datos originales. Las soluciones basadas únicamente en ventanas de contexto requieren volver a incorporar todo el contenido.
4. La privacidad y el cumplimiento normativo. Los índices utilizados por RAG pueden cifrarse y someterse a controles de acceso independientes. En los sectores regulados,el envío simultáneo de todo el contenido al gran modelo de lenguaje plantea problemas cuando parte de la información está restringida.

El sector sanitario presenta algunos de los casos más avanzados de adopción de RAG y ofrece resultados concretos.

Un estudio sobre el apoyo a la toma de decisiones clínicas en radiología comprobó que RAG eliminó las alucinaciones y redujo su incidencia del 8 % al 0 %.

En nutrición clínica, un sistema basado en RAG alcanzó una precisión del 99,25 % al resumir información nutricional procedente de las notas de enfermería incluidas en las historias clínicas electrónicas.

Otro sistema que utilizaba manuales previamente seleccionados obtuvo u una precisión del 91,5 % en exámenes de acreditación de oncología radioterápica.

GraphRAG constituye una variante que representa las entidades y sus relaciones mediante un grafo de conocimiento, en lugar de utilizar únicamente fragmentos de documentos independientes. Esta estructura facilita búsquedas que siguen varias relaciones sucesivas y resulta útil, por ejemplo, para la gestión de enfermedades crónicas complejas.

MCP resuelve un problema diferente: proporciona a los modelos de IA una forma normalizada de realizar acciones en sistemas externos.

Antes de su aparición, cada herramienta necesitaba un código de integración específico, con parámetros, protocolos y formatos de respuesta diferentes. MCP normaliza el acceso a las herramientas. En su vídeo sobre el MCP, Woodlock lo define así:

Un servidor MCP agrupa una o varias herramientas, como API internas, bases de datos externas o cualquier servicio que pueda ejecutarse, y aplica dos operaciones básicas:

1. Enumerar las herramientas — el gran modelo de lenguaje pregunta: «¿qué herramientas están disponibles?».
2. Ejecutar una herramienta — el gran modelo de lenguaje indica: «ejecuta esta herramienta con estos argumentos».
   

Eso es todo. Un cliente MCP, integrado en la aplicación principal o en el entorno de agentes, puede comunicarse con cualquier servidor MCP mediante este protocolo normalizado.

Don Woodlock establece la siguiente comparación:
«En nuestro sector, podría entenderse como algo parecido a un servidor FHIR. Un servidor FHIR no deja de ser un servidor REST, pero existe una forma concreta de solicitar o actualizar información de los pacientes. Las respuestas tienen un formato determinado que el sistema sabe interpretar. MCP funciona de forma parecida: ofrece una forma normalizada de hacer referencia a las herramientas y obtener resultados».

FHIR normalizó el intercambio de datos sanitarios. MCP normaliza el acceso de la IA a las herramientas. En la actualidad, se están desarrollando entornos que integran MCP con FHIR.

Don Woodlock señala cinco motivos por los que MCP resulta importante para las organizaciones:

1. El valor aumenta con el número de herramientas. La normalización puede no compensar el trabajo inicial en un proyecto con tres herramientas, pero adquiere un valor considerable cuando la organización utiliza cien.
   
2. No depende de una tecnología concreta. La herramienta puede desarrollarse en un lenguaje y el cliente en otro diferente. Esta separación prolonga la vida útil de las herramientas aunque cambie la infraestructura tecnológica.
   
3. Los estándares simplifican los cambios. La organización puede sustituir el proveedor del gran modelo de lenguaje o el entorno de agentes sin tener que reescribir las herramientas MCP.
   
4. Los proveedores ya incorporan servidores MCP. Salesforce, Jira y otras plataformas empresariales de distintos ámbitos ya los incluyen. En el sector sanitario, GenomOncology presentó BioMCP, en abril de 2025, con doce tipos de datos biomédicos relacionados con ensayos clínicos, variantes genómicas, medicamentos y publicaciones científicas.
   
5. Los servidores MCP pueden utilizar recursos disponibles en Internet. No necesitan ejecutarse de forma local. Las API meteorológicas, los servicios de documentación, las bases de datos externas y otros recursos accesibles por Internet pueden integrarse mediante un servidor MCP.

Los servidores MCP resultan especialmente útiles para las herramientas internas cuyos usuarios necesitan interactuar de formas poco previsibles con datos estructurados. Entre estas tareas se encuentran la actualización de registros en un CRM, la consulta de datos en tiempo real o la activación de flujos de trabajo.

Anthropic presentó MCP en noviembre de 2024. OpenAI lo adoptó en marzo de 2025 y Google DeepMind lo hizo en abril del mismo año.

En diciembre de 2025, Anthropic cedió MCP a la Agentic AI Foundation de la Linux Foundation, creada junto con Block y OpenAI. En ese momento, existían más de 10 000 servidores MCP públicos activos en plataformas como ChatGPT, Cursor, Gemini y Microsoft Copilot.

La llamada a funciones es el mecanismo interno mediante el que un gran modelo de lenguaje indica: «quiero ejecutar una herramienta». Cada plataforma aplica este mecanismo de una forma diferente.

MCP actúa en una capa superior y normaliza la descripción y la ejecución de las herramientas, con independencia del LLM utilizado.

La llamada a funciones expresa la intención de ejecutar una herramienta. MCP aporta la infraestructura necesaria para que esa intención pueda trasladarse entre diferentes sistemas.

Dimensión	RAG	MCP
Función principal	Recupera contexto relevante de distintas fuentes de datos.	Normaliza el acceso de los agentes de IA a las herramientas.
Tipo de datos	Datos no estructurados, como documentos, artículos y manuales.	Datos estructurados procedentes de API, bases de datos y sistemas activos.
Flujo de datos	Unidireccional: recuperación, incorporación y generación.	Bidireccional: consulta, acción, resultado y siguiente paso.
Modificación de los sistemas	Solo lee los datos y no modifica su estado.	Puede escribir, actualizar o activar acciones.
Escalabilidad	Requiere ampliar el almacenamiento vectorial y la capacidad de reindexación.	Requiere añadir nuevos servidores, puntos de acceso y conexiones.
Problema que resuelve	El LLM desconoce los datos privados de la organización.	El LLM o puede actuar de forma uniforme sobre sistemas externos.
Aplicaciones más adecuadas	Aplicaciones públicas que reciben preguntas previsibles.	Herramientas internas con interacciones poco previsibles.

Peter Lee, presidente de Microsoft Research, define la IA basada en agentes a partir de cuatro capacidades relacionadas: memoria, permisos, acciones y razonamiento.

RAG se ocupa de la memoria, es decir, del contexto externo que necesita el agente. MCP gestiona los permisos y las acciones, como los recursos a los que puede acceder y las operaciones que puede realizar. El propio gran modelo de lenguaje aporta la capacidad de razonamiento.

Tres preguntas facilitan la elección.

Cuando el conocimiento se encuentra en datos estáticos y no estructurados, como guías clínicas, manuales de políticas o documentación de productos, RAG recupera la información necesaria en el momento de la consulta y la incorpora al prompt.

Cuando la información procede de datos estructurados y cambia continuamente, como los resultados actuales de laboratorio, el inventario en tiempo real o el estado de los pedidos pendientes, MCP consulta directamente la fuente.

RAG suele ser suficiente para responder preguntas, resumir contenidos o buscar información en documentos.

Cuando la IA debe actualizar un registro, concertar una cita o activar un flujo de trabajo, necesita MCP.

Un caso de uso aislado puede comenzar con RAG e incorporar llamadas a funciones cuando sea necesario.

Cuando una organización prevé implantar varios flujos de trabajo de IA en distintos departamentos, conviene establecer desde el principio una infraestructura basada en MCP. Las ventajas de la normalización aumentan con cada nueva herramienta.

Escenario	Arquitectura	¿Por qué?
Chatbot de preguntas frecuentes para clientes.	Solo RAG.	Recupera información de bases de conocimiento internas sin modificar los datos.
Búsqueda en documentación técnica.	Solo RAG.	Realiza búsquedas semánticas en datos no estructurados.
Consulta de interacciones entre medicamentos.	GraphRAG.	Las relaciones complejas entre entidades requieren un razonamiento basado en varias conexiones sucesivas.
Asistente para autorizaciones previas.	RAG y MCP.	Necesita consultar las políticas mediante RAG y presentar las solicitudes mediante MCP.
Apoyo a la toma de decisiones clínicas.	RAG basado en agentes y MCP.	Combina búsquedas en varios pasos con acciones sobre fuentes de datos externas.
Automatización de la incorporación de datos a un CRM o una HCE.	Principalmente MCP.	Escribe en bases de datos, programa acciones y envía notificaciones.
Cuadro de mando con datos en tiempo real.	Principalmente MCP.	Consulta datos estructurados y actualizados procedentes de varias fuentes.

Un flujo de derivación de pacientes muestra cómo pueden combinarse ambas tecnologías:

1. MCP consulta la información actualizada del paciente en la HCE.
2. RAG recupera de la base de conocimiento las guías clínicas pertinentes.
3. MCP envía la derivación al sistema de programación de citas.
4. MCP remite una notificación al médico que ha solicitado la derivación.
5. El gran modelo de lenguaje integra toda la información en una respuesta y genera un registro de auditoría.

RAG limita los riesgos porque restringe el acceso del sistema. El contenido se transforma en embeddings y se indexa previamente. Cuando se recibe una consulta, el sistema solo recupera los fragmentos relevantes. La arquitectura no establece una conexión directa con los sistemas activos, lo que reduce la superficie expuesta a ataques.

Las organizaciones de sectores regulados suelen implantar RAG en sus propias instalaciones o en una nube privada. Las bases de datos vectoriales funcionan dentro de su infraestructura, los embeddings se generan de forma local y los datos confidenciales no salen del entorno de la organización.

La capacidad de MCP para ejecutar acciones introduce riesgos que no existen en las arquitecturas RAG de solo lectura. MCP facilita que la IA actúe en nombre de una persona, lo que puede causar problemas cuando el servidor está comprometido o se ha configurado de forma incorrecta.

OWASP publicó en 2025 una lista de las 10 principales amenazas específicas de MCP:

Gestión inadecuada de los tokens. Las credenciales incluidas directamente en el código y los tokens de larga duración pueden exponer los sistemas conectados. El protocolo especifica OAuth 2.0 como sistema de autenticación, pero su aplicación depende de cada implantación.

Inyección de instrucciones en el contexto o en el prompt. En los entornos MCP, la inyección de instrucciones puede activar acciones automáticas. Un mensaje enviado por un usuario puede contener instrucciones ocultas que un agente con permisos excesivos ejecute en los sistemas de producción. Las ventanas de contexto demasiado extensas agravan el problema, ya que el modelo puede actuar a partir de información irrelevante o contradictoria.

Extracción de datos y reconocimiento del esquema. Un atacante puede diseñar prompts para obtener información confidencial de las bases de datos conectadas o reconstruir toda su estructura para preparar nuevos ataques. Los agentes con permisos excesivos aumentan ambos riesgos.

Las medidas recomendadas incluyen una lista de servidores MCP autorizados y verificados mediante métodos criptográficos, controles de acceso basados en el principio de privilegios mínimos, la aprobación humana de las operaciones de alto riesgo, los entornos aislados y los registros de auditoría.

En las organizaciones sanitarias, los sistemas de autenticación que ya utiliza FHIR, como SMART on FHIR con OAuth 2.0, proporcionan una capa de seguridad adecuada para los agentes conectados mediante MCP.

Cuando un agente de IA accede a los datos de un paciente mediante un servidor FHIR integrado como herramienta MCP, utiliza la infraestructura de autenticación, autorización y auditoría del propio servidor FHIR.

Las organizaciones que utilizan InterSystems HealthShare o InterSystems IRIS for Health ya cuentan con una infraestructura nativa de FHIR con certificación HITRUST r2. Esta infraestructura constituye una base previa para el cumplimiento normativo de sus agentes de IA.

Los sistemas de IA más avanzados combinan RAG y MCP dentro de arquitecturas con varios agentes. Cada llamada a un gran modelo de lenguaje se convierte en un agente con una función concreta.

No todos los agentes son grandes modelos de lenguaje. Algunos son herramientas. Un orquestador dirige el flujo de trabajo de forma dinámica.

La arquitectura basada en agentes incorpora el proceso de revisión que no existe cuando se realiza una única llamada a un gran modelo de lenguaje.

En una entrevista de Don Woodlock con Peter Lee, de Microsoft Research, este último describió un agente orquestador desarrollado con Stanford Medicine para las reuniones de los comités de tumores.

El agente recupera la información de los pacientes mediante MCP, utiliza modelos de IA de radiología y anatomía patológica también mediante MCP, consulta investigaciones publicadas en fuentes externas mediante RAG y registra las decisiones de la reunión mediante MCP.

Cada tecnología cumple así la función para la que fue diseñada.

El sistema MAI-DXO de Microsoft amplía este planteamiento mediante varios agentes con funciones diferenciadas: un agente principal realiza el diagnóstico, otro cuestiona todas las conclusiones y un tercero analiza la necesidad y el coste de cada prueba solicitada.

Mediante una «cadena de debate», el sistema alcanzó una precisión diagnóstica del 85,5 % en casos clínicos publicados en The New England Journal of Medicine. El resultado multiplicó por más de cuatro la precisión obtenida por médicos con experiencia que analizaron los mismos casos en condiciones equivalentes.

1. Revisar los datos de origen. RAG recupera la información disponible en las fuentes de datos. Cuando la documentación es incoherente o existen contradicciones entre las políticas, RAG reproduce esos problemas a gran escala. Una plataforma de datos unificada como InterSystems IRIS combina las operaciones transaccionales, el análisis y la búsqueda vectorial en un único motor, lo que reduce la fragmentación que perjudica la calidad de la recuperación.
   
2. Evaluar la preparación de las API. Los puntos de acceso REST existentes, incluidas las API FHIR de las organizaciones sanitarias, pueden integrarse con servidores MCP. Una organización que ya dispone de API internas bien documentadas y protegidas mediante OAuth 2.0 cuenta con buena parte de la infraestructura necesaria para adoptar MCP.
   
3. Comenzar con un proyecto acotado de RAG. Los chatbots de atención al cliente, la búsqueda en documentación y las consultas sobre políticas constituyen casos de uso consolidados y se apoyan en fuentes de datos delimitadas y fáciles de mantener.
   
4. Establecer la gobernanza de MCP antes de abrir el acceso a las herramientas. Las listas de servidores autorizados, los controles de acceso, la aprobación humana de las acciones y los registros de auditoría deben estar preparados antes de que los agentes interactúen con los sistemas de producción. Joel Venco, director de información de Hartford Health, recurre a una frase de Mario Andretti para explicar este planteamiento: «Unos frenos realmente buenos permiten conducir más rápido». La gobernanza no limita la velocidad, sino que facilita una implantación con las debidas garantías.