MCP vs function calling vs RAG: cuándo usar cada uno

Se buscan juntas porque las tres conectan un LLM con el mundo. Se confunden porque los demos las mezclan. La pregunta útil no es “¿cuál gana?” sino “¿en qué capa está mi problema?”.

• Si el modelo no puede hacer nada (crear una tarea, consultar una API) → te falta function calling (o tools equivalentes).
• Si no sabe lo que está en tus documentos o proyectos → te falta RAG.
• Si cada herramienta nueva te obliga a escribir otra integración → te falta MCP.

El pilar qué es MCP roza esta tabla. Acá la desglosamos con límites honestos.

Function calling (o tool use) es una capacidad del modelo: frente a un prompt, puede devolver “llama a create_task(title=…)” en vez de solo texto. El runtime de tu app ejecuta esa función y le devuelve el resultado al modelo.

Qué resuelve: acciones. Crear, actualizar, listar, enviar. Qué no resuelve: cómo se descubren esas funciones si mañana aparece otra app, ni cómo recuperar un documento largo que no cabe en el schema de una función.

Puedes tener function calling excelente sin MCP (un set fijo de tools en tu app) y sin RAG (el modelo solo ve lo que le pasas en el prompt). Es el caso más común en productos con asistente propio.

RAG (Retrieval-Augmented Generation) busca trozos relevantes en un índice y los inyecta en el prompt antes de que el modelo responda. No “entrena” el modelo con tus datos: le pasa contexto a tiempo.

Qué resuelve: conocimiento que cambia o que es privado. Qué no resuelve: ejecutar una acción. Recuperar el párrafo de un contrato no crea la tarea de revisión.

“RAG local” añade una restricción: el índice vive en tu dispositivo, no en la base vectorial de un tercero. Cómo se ve eso en la práctica está en RAG local explicado. Spoiler útil: local suele ser el índice, no necesariamente cada llamada al modelo.

MCP no es un modelo ni una técnica de recuperación. Es un protocolo: cliente y servidor hablan el mismo idioma para listar e invocar tools, leer resources y servir prompts. El cliente descubre capabilities al abrir la sesión MCP; no las tiene fijadas en el código.

Qué resuelve: interoperabilidad. Un servidor que escribiste hoy puede hablar con un cliente que no existía cuando lo publicaste. Qué no resuelve: por sí solo, ni la calidad de las respuestas ni la búsqueda semántica. Un servidor MCP puede exponer un tool que por debajo hace RAG; MCP no es el RAG.

Un agente decente en 2026 suele verse así:

1. El usuario pregunta. Un paso de RAG trae los 5 trozos más parecidos de su workspace.
2. El modelo, con ese contexto, decide si responde en texto o si necesita una acción → function calling.
3. Si la acción o el dato viven en otra app, el cliente habla con esa app por MCP en vez de un conector exclusivo.

MCP puede transportar un tool cuyo cuerpo es function calling interno, o un resource cuyo contenido salió de un índice RAG. Las capas se apilan; no se votan.

• Chat sobre un PDF único: pega el texto o haz RAG simple. MCP sobra.
• Asistente dentro de una sola app, con 20 tools fijas: function calling nativo. MCP hacia adentro suele ser más protocolo que valor — el protocolo brilla hacia afuera.
• Quieres que Claude o Cursor lean tu producto: ahí sí un servidor MCP. Function calling solo dentro de tu UI no les sirve a ellos.
• Tus datos no pueden salir de la máquina: el índice puede ser local (RAG local), pero si el modelo es una API, el contexto recuperado viaja. Ninguna de las tres capas te salva de esa frase si no la lees completa.

Function calling hace. RAG sabe. MCP conecta. Si alguien te vende una de las tres como reemplazo de las otras, está vendiendo un demo, no una arquitectura.

En Hito el asistente dentro de la app usa function calling nativo, el contexto semántico sale de un RAG con índice en el navegador, y el servidor MCP existe para que clientes externos lean el workspace. Tres capas, tres papeles. Sin cuenta, con tu propia API key.