MCP vs CLI vs RAG: ¿Cuál Deberías Usar para Conectar tu IA?

Si en algún punto te han pedido crear un chat que se comunique con la información de una empresa, una base de datos o cualquier origen de datos, este artículo es para ti. Vamos a ver cómo una IA puede acceder a datos personales, privados o de empresa para construir aplicaciones de verdad.

Y no es un enfoque a nivel de usuario. Vamos a hablar de cuatro técnicas concretas para lograrlo: context stuffing, MCP, CLI y RAG, con una mención final al fine tuning. La idea es que al terminar sepas cuál te conviene según lo que realmente necesitas construir.

El problema de fondo

Lo que queremos es que una IA que ya existe pueda comunicarse con datos que tú ya tienes almacenados en algún lugar. Ese lugar suele ser uno de tres:

• Una base de datos, que es lo más común.
• Archivos, como Excels o documentos de Word. Muchas empresas siguen trabajando así.
• Una API, porque ya tienen un sistema desarrollado que expone sus datos de forma programada.

El detalle es que los LLM no se conectan directamente a ninguno de estos. Entonces la pregunta es: ¿de qué forma hacemos el puente?

La respuesta depende de lo que quieras lograr. No es lo mismo querer una interfaz tipo ChatGPT pero con tus datos, que un asistente con el que conversas por WhatsApp o Telegram, o un agente que se instala en un servidor y ejecuta acciones reales sobre tu sistema. El agente es el ideal, porque no solo consulta tus datos: también puede crearlos y ejecutar acciones apoyándose en otras herramientas. Pero todos pasan por el mismo punto: necesitas una forma de conectar tu modelo con tu origen de datos.

Aquí van las cuatro, ordenadas de lo más fácil a lo más complejo (y más caro).

1. Context stuffing: inyectar el contexto en la conversación

Es el más fácil. Le pides a un agente o editor con IA que te cree un chat: una aplicación web que se comunica con alguna API de IA. Esa API puede ser de OpenAI (GPT), de Anthropic (Claude), de proveedores chinos como GLM, Kimi o MiniMax, o un agregador como OpenRouter que te da variedad de modelos.

El problema es que un chat que solo habla con una IA genérica no sirve de mucho, porque no accede a tus datos. La forma más básica de resolverlo es incrustar un prompt dentro de tu aplicación: además de lo que escribe el usuario, tu app envía un prompt fijo que describe de qué trata todo y agrega datos de contexto.

¿Recuerdas cuando podías crear tus propios GPTs personalizados? Por debajo no hacían nada más complicado que esto: inyectar un prompt adicional del tipo "compórtate como un experto en X". Si vas a crear una app sobre datos médicos, plantas, animales u objetos, esta es la forma más sencilla de empezar, y no te toma ni 10 minutos.

Esto funciona gracias al contexto del modelo, que hoy es bastante amplio. Para que veas cómo evolucionó:

Como referencia, un token equivale a unos cuatro caracteres. Y ya se habla de modelos que apuntan a los 12 millones de tokens, diez veces el millón actual. Imagina cuánta información cabe ahí dentro.

Es la forma más básica y poco "producida", pero es un excelente punto de partida.

2. MCP: la API para que las IAs hablen con tu API

El context stuffing inyecta texto fijo. Pero lo que normalmente quieres es que la información cambie con el tiempo. Ahí entra el MCP (Model Context Protocol).

Olvidemos el chat un segundo. Antes de los LLM ya existían los sistemas que registran datos, y el rey para eso siempre fue la base de datos. Nadie escribe directamente sobre ella: se desarrolla una aplicación de servidor, normalmente una API. Por eso se le ha pagado durante años a tantos programadores: para crear bases de datos, backends y frontends que se comunican entre sí.

Ese paso no te lo puedes saltar. Mucha gente cree que basta con un chat y subirle archivos, pero si tus datos son importantes y crecen con el tiempo (compras, ventas, reportes, usuarios), vas a necesitar una base de datos de verdad. Eso no ha cambiado. Lo que cambió es cómo interactúas con esos datos.

El MCP no reemplaza a la API: la envuelve, es como un wrapper. Bajo este diseño tienes que crear el frontend con el chat, la API, la base de datos y, además, el código del MCP. ¿Y qué hace el MCP al final del día? Llama a tu API, pero usando lenguaje natural.

Si desarrollas una ruta como GET /api/users, esta te devuelve un JSON con objetos. Con MCP no llamas la ruta directamente: le dices "dame datos de usuarios" y el MCP traduce eso a la llamada correspondiente. La API tiene que existir de todas formas; solo le estamos agregando una capa para que el modelo pueda comunicarse con ella.

Yo siempre veo al MCP como "la API de la API". Antes creabas base de datos + API; ahora, encima, creas otra API para que la IA pueda hablar con la tuya. Suena redundante, pero ese puente es lo que habilita casi todo lo que hacen los agentes hoy.

Algunos puntos clave:

• Es un estándar abierto. Puedes crear MCPs en cualquier lenguaje, aunque típicamente se usan Python y JavaScript/TypeScript por su cercanía al ecosistema de IA y de herramientas de consola.
• No importa que tu backend esté en Java o PHP: el MCP puede estar en TypeScript sin problema.
• Por debajo siguen siendo llamadas HTTP (fetch). Lo que lo caracteriza es el concepto de tools: una tool no es más que una función con un nombre, una descripción, parámetros de entrada y una respuesta. Lo "inteligente" está en la descripción: la IA la lee y decide cuándo llamarla.

Otra gran ventaja: como el MCP es básicamente una API para IAs, cualquier cliente que soporte MCP puede usar el tuyo. Claude Desktop, ChatGPT en modo desarrollador, editores como Cursor o VS Code, herramientas como Codex... todos pueden conectarse a tu MCP. En Claude, por ejemplo, esto aparece como conectores: le pasas la URL del MCP y, si requiere autenticación, te pedirá el OAuth correspondiente.

Un ejemplo real: tengo el MCP de Notion conectado a Claude. Le pido "dame la lista de proyectos de mi página de projects", y por debajo hace llamadas a la API de Notion, recupera los datos y me los lista como texto. Esos son literalmente mis datos en Notion.

Resumen de esta parte: si te pidieron un chat inteligente que consulte información de una empresa y no quieres meterte con agentes ni entrenar modelos, investiga el MCP. Si sabes crear una API + un MCP, puedes crear una aplicación inteligente. No es excesivamente rápido respondiendo, pero para muchos casos es más que suficiente.

3. CLI: el atajo del agente (mi favorito para empezar)

Hay otra forma de lograr lo mismo, sobre todo si quieres crear tu propio asistente personal, y es no usar un MCP.

Aplicaciones de escritorio y terminal como Claude Desktop, Cursor, VS Code, Claude Code, Codex u OpenCode viven dentro de tu sistema operativo. Y como viven ahí, pueden ejecutar comandos del sistema. Esa es justamente la característica que define a un agente: la capacidad de hacer una acción. Y para mí, una acción se resume casi siempre en ejecutar un programa, es decir, un comando del sistema, un CLI.

Si estas herramientas pueden ejecutar comandos, entonces si tú creas tu propio CLI, también lo van a ejecutar. Y ese CLI puede, a su vez, llamar a tu API. Llegamos exactamente al mismo lugar que con el MCP: la IA ejecuta un comando, el comando hace la llamada y accede a tu origen de datos.

¿Por qué me gusta más que el MCP en muchos casos? Porque los MCP, aunque la idea es buena, son una molestia de mantener: bastante verbosos, algo lentos y no tan triviales de sostener. El CLI lo puedes crear en cuestión de horas, no de días.

Eso sí, no siempre es reemplazable. Si vas a usarlo dentro de chats alojados como ChatGPT o Claude web, necesitas sí o sí un MCP. Pero si estás en un entorno donde puedes acceder a herramientas de consola, el CLI suele ser el camino más simple.

Esta es justamente la idea detrás de proyectos como OpenClaw o Hermes: se instalan en un servidor o computador y, como tienen acceso al sistema, ejecutan programas de consola para conectarse con servicios externos. No es casualidad que hoy casi todas las plataformas tengan su CLI oficial: Stripe, AWS, Google Cloud, Azure, Notion... y la razón ya no son las personas, son los agentes.

Un ejemplo concreto con Hermes: le doy acceso a una máquina Linux donde tengo mis propios comandos. Le mando un mensaje de voz "crea una tarea de prueba en mis tareas usando el comando th". Hermes transcribe el audio, ejecuta th (un CLI que yo creé y que se comunica con mi sistema de tareas), y la tarea aparece en mi aplicación. Sin RAG, sin modelo avanzado, sin nada complicado. También funciona al revés: "usando th, lista mis últimas tareas" y me trae los datos reales. No es instantáneo, pero es un puente tan sencillo que casi cualquiera puede construirlo, e incluso es más fácil que un MCP.

4. RAG: la forma "correcta" (pero más trabajosa)

El RAG (Retrieval Augmented Generation) es lo que la mayoría imagina cuando piensa en un chat inteligente: el chat conectado directamente a una base de datos a través de una API.

El flujo es este:

1. El usuario escribe en el chat.
2. El chat llama a tu API.
3. La API se apoya en una API de IA (OpenAI, Anthropic, etc.).
4. Esa IA carga información desde tu base de datos.
5. La API responde con tus datos tal cual.

Si quitaras la API de IA, esto sería una aplicación web de toda la vida. ¿Qué la convierte en RAG? La forma en que se inyectan los datos de la base de datos dentro del modelo. Y ahí está el problema.

La IA no entiende tablas. Si tienes un usuario Juan, 20 años, S/ 3.000 en su cuenta, con fechas y transacciones, ese formato no es el que las IAs procesan. Lo único que entienden son números, y no sueltos, sino conjuntos de números relacionados en matrices: lo que se conoce como vectores. Convertir tus datos a ese formato se llama generar embeddings.

Para esa conversión existen frameworks como LangChain, muy popular en el mundo de la ciencia de datos. También puedes generar embeddings directamente con la API de OpenAI. Pero ojo: los embeddings no son genéricos. Cada modelo interpreta los suyos a su manera, así que tienes que generarlos con el mismo proveedor que vas a usar para consultar (OpenAI, Gemini, Claude...).

Por eso normalmente guardas dos versiones de tus datos: la información tradicional y su versión vectorial. Y para esa segunda versión necesitas una base de datos vectorial, como Pinecone, Qdrant o Chroma.

¿Tienes que complicarte tanto? Por lo general, no. Existen plugins para bases de datos comunes que añaden soporte de vectores sin instalar una base aparte:

• pgvector para PostgreSQL
• Soporte equivalente en MongoDB, SQLite y otras

Lo que más te va a interesar de todo esto es cómo conviertes tus datos a ese formato y con qué estrategia lo mantienes actualizado.

Al final, todo esto sirve para que cuando le preguntes "¿cuánto dinero tiene Juan en su cuenta?", el modelo no solo entienda el texto, sino que sepa de quién hablas y qué buscas, recupere la información vectorizada y responda "Juan tiene 3.000 en su cuenta". Está sobresimplificado, pero esa es la idea.

El riesgo del RAG: alucinaciones y temperatura

Hay algo que debes saber antes de mandar un RAG a producción. Como estos modelos saben de todo y responden de todo, si están mal configurados se desvían. Ha pasado con chats de soporte de varias plataformas: alguien pide "hazme un ejemplo en React" y el chat, en lugar de negarse, se pone a generar código como si fuera ChatGPT.

Eso se controla con la temperatura. Por lo general la pones en 0, que es como decirle "no imagines cosas". La temperatura está directamente ligada a las famosas alucinaciones: si no la ajustas bien, ante "¿cuánto dinero tiene Juan?" el modelo puede inventarte un "4.000" en vez de admitir que no tiene el dato. Esa información errónea es un riesgo real.

El RAG es lo que en teoría deberías construir, pero no es sencillo. Muchos han fallado con esto. Mi consejo: practica antes de lanzarlo a producción, sobre todo porque consume dinero y las APIs hoy están caras.

Mención aparte: Fine Tuning

Hay una quinta vía más avanzada que no considero tanto para aplicaciones, sino para quien quiere algo mucho más custom y tiene los recursos: empresas, universidades. Es el famoso fine tuning.

La idea: en lugar de que el chat consulte una base de datos cada vez, el modelo ya tiene los datos cargados dentro de sí mismo. Los modelos son, de cierta forma, como una base de datos en tiempo real. Esto tiene sentido cuando tu información no cambia mucho: documentos, expedientes, información histórica o clínica. Una base de datos está pensada para lo dinámico; el fine tuning, para lo estable.

Para hacerlo necesitas un modelo abierto, porque requieres acceso al modelo. Hay muchos: Qwen, Gemma de Google, modelos open source de todo tamaño y para todo tipo de tarea. A diferencia de los modelos comerciales (gigantes, muy producidos, listos para el consumidor), aquí entrenas algo enfocado en tareas muy puntuales.

Herramientas como Unsloth te permiten entrenar tus propios modelos localmente. El reto no es tanto técnico (cualquiera puede aprenderlo) sino de hardware: necesitas equipo especializado, bastante VRAM, o máquinas dedicadas como el DGX Spark de NVIDIA o el equivalente reciente de AMD. La ventaja es que, una vez entrenado, ya no necesitas ni una API propia: instalas el modelo y consultas directamente con la información dentro.

¿Cuál deberías elegir?

Es relativamente sencillo llegar a una aplicación propia conectada con IA. La verdadera pregunta es cuánto necesitas que la IA sepa y qué tan rápido quieres que responda.

Mi recomendación según el caso:

• ¿Quieres algo sencillo para una empresa, operable desde un chat? Ve por chat + CLI y desarrolla tus propias herramientas. Es lo más fácil y lo puedes tener en cuestión de horas.
• ¿Necesitas integrarte con chats alojados (ChatGPT, Claude) o que terceros usen tu integración? Entonces MCP. No es complejo en sí, pero da uno que otro problema y el código es algo más difícil de mantener.
• ¿Quieres lo ideal y "correcto"? RAG, pero prepárate: te obliga a alterar la arquitectura (base de datos vectorial o plugins, más recursos en la nube). Si puedes evitarlo y solo necesitas que la IA responda algo puntual, las opciones anteriores te lo resuelven con menos dolores de cabeza.
• ¿Tienes recursos y quieres aprender o algo muy custom? Fine tuning.

Un apunte sobre los clientes: casi todos te van a pedir "quiero entrenar mi modelo de IA" sin saber realmente lo que están pidiendo. Creen que entrenar un modelo es fácil o que cargarle su información es como pasárselo directo. Ahora que conoces las opciones, no te preocupes tanto por darle lo que cree que quiere: elige lo que de verdad le conviene según lo que va a hacer. Eso sí, recuerda que la opción más compleja también es la más cara.

¿Tienes dudas o quieres que profundice en alguna de estas técnicas en un próximo artículo? Déjalo en los comentarios. Y si necesitas asesoría personalizada sobre IA, agentes o cualquier tema de desarrollo, puedes reservar una sesión en fazt.dev.