MCP, RAG y el LLM: qué hace de verdad cada capa en tu aplicación

Si ya desarrollabas software antes del auge de la IA, seguramente te has preguntado por qué de pronto todo necesita unas siglas. AI, LLM, RAG, MCP, agentes, bases de datos vectoriales. Muchos desarrolladores miran ese montón y piensan que han sacado adelante aplicaciones perfectamente válidas sin nada de eso. Una forma justa de atravesar la palabrería es preguntar qué añade realmente cada pieza a lo que ya tienes.

Empieza por algo que ya conoces

Supongamos que un cliente quiere ver sus últimas 5 transacciones facturadas. No es un problema nuevo, y tu aplicación ya lo resuelve.

User
 ↓
Application
 ↓
SQL
 ↓
Database
 ↓
Transactions

La consulta que hay detrás puede ser tan simple como esta:

SELECT *
FROM transactions
WHERE status = 'billed'
ORDER BY transaction_date DESC
LIMIT 5;

Y ya está. Sin IA, sin MCP, sin base de datos vectorial, sin agente, y funciona sin problemas.

Las variaciones cambian poco

Ahora supongamos que el cliente quiere 37 transacciones en lugar de 5. La aplicación simplemente acepta un parámetro.

limit = 37

O pide las transacciones facturadas de agosto por encima de ₹10.000. El backend lo convierte en la consulta correcta, de nuevo sin que intervenga MCP.

Aquí es donde MCP suele empezar a confundir. Es tentador suponer que MCP averiguará de algún modo cómo consultar tu base de datos. No lo hará. MCP no conoce tu esquema, no escribe tu lógica de negocio, no obtiene tus datos por su cuenta y no deja obsoleta la aplicación que ya has construido.

Entonces, ¿qué es MCP?

La descripción más corta que se sostiene es esta: MCP es un protocolo común que permite a las aplicaciones de IA encontrar herramientas y fuentes de datos y llamarlas de una forma coherente.

Imagina tres sistemas que no tienen nada que ver entre sí. Las transacciones están en una base de datos.

Transactions → Database

Los tickets de soporte están en un CRM o en Jira, y las políticas de la empresa en un sistema RAG respaldado por una base de datos vectorial.

Support Tickets → CRM/JiraCompany Policies → RAG / Vector Database

Un asistente de IA podría necesitar los tres. MCP puede publicar cada uno como una capacidad que el asistente encuentra y llama:

get_transactions()
get_support_tickets()
search_knowledge_base()

A partir de ahí, el modelo puede decidir que necesita información de los tres. La trampa es que MCP no hace nada del trabajo real. Algo por debajo sigue teniendo que sacar las transacciones, consultar los tickets, buscar en la base de conocimiento, aplicar los permisos y filtrar los resultados. Por eso MCP puede parecer una capa de más, y a veces es justo eso.

¿Entonces no sirve para nada?

Sí sirve, solo que resuelve un problema distinto del que la gente imagina al principio.

Si construyes una sola aplicación y el backend es tuyo, llamar directamente a tus funciones como herramientas es perfectamente razonable. La cosa cambia cuando hay varios consumidores.

AI Agent 1
AI Agent 2
AI Agent 3
Customer Chatbot
Internal Copilot

Ahora imagina que todos necesitan el mismo conjunto de sistemas:

CRM
Jira
Databases
Internal APIs
Knowledge Base
Cloud services

En ese punto tienes un problema de integración. Sin un protocolo compartido, cada aplicación de IA inventaría su propia manera de hablar con cada sistema. MCP ofrece en su lugar una interfaz común, y ahí es donde un estándar empieza a compensar.

Dónde encaja RAG

RAG es más fácil de ubicar, porque responde a una pregunta de recuperación. Alguien pregunta cuál es la política de reembolsos, y RAG busca en un gran montón de documentos y devuelve los fragmentos que importan.

MCP no sustituye eso. Incluso podrías publicar tu sistema RAG a través de MCP. Los tres papeles se separan con claridad:

• RAG encuentra la información relevante.
• MCP da a la IA una forma estándar de llegar a esa capacidad.
• El LLM entiende la pregunta, decide qué necesita y razona sobre lo que recibe.

Son trabajos distintos.

La verdadera lección

La conclusión no es que MCP sea increíble, ni que sea una pérdida de tiempo. Es esta: una moda es un mal motivo para añadir una capa, y un problema real que esa capa resuelve es uno bueno.

Llevas años construyendo APIs, bases de datos, autenticación, búsqueda, caché, integraciones y lógica de negocio. La IA no borra nada de eso. Te da una forma más de interactuar con todo ello. A veces una capa nueva mejora la arquitectura, y a veces es solo otra capa más. Saber en qué caso estás es lo más útil que te puedes llevar de todas estas siglas.