MCP vs RAG: cuándo tu agente necesita recuperar conocimiento y cuándo necesita ejecutar herramientas

RAG (Retrieval-Augmented Generation) resuelve un problema de conocimiento: el modelo no sabe algo, tú tienes ese algo escrito en alguna parte, y necesitas que lo tenga delante cuando responde. El mecanismo es conocido: se trocean los documentos, se indexan —normalmente con embeddings en una base vectorial, a menudo combinados con búsqueda léxica—, se recupera lo más relevante para la consulta y se incorpora al contexto. El modelo no aprende nada; lee lo que le has puesto delante antes de escribir.

MCP resuelve un problema de conexión: la aplicación de IA necesita acceder a capacidades y contexto que viven fuera del modelo, y necesitas una forma estándar de exponerlos sin escribir una integración distinta por cada modelo y cada cliente. La especificación define tres participantes —host (la aplicación de IA), client (el conector dentro del host) y server (el servicio que aporta contexto y capacidades)— y comunicación sobre JSON-RPC 2.0.

Aquí está el primer matiz que casi todo el mundo se salta: un servidor MCP no expone solo herramientas. La especificación define tres tipos de funcionalidad de servidor, y conviene tenerlos claros porque cambian el mapa de decisiones.

• Tools: funciones que el modelo puede ejecutar, desde consultas de solo lectura hasta operaciones con efectos sobre sistemas externos.
• Resources: contexto y datos que el usuario o el modelo pueden usar; pueden ser perfectamente contenido no estructurado.
• Prompts: mensajes y flujos plantillados, pensados para que el usuario los invoque.

El segundo malentendido frecuente es tratar MCP como si fuera el orquestador del agente. No lo es. MCP no decide cómo razona el agente, cuándo debe recuperar conocimiento ni cómo planifica una tarea de varios pasos: estandariza la conexión con sistemas externos. La estrategia de recuperación, el bucle de razonamiento, la política de reintentos y la orquestación siguen siendo decisiones de arquitectura tuyas, las tomes con LangGraph, con Semantic Kernel, con Spring AI o con código propio.

Esa separación de responsabilidades es justamente lo que hace útil al protocolo: puedes cambiar de orquestador sin rehacer las integraciones, y puedes cambiar de modelo o de cliente sin reescribir cómo se accede al CRM. Pero también significa que adoptar MCP no responde por sí solo a ninguna de las preguntas difíciles de este artículo. Decide cómo se conecta el agente, no qué debe consultar en cada pregunta.

Conviene añadir que el protocolo sigue evolucionando: la revisión vigente en el momento de escribir es la 2026-07-28, que además del núcleo define extensiones opcionales —negociadas explícitamente entre cliente y servidor— para cosas como la ejecución asíncrona de operaciones largas o los elementos de interfaz embebidos. La dirección del trabajo apunta a operación, extensibilidad y fiabilidad de servidores en producción, que es exactamente donde duele cuando esto sale del prototipo.

Casi todas las decisiones difíciles se ordenan con una pregunta bien formulada: ¿qué naturaleza tiene lo que el agente necesita? Conocimiento es lo que alguien escribió una vez para que se leyera: una política de devoluciones, un manual de producto, la documentación de una API interna, el histórico de resoluciones de soporte. Cambia despacio, vive en prosa, admite matices y su interpretación depende del contexto de la pregunta. Estado es lo que un sistema sabe en este momento: el stock de una referencia, el saldo de un cliente, el estado de un pedido, la disponibilidad de una sala. Cambia rápido, vive en registros y admite una respuesta concreta en cada instante.

A esas dos hay que añadir dos categorías que la simplificación habitual se deja fuera. Cálculo o agregación son las preguntas de "cuántos", "cuál es el total", "qué clientes cumplen X" o "cuál es la media": no se resuelven recuperando fragmentos parecidos, sino ejecutando una consulta estructurada. Y acción es todo lo que modifica un sistema: crear un ticket, enviar un correo, emitir un abono. La acción siempre se ejecuta mediante una herramienta; MCP es una forma estandarizada de exponer esa herramienta al agente, no la única.

Esto es una heurística arquitectónica, no una ley. Sirve para ordenar el 80 % de los casos y dejar el 20 % restante señalado como lo que es: una decisión de diseño que hay que razonar. Con ella, el mapa queda así:

• Conocimiento: políticas internas, normativa, manuales, documentación técnica, actas, propuestas, base de conocimiento de soporte.
• Estado: CRM, ERP, ticketing, inventario, facturación, calendarios, sistemas de RRHH — todo lo que responde a "ahora mismo".
• Cálculo: conteos, totales, medias, listados que deben ser exhaustivos.
• Acción: crear un ticket, actualizar una oportunidad, enviar un correo, reservar, aprobar, emitir un abono.

Puesto en forma de flujo, el enrutado de una pregunta cualquiera recorre estas etapas. No es un diagrama de cajas por gusto: es la decisión que toma el agente —o que tomas tú al diseñarlo— en cada turno.

1. El usuario formula una pregunta y el agente la recibe con su contexto de sesión.

2. ¿Necesita conocimiento? → capa de recuperación

   base vectorial o búsqueda híbrida sobre documentación, políticas y manuales.

3. ¿Necesita estado o cálculo? → capa MCP

   tools contra CRM, ERP, bases de datos y APIs internas.

4. ¿Necesita ejecutar algo con efectos? → tool de escritura, con permisos, validación y confirmación cuando proceda.

5. El agente razona con lo recuperado y lo consultado, y responde citando lo que procede.

La heurística es el marco; estas son las señales concretas que aparecen en las conversaciones de descubrimiento y que permiten decidir sin escribir una línea de código. Conviene atender a cómo formula el negocio la pregunta, porque el lenguaje delata la naturaleza del dato mucho antes que el diagrama de arquitectura.

Con la heurística clara, quedan cuatro zonas grises que merecen tratamiento explícito porque son las que rompen proyectos ya en marcha.

La primera es la documentación versionada. Manuales de producto, documentación de API o normativa interna que existen en varias versiones simultáneas son conocimiento —se recuperan— pero necesitan que la versión sea un filtro duro, no una señal semántica. Si la versión vive solo dentro del texto del fragmento, el recuperador mezclará versiones y el agente responderá con una combinación imposible. La solución no es cambiar de patrón: es llevar versión, ámbito, fecha de vigencia, país, departamento o cliente a los metadatos y filtrar antes de buscar.

La segunda son los catálogos de producto, donde conviven descripción semántica (conocimiento), atributos relativamente estables (ficha técnica, categoría, compatibilidades) y precio, stock y disponibilidad (estado puro). Tratar el catálogo como una sola cosa es la vía rápida al desastre: o indexas precios que caducan, o renuncias a la búsqueda semántica que hace útil la descripción. La arquitectura correcta separa las tres capas y consulta las volátiles en el momento de responder.

La tercera son las respuestas que exigen agregación. "¿Cuántos contratos vencen este trimestre en la zona norte?" no es una pregunta de recuperación: aunque el índice contenga todos los contratos, el recuperador devolverá los k fragmentos más relevantes, no todos los que cumplen la condición, y el agente contará mal con absoluta seguridad en el tono. Cualquier pregunta con "cuántos", "total", "media" o "todos los que" pide una consulta estructurada.

La cuarta es el conocimiento que en realidad es estado con formato de prosa: el estado de un proyecto en un wiki que alguien actualiza a mano, la lista de responsables en un documento compartido. Aquí el problema no es de patrón sino de origen: el dato debería venir del sistema que lo gobierna. Indexar el documento perpetúa un proceso frágil y le da apariencia de fiabilidad.

• Documentación versionada: versión, ámbito y vigencia como filtros de metadatos antes del retrieval, nunca como pista semántica.
• Catálogos: separa descripción semántica, atributos estables y precio/stock/disponibilidad.
• Agregaciones y conteos: consulta estructurada mediante herramienta.
• Prosa que en realidad es estado: arregla el origen antes de decidir el patrón.

La arquitectura híbrida es especialmente adecuada cuando el caso de uso combina conocimiento documental con sistemas operativos, y ahí la recuperación y las herramientas suelen convivir dentro del mismo agente. La pregunta deja de ser excluyente en cuanto el caso de uso toca a la vez la política escrita y el registro vivo, que es lo que ocurre en soporte, en ventas, en operaciones y en RRHH.

Una opción especialmente útil en arquitecturas agénticas es exponer la búsqueda sobre la base de conocimiento como una tool MCP más, junto a las consultas al CRM o al ERP: el agente decide en cada turno si necesita leer documentación, consultar un sistema, o ambas cosas. En otros diseños, parte del contexto se expone mediante resources, o la recuperación la gestiona directamente la capa de retrieval antes de invocar al modelo. No hay una única arquitectura correcta; hay una decisión que depende de cuánta libertad quieras darle al modelo y de cuánto control necesites sobre el contexto.

El patrón que mejor envejece, cuando encaja, tiene tres ventajas que no son evidentes hasta que se vive el mantenimiento. La primera es que la recuperación deja de ser obligatoria en cada turno: solo la pagan las preguntas que la necesitan. La segunda es que se vuelve iterativa —el agente puede refinar la consulta tras ver los primeros resultados—, que es la base del RAG agéntico. La tercera es de gobierno: una interfaz homogénea, con permisos, cuotas y trazas comparables, en lugar de dos caminos de acceso al dato con controles distintos.

Conviene añadir una advertencia sobre el coste de la flexibilidad. Cada herramienta que expones ocupa contexto, y una superficie de treinta herramientas mal nombradas degrada la decisión del modelo más de lo que cualquiera espera. La disciplina es la misma que aplicamos en harness engineering: pocas herramientas, bien nombradas, con descripciones que digan cuándo usarlas y cuándo no, y errores que enseñen al modelo a corregirse.

La diferencia entre las dos formas de recuperar merece precisión, porque se cita mal con frecuencia. En el RAG clásico, la recuperación suele ejecutarse antes de generar la respuesta: se busca, se incorpora al contexto y se responde, normalmente en una sola pasada. En arquitecturas agénticas, el propio modelo puede decidir cuándo recuperar, reformular la consulta, evaluar los resultados y realizar varias búsquedas antes de dar una respuesta.

Exponer la recuperación como herramienta es una de las formas de habilitar ese comportamiento, y encaja de forma natural con MCP, pero no es la única: un orquestador puede implementar el mismo bucle de query planning, recuperación iterativa y reranking sin que el modelo llame a ninguna tool. Lo que define al RAG agéntico es el bucle, no el mecanismo de exposición.

El precio de esa flexibilidad es real: más latencia, más tokens y más varianza. Merece la pena cuando las preguntas son complejas o mal formuladas, y no la merece cuando el caso de uso es un buscador semántico sobre un corpus acotado. Como siempre, la respuesta depende de las preguntas que vas a recibir, y por eso conviene tener un conjunto representativo antes de decidir.

Hay una distinción que ordena buena parte del trabajo de seguridad y que rara vez está explícita en los diseños iniciales: no es lo mismo una herramienta que lee que una que escribe. La superficie de riesgo cambia de naturaleza en cuanto una operación deja huella en un sistema.

• Lectura: consultar el estado de un pedido, buscar un cliente, comprobar stock. El riesgo es de exposición de información.
• Escritura: cancelar un pedido, enviar un correo, emitir un abono, borrar un cliente. El riesgo es de efectos reales, a veces irreversibles.

Los perfiles de riesgo de las dos rutas son distintos y complementarios. El riesgo del RAG es de exposición: si el índice mezcla documentos con permisos distintos y no filtras por identidad antes de recuperar, el agente revelará información a quien no debía verla, y lo hará de forma difícil de auditar. El riesgo de las herramientas es de ejecución: operaciones con efectos, permisos demasiado amplios y prompt injection indirecta que llega desde el contenido devuelto por la propia herramienta. La especificación es explícita al respecto: las descripciones y anotaciones de una tool deben considerarse no confiables salvo que procedan de un servidor de confianza, y el host debe recabar consentimiento explícito antes de invocarlas.

La lista de controles no es larga ni exótica, pero hay que aplicarla entera. En transportes HTTP, la autorización se apoya en OAuth 2.1: el servidor debe validar que el token fue emitido para él como audiencia y no aceptar ni reenviar tokens ajenos. En transportes locales, las credenciales se toman del entorno.

• Mínimo privilegio: solicita solo los scopes necesarios para la operación en curso, y amplía de forma incremental si hace falta.
• Autorización real: OAuth 2.1 cuando el transporte lo permita, con validación de audiencia del token y sin reenviar tokens de terceros.
• Credenciales protegidas en tránsito y en almacenamiento, nunca en la definición de la herramienta ni en el prompt.
• Validación de inputs de cada herramienta: los parámetros los propone un modelo, no un desarrollador.
• Separación explícita de lectura y escritura, con políticas y aprobaciones distintas.
• Trazabilidad completa: qué herramienta se llamó, con qué parámetros, por cuenta de quién y con qué resultado.
• Límites de ejecución: cuotas, timeouts y topes de iteraciones para acotar el daño de un bucle mal cerrado.
• Confirmación humana en operaciones sensibles o irreversibles.

La elección se suele discutir en términos de capacidad y se acaba pagando en términos de operación. Estos son los tres ejes donde la decisión se nota a los seis meses.

En coste, ninguna de las dos rutas es "solo por adelantado" o "solo por uso". RAG combina costes de preparación y mantenimiento del conocimiento —curación del corpus, embeddings, almacenamiento, reindexado— con costes por recuperación: la propia búsqueda, el reranking, los tokens adicionales de contexto y la evaluación continua. Las herramientas combinan costes de integración y operación —desarrollo, hosting, autenticación, mantenimiento de contratos, observabilidad— con el coste de cada consulta o acción: latencia y cuota del sistema destino, y tokens derivados de los resultados que vuelven al contexto.

En latencia, la recuperación sobre un índice bien diseñado suele tener un comportamiento relativamente predecible, mientras que una cadena de herramientas acumula la latencia de cada sistema externo y de cada iteración del agente. No hay cifras universales: dependen de la infraestructura, del tipo de búsqueda, del reranking, de la red, del tamaño del corpus y de cuántas llamadas encadene el agente. Lo que sí es general es la forma de la curva: el retrieval tiende a ser estable y las cadenas de tools tienden a tener cola larga.

En mantenimiento hay una asimetría que conviene tener presente: el RAG puede degradarse en silencio cuando cambia el corpus, el pipeline de retrieval o el modelo de embeddings, y nadie se entera hasta que alguien nota que las respuestas ya no son buenas. Las integraciones mediante herramientas tienden a producir fallos más visibles cuando cambian APIs, permisos o contratos —aunque también pueden degradarse de forma silenciosa, por ejemplo si una API empieza a devolver datos incompletos sin error—. La consecuencia práctica: el RAG necesita evaluación continua para no pudrirse, y las herramientas necesitan disciplina de contratos y versiones más observabilidad que registre qué se llamó, con qué parámetros y con qué resultado.

Para cerrar, la versión operativa. Toma una pregunta representativa de las que el agente tendrá que responder —una real, tomada de un ticket o de una conversación de negocio, no una inventada— y recórrela por este orden. En proyectos con varios tipos de pregunta, repite el recorrido por cada familia: es normal que un mismo agente termine con dos o tres rutas distintas.

• ¿La respuesta implica hacer algo con efectos (crear, modificar, enviar, aprobar)? Sí → herramienta de escritura, con permisos, validación y confirmación cuando proceda.
• ¿La respuesta correcta cambia a lo largo del día o depende de un registro concreto? Sí → herramienta contra el sistema origen. Indexarlo tiende a envejecer mal.
• ¿La pregunta pide contar, sumar, promediar o listar todos los que cumplen algo? Sí → consulta estructurada. Un top-k semántico no es exhaustivo.
• ¿La respuesta está escrita en prosa, dispersa en varios documentos y admite matiz? Sí → RAG, con citas al fragmento origen y filtrado por permisos e identidad.
• ¿Hay varias versiones o ámbitos del mismo documento? Sí → filtros duros de versión, vigencia y ámbito en los metadatos.
• ¿La pregunta mezcla varias de las anteriores? Sí → arquitectura híbrida diseñada desde el principio como tal.
• ¿Sabes medir si la respuesta fue buena? Si no → páralo aquí. Sin evals, cualquiera de las rutas se degrada sin que nadie se entere.

Nada de lo anterior se decide en el vacío. Muchas organizaciones ya disponen de parte de la base necesaria: bases de datos, APIs, un data warehouse o un lakehouse, catálogos, sistemas de identidad y algún mecanismo de gobierno. Lo determinante no es tener una pieza concreta de infraestructura, sino tener fuentes gobernadas, permisos, ownership definido y calidad de datos conocida. Esa base no se tira: es exactamente lo que hace viable cualquiera de las dos rutas.

El patrón que hemos visto funcionar mejor es tratar el acceso del agente como una capa más de la arquitectura de datos, no como un proyecto aparte de IA. Es la tesis que desarrollamos en por qué los agentes necesitan una capa de conocimiento y que aterrizamos técnicamente en Big Data e IA en producción. Quien ya tiene el dato gobernado no está empezando de cero: está a una capa de distancia.

Y una última consideración de cumplimiento, porque en España y la UE es parte del diseño y no del papeleo posterior: la ruta que elijas determina qué se registra, qué se puede auditar y qué se puede explicar. Un RAG con citas al fragmento origen y unas herramientas con traza de cada llamada dan una capacidad de rendir cuentas que un agente opaco no puede ofrecer. Cuando llegue la pregunta de por qué el sistema respondió lo que respondió, esa trazabilidad es la diferencia entre una explicación y un encogimiento de hombros.