RAG vs MCP: guía completa para desarrolladores (2026)
TL;DR
- RAG le da a un modelo un conocimiento que no tenía en el entrenamiento, recuperando texto relevante y pegándolo en el prompt. Lee.
- MCP le da a un modelo la capacidad de llamar herramientas y realizar acciones a través de un protocolo estándar. Actúa.
- La división mental limpia: RAG es para lo que dicen tus documentos. MCP es para lo que pueden hacer tus sistemas.
- No son competidores. RAG es una técnica, MCP es un protocolo. Preguntar "¿RAG o MCP?" es como preguntar "¿caché o HTTP?".
- Para cualquier cosa que cambia (precios, inventario, saldos de cuenta), RAG es la herramienta equivocada. Una base de datos vectorial devuelve lo que indexaste, no lo que es cierto ahora mismo.
- Para un cuerpo de texto grande y estático (documentación, contratos, políticas), MCP por sí solo es un desperdicio. Estarías haciendo llamadas a una API para responder preguntas que un índice bien construido responde al instante.
- La mayoría de los sistemas en producción en 2026 usan ambos: MCP para traer datos frescos y actuar, RAG para anclar al modelo en conocimiento de dominio estable.
Aquí hay una pregunta que parece simple y no lo es:
"¿Cuál es el PER actual de Apple?"
Constrúyelo con RAG y obtendrás una respuesta confiada, bien formateada, y equivocada. Constrúyelo con MCP y funciona. Ahora cambia la pregunta a "explica cómo se calcula el PER para empresas con resultados negativos" y la situación se invierte: RAG lo gestiona limpiamente, y MCP no tiene nada útil que ofrecer.
Mismo dominio. Mismo usuario. Arquitectura completamente distinta.
La mayor parte de la confusión en torno a RAG y MCP viene de tratarlos como dos opciones en un menú. No lo son. Una vez ves qué es realmente cada uno, la elección deja de ser un juicio de valor y se vuelve casi mecánica.
Este artículo recorre ambos conceptos desde primeros principios, construye el mismo asistente financiero dos veces, y te da una regla de decisión que puedes aplicar sin pensar mucho.
Parte 1: Qué es realmente RAG
RAG significa Retrieval-Augmented Generation (generación aumentada por recuperación). Quita la terminología y son tres pasos:
- Recuperar los fragmentos de texto más relevantes para la pregunta del usuario.
- Aumentar el prompt pegando esos fragmentos dentro.
- Generar una respuesta usando ese contexto prestado.
La analogía que lo hace clic
Imagina un examen donde no puedes traer apuntes, pero tienes un ayudante de investigación fuera de la sala. Deslizas tu pregunta por debajo de la puerta. El ayudante corre a la biblioteca, encuentra las tres páginas más relevantes, y te las desliza de vuelta. Escribes tu respuesta usando esas páginas.
No aprendiste nada. Simplemente conseguiste las páginas correctas en el momento correcto.
Eso es RAG. Los pesos del modelo nunca cambian. Estás editando el prompt, no el modelo.
Por qué necesita una base de datos vectorial
La parte difícil es el paso 1: encontrar las páginas correctas. La búsqueda por palabras clave falla constantemente aquí, porque las preguntas humanas rara vez usan las mismas palabras que el texto fuente.
Alguien pregunta por "empresas que pierden dinero". El documento dice "beneficio neto negativo". Cero solapamiento de palabras clave, significado idéntico.
Los embeddings resuelven esto. Un modelo de embeddings convierte texto en una lista de números (un vector) posicionado en un espacio de forma que significados similares caen cerca unos de otros. "Empresas que pierden dinero" y "beneficio neto negativo" acaban siendo vecinos, aunque no compartan ninguna palabra.
Una base de datos vectorial almacena estos vectores y responde rápido a una pregunta: ¿qué está más cerca de esto?
RAG en código
Aquí tienes una implementación mínima y honesta. Sin framework, para que veas cada pieza en movimiento:
from openai import OpenAI
client = OpenAI()
# Your knowledge base, already chunked.
DOCUMENTS = [
"The P/E ratio divides share price by earnings per share. "
"When earnings are negative, P/E is undefined and usually shown as N/A.",
"EV/EBITDA is often preferred over P/E for capital-intensive companies "
"because it is unaffected by capital structure and depreciation policy.",
"The PEG ratio adjusts P/E by the expected earnings growth rate. "
"A PEG below 1.0 is traditionally read as undervalued.",
]
def embed(text: str) -> list[float]:
"""Turn text into a vector."""
response = client.embeddings.create(
model="text-embedding-3-small",
input=text,
)
return response.data[0].embedding
def cosine_similarity(a: list[float], b: list[float]) -> float:
"""How close are two vectors? 1.0 means identical direction."""
dot = sum(x * y for x, y in zip(a, b))
norm_a = sum(x * x for x in a) ** 0.5
norm_b = sum(y * y for y in b) ** 0.5
return dot / (norm_a * norm_b)
# Index once, reuse many times. In production this lives in a vector DB.
INDEX = [(doc, embed(doc)) for doc in DOCUMENTS]
def retrieve(question: str, k: int = 2) -> list[str]:
"""Step 1: find the most relevant chunks."""
q_vector = embed(question)
scored = [
(cosine_similarity(q_vector, vector), doc)
for doc, vector in INDEX
]
scored.sort(reverse=True)
return [doc for _, doc in scored[:k]]
def answer(question: str) -> str:
"""Steps 2 and 3: augment the prompt, then generate."""
context = "\n\n".join(retrieve(question))
prompt = (
f"Answer using only the context below.\n\n"
f"Context:\n{context}\n\n"
f"Question: {question}"
)
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
)
return response.choices[0].message.content
print(answer("What do I use when a company has negative earnings?"))
Fíjate en lo que pasó. El modelo nunca se entrenó con esos tres documentos. Respondió correctamente porque el fragmento correcto aterrizó en su prompt.
Fíjate también en el techo: RAG solo puede devolver lo que indexaste. Si el PER de Apple cambió esta mañana y tu índice se construyó el mes pasado, RAG responderá con el número del mes pasado y sonará completamente seguro de ello.
Esa limitación es la razón entera por la que existe MCP.
Parte 2: Qué es realmente MCP
MCP significa Model Context Protocol. Anthropic lo presentó en noviembre de 2024, y en diciembre de 2025 lo donó a la Agentic AI Foundation bajo la Linux Foundation, por lo que ahora tiene soporte en Claude, ChatGPT, Gemini, Cursor, y VS Code en lugar de ser el formato de un solo proveedor.
MCP es un estándar para conectar modelos de IA a herramientas. No es una técnica. Es un protocolo, en la misma categoría que HTTP o SQL.
La analogía
Antes del USB-C, cada dispositivo tenía su propio conector. Quince dispositivos significaban quince cables incompatibles, y cada dispositivo nuevo significaba un cable nuevo para cada puerto.
Así era el tooling de IA antes de MCP. Conectar 10 aplicaciones de IA a 100 herramientas significaba escribir hasta 1.000 integraciones personalizadas. Cada una hecha a medida, cada una mantenida por separado.
MCP colapsa eso a una sola forma. Un proveedor de herramientas implementa el protocolo una vez, y cualquier cliente compatible con MCP puede usarlo. La aplicación de IA implementa el lado del cliente una vez, y consigue acceso a todo.
Las tres cosas que exponen los servidores MCP
- Tools (herramientas) son funciones que el modelo puede llamar.
get_stock_price("AAPL.US")ejecuta código real y devuelve un resultado real. - Resources (recursos) son datos que el modelo puede leer, como documentación o contenido de archivos.
- Prompts son plantillas reutilizables que encadenan varias herramientas en un flujo de trabajo completo.
MCP en código
Aquí tienes un servidor funcional. Esto es todo:
from mcp.server.fastmcp import FastMCP
import httpx
mcp = FastMCP("finance-tools")
@mcp.tool()
def get_current_price(ticker: str) -> dict:
"""Get the latest price for a stock ticker.
The docstring matters more than you'd think. It is what the
model reads to decide whether to call this tool at all.
"""
response = httpx.get(f"https://api.example.com/quote/{ticker}")
return response.json()
@mcp.tool()
def compare_tickers(ticker_a: str, ticker_b: str) -> dict:
"""Compare two tickers on price, market cap and P/E ratio."""
return {
"a": get_current_price(ticker_a),
"b": get_current_price(ticker_b),
}
if __name__ == "__main__":
mcp.run()
Conéctalo a Claude Code con un solo comando:
claude mcp add finance -- python /path/to/server.py
Ahora el modelo puede hacer cosas. No está leyendo sobre precios. Los está trayendo.
Un detalle que vale la pena interiorizar: el docstring es la interfaz. El modelo decide si llamar a tu herramienta según esa descripción. Un docstring vago produce una herramienta que nunca se usa, que es la razón más común por la que un servidor MCP correctamente instalado parece no hacer nada.
Parte 3: La diferencia real
Aquí está la comparación en una tabla:
La regla de una frase
Si la respuesta vive en un documento, usa RAG. Si la respuesta vive en un sistema, usa MCP.
Pruébala contra preguntas reales:
Por qué sigue preguntándose "¿son RAG y MCP lo mismo?"
Por un caso que se solapa: un servidor MCP puede exponer documentación como un recurso, lo que parece recuperación.
La diferencia es la escala y el mecanismo. Los recursos de MCP funcionan bien para un conjunto acotado de documentos que el modelo puede navegar por ID. RAG funciona cuando tienes miles de documentos y necesitas un ranking semántico para encontrar los tres relevantes.
También se pueden combinar. Un servidor MCP puede correr un pipeline de RAG internamente y exponerlo como una herramienta search_knowledge_base. En ese momento el modelo llama a una herramienta (MCP) que realiza recuperación (RAG). Ambos, cooperando.
Parte 4: El mismo asistente, construido dos veces
Las comparaciones abstractas solo llegan hasta cierto punto. Vamos a construir un asistente de análisis financiero de las dos formas y ver dónde se rompe cada una.
Los datos financieros son el caso de prueba ideal porque contienen los dos tipos de pregunta en el mismo dominio: definiciones que nunca cambian, y números que cambian cada segundo.
Estoy usando EODHD para los datos de mercado aquí, porque da la casualidad de que ofrece tanto una REST API convencional como un servidor MCP oficial, lo que la hace una forma limpia de comparar las dos arquitecturas sin cambiar de proveedor de datos a mitad de camino.
Versión A: el enfoque RAG
Indexa un corpus de conocimiento financiero, y luego responde preguntas a partir de él.
# Building a knowledge base of financial concepts
CORPUS = [
"Market capitalization equals share price multiplied by shares outstanding.",
"The P/E ratio compares share price to earnings per share.",
"Free cash flow is operating cash flow minus capital expenditures.",
"A dividend yield above 6% often signals either a falling share price "
"or an unsustainable payout ratio.",
# ...plus a few thousand more chunks
]
# Index them, then:
answer("Explain what a high dividend yield might indicate")
Esto funciona bien. El concepto es estable, la respuesta está en el corpus, y la recuperación la encuentra.
Ahora prueba esto:
answer("What is Apple's current dividend yield?")
Esto falla, y falla de la peor forma posible. El modelo encuentra un fragmento que explica qué significa la rentabilidad por dividendo, nota que también absorbió una cifra de Apple durante el entrenamiento, y produce algo como "la rentabilidad por dividendo de Apple es aproximadamente del 0,5%."
Confiado. Bien formateado. Potencialmente desactualizado por meses. Nada en el pipeline lo señala.
Ese es el modo de fallo de RAG que la gente subestima. No devuelve un error. Devuelve texto fluido y desactualizado.
Versión B: el enfoque MCP
Conecta el modelo a datos en vivo en su lugar.
# EODHD publishes two endpoints. v2 uses OAuth, v1 uses an API key.
claude mcp add --transport http eodhd https://mcp.eodhd.com/v2/mcp
Ahora la misma pregunta se enruta de forma distinta. El modelo llama a resolve_ticker("Apple") para obtener AAPL.US, y luego a get_fundamentals_data para traer la cifra actual. El número es real porque se trajo, no se recordó.
Dos detalles de diseño en el servidor de EODHD merecen estudiarse, uses o no la plataforma, porque resuelven problemas que todo sistema de tool-calling encuentra:
La resolución de tickers como herramienta de primera clase. Los usuarios dicen "Apple", las APIs quieren AAPL.US. Los usuarios dicen "Deutsche Bank", la API quiere DBK.XETRA. Su herramienta resolve_ticker gestiona nombres, tickers parciales, e ISINs, y devuelve alternativas cuando una empresa cotiza en varios mercados en lugar de adivinar mal en silencio. La mayoría de los fallos de tool-calling en agentes financieros pasan exactamente en este paso.
Documentación incrustada como recursos. El servidor incluye más de 100 páginas de su propia documentación de API como recursos MCP, así el modelo puede consultar qué parámetros acepta un endpoint sin gastar una llamada a la API. Esta es la parte arquitectónicamente interesante: es un pequeño patrón con forma de RAG viviendo dentro de un servidor MCP. Material de referencia estático como recursos, datos en vivo como herramientas, cada uno haciendo lo que se le da bien.
¿Quieres probar tú mismo la mitad de datos en vivo?
El servidor MCP de EODHD expone 72 herramientas de solo lectura entre más de 150.000 tickers y más de 70 mercados, con un plan gratuito que cubre la evaluación. Es la forma más rápida de sentir la diferencia entre una respuesta recuperada y una traída en vivo.
→ Consigue una API key gratuita de EODHD
Versión C: ambos, que es lo que realmente vas a lanzar
Ninguna de las dos versiones por sí sola es un buen producto. La versión RAG no puede decirte el precio de hoy. La versión MCP gasta una llamada a la API para explicar qué es un PER.
La arquitectura real enruta según el tipo de pregunta:
def route(question: str) -> str:
"""Decide which subsystem answers this question."""
# Signals that the question is about live state
live_signals = ["current", "today", "now", "latest", "price", "quote"]
if any(signal in question.lower() for signal in live_signals):
return "mcp" # fetch it
return "rag" # look it up
Esa comprobación de palabras clave es deliberadamente simplista. En producción, el enrutador suele ser el propio modelo: le das tanto la herramienta de recuperación como las herramientas de datos en vivo, escribes descripciones claras, y dejas que elija. Pero la lógica subyacente es exactamente esta división.
El resultado:
- "¿Qué mide el PER?" → RAG, instantáneo, coste casi cero
- "¿Cuál es el PER de Microsoft ahora mismo?" → MCP, en vivo, una llamada a la API
- "¿Es el PER de Microsoft alto para su sector?" → ambos: MCP para el número, RAG para el contexto de sector que lo interpreta
Esa tercera pregunta es donde la combinación se gana su sitio, y también es la forma de la mayoría de las preguntas reales de los usuarios.
Parte 5: Comparaciones relacionadas que la gente confunde
La confusión entre RAG y MCP suele viajar acompañada de otras tres. Aclararlas es rápido.
MCP vs API
Un servidor MCP suele ser un wrapper alrededor de una API, no un sustituto de ella.
La diferencia es para quién está diseñada la interfaz. Una REST API está diseñada para un desarrollador que lee documentación y escribe código de integración. Un servidor MCP está diseñado para un modelo que descubre las herramientas disponibles en tiempo de ejecución y lee descripciones para decidir qué llamar.
Igualmente necesitas la API por debajo. MCP estandariza cómo un modelo la descubre y la llama.
Usa la API directamente cuando estés escribiendo código de aplicación determinista. Usa MCP cuando un modelo necesite decidir, en tiempo de ejecución, qué operación realizar.
MCP vs agente
Están en capas distintas, así que compararlos es un error de categoría.
Un agente es lo que razona, planifica, y decide. MCP es cómo el agente alcanza el mundo exterior.
Un agente sin MCP puede pensar pero no actuar. MCP sin un agente es un servidor al que nadie llama. Claude Code es el agente; los servidores MCP son sus manos.
RAG vs fine-tuning
Ambos cambian lo que un modelo puede hacer, de formas distintas.
El fine-tuning ajusta los pesos del modelo. Enseña comportamiento: tono, formato, estilo específico de dominio, estructura consistente. Es caro, lento de iterar, y actualizar el conocimiento significa reentrenar.
RAG deja los pesos intactos y cambia el prompt. Enseña hechos. Actualizar significa reindexar un documento, lo que lleva segundos.
La regla práctica: haz fine-tuning para cómo debería comportarse el modelo, usa RAG para lo que debería saber. Si tu respuesta cambia cuando cambia un documento, eso es RAG. Si tu respuesta cambia cuando cambia tu guía de estilo, eso podría ser fine-tuning.
Parte 6: Eligiendo tu stack
Si vas a construir cualquiera de las dos mitades, así está el panorama en 2026.
Para la mitad de RAG, necesitas una base de datos vectorial. Qdrant es la que más uso, en parte porque se auto-hospeda limpiamente en Docker y en parte porque incluye un servidor MCP oficial, lo que significa que el mismo índice es accesible desde un script o desde Claude Code. Chroma es el punto de partida más suave si quieres algo corriendo en cinco minutos sin infraestructura. Weaviate y Pinecone completan las opciones serias, la segunda totalmente gestionada si prefieres no correr nada tú mismo.
Para la capa de orquestación, LlamaIndex sigue siendo el framework más enfocado específicamente en el problema de recuperación e indexación, mientras que LangChain es más amplio y más pesado.
Para la mitad de MCP, Composio enruta muchas aplicaciones a través de un único endpoint con carga de herramientas just-in-time, lo que aborda directamente el problema de saturación de contexto que viene de conectar una docena de servidores. Arcade.dev se toma en serio el problema de autenticación, inyectando tokens OAuth en la ejecución de herramientas sin exponerlos al modelo, algo que importa en cuanto hay más de un usuario implicado. Mem0 se sitúa de forma interesante entre las dos categorías: es un servidor MCP cuyo trabajo es la memoria semántica, que es, dicho de otra forma, recuperación.
Para observabilidad, una vez ambas mitades están corriendo vas a querer ver qué llamadas de recuperación devolvieron basura y qué llamadas a herramientas fallaron. Langfuse es de código abierto y auto-hospedable para eso.
El patrón que vale la pena notar: varias de estas empresas ahora ofrecen un servidor MCP para un producto que fundamentalmente va de recuperación. Las dos ideas están convergiendo en la práctica, no compitiendo.
Preguntas frecuentes
❓ ¿Son RAG y MCP lo mismo?
✅ No. RAG es una técnica para inyectar texto recuperado en un prompt para que el modelo pueda leerlo. MCP es un protocolo para dejar que un modelo llame herramientas y realice acciones. RAG hace que un modelo esté mejor informado; MCP lo hace capaz. Operan en capas distintas y se usan con frecuencia juntos en la misma aplicación.
❓ ¿Sustituye MCP a RAG?
✅ No, y ese planteamiento causa errores arquitectónicos reales. MCP es un estándar de transporte para llamar herramientas. Si tienes 50.000 documentos que buscar semánticamente, sigues necesitando embeddings, una base de datos vectorial, y un pipeline de recuperación. Lo que MCP cambia es cómo el modelo alcanza ese pipeline: en lugar de una integración a medida, lo expones como una herramienta a través de una interfaz estándar.
❓ ¿Cuándo debería usar RAG en lugar de MCP?
✅ Cuando la respuesta vive en un cuerpo de texto grande y relativamente estable: documentación, contratos, políticas, papers de investigación, artículos de soporte. RAG es más barato por consulta y responde más rápido que un viaje de ida y vuelta a una API. Cambia a MCP en el momento en que la respuesta dependa del estado actual, o en el momento en que el usuario quiera algo hecho en lugar de explicado.
❓ ¿Cuál es la diferencia entre MCP y una API?
✅ Un servidor MCP casi siempre envuelve una API. La API es la capacidad subyacente; MCP es la forma estandarizada en que un modelo la descubre e invoca. Las APIs están diseñadas para desarrolladores que leen documentación en tiempo de construcción. MCP está diseñado para modelos que leen descripciones de herramientas en tiempo de ejecución. Usas la API directamente en código determinista, y MCP cuando el modelo necesita elegir.
❓ ¿Necesito una base de datos vectorial para MCP?
✅ No. MCP no tiene ningún componente de recuperación propio. Las bases de datos vectoriales pertenecen a RAG. Solo meterías una en una configuración MCP si la herramienta que expones da la casualidad de que realiza búsqueda semántica, en cuyo caso la base de datos vectorial se sitúa detrás de la herramienta, no al lado.
❓ ¿Puede un servidor MCP correr RAG internamente?
✅ Sí, y este es un patrón de producción habitual. Construyes un pipeline de recuperación normal, y luego lo expones como una única herramienta como search_internal_docs. El modelo llama a una herramienta; detrás de ella, el embedding y la búsqueda vectorial hacen el trabajo. El modelo no necesita saber la diferencia.
❓ ¿Cuál es más barato de operar?
✅ RAG suele ser más barato por consulta una vez indexado, ya que pagas por una pequeña llamada de embedding más una búsqueda vectorial. MCP cuesta lo que cueste la API subyacente, que puede variar mucho: una cotización de acciones es barata, una sesión de navegador o una llamada de procesamiento de documentos no lo es. El modo de fallo caro es usar MCP para preguntas que RAG podría haber respondido desde un índice estático.
❓ ¿Qué pasa con MCP vs A2A?
✅ Problemas distintos. MCP conecta un modelo a herramientas. A2A (Agent-to-Agent) va de agentes comunicándose con otros agentes. Un agente podría usar MCP para llamar a una base de datos y A2A para pasarle trabajo a un agente especializado. Son capas complementarias, no alternativas.
❓ ¿Cómo decido rápido cuál necesito?
✅ Pregúntate si la respuesta cambiaría si volvieras a lanzar la consulta dentro de una hora. Si sí, es estado en vivo, así que MCP. Si no, es conocimiento estable, así que RAG. Luego pregúntate si el usuario quiere que pase algo. Si sí, es MCP de todas formas, porque RAG no puede actuar sobre nada.
La razón por la que esta comparación sigue circulando es que ambas tecnologías se hicieron populares casi al mismo tiempo y ambas se describen con la frase "le da a tu IA acceso a tus datos".
Esa descripción hace demasiado trabajo. El acceso para leer lo que escribiste es un problema distinto al acceso para hacer cosas en tus sistemas.
Acierta en esa división y la arquitectura prácticamente se diseña sola.
¿Construyendo algo con datos financieros?
EODHD cubre más de 150.000 tickers en más de 70 mercados, con tanto una REST API como un servidor MCP oficial, así que puedes probar cualquiera de las dos arquitecturas sin cambiar de proveedor.
→ Empieza con el plan gratuito¿Necesitas contenido técnico que explique conceptos difíciles con claridad?
Escribo tutoriales y comparativas orientadas a desarrolladores, con código funcional y trade-offs honestos.
→ Ve mi trabajo y contacta
¿Buscas contenido técnico para tu empresa? Puedo ayudarte, LinkedIn · kevinmenesesgonzalez@gmail.com