MCP explicado: cómo funciona Model Context Protocol

Los LLM llevan tiempo pudiendo llamar herramientas, pero Model Context Protocol (MCP) aporta una forma estructurada y estandarizada de hacerlo.

Aun así, todavía hay confusión sobre qué es realmente MCP.

Muchos suponen que MCP es una app, una API o alguna herramienta, pero no es ninguna de esas cosas. Es un protocolo, y eso significa algo muy específico.

Vamos a desglosarlo.

Si solo quieres ver qué permite MCP en la práctica, mira este video corto:

Qué es un protocolo

Un protocolo es simplemente un conjunto de reglas que define cómo dos o más sistemas se comunican entre sí.

No hace nada por sí mismo. Solo define la estructura y las expectativas de una conversación entre dos entidades. Piensa en él como un lenguaje compartido con reglas gramaticales estrictas que las computadoras siguen para intercambiar información.

Los sistemas postales hacen algo parecido. Todas las oficinas postales de un país determinado siguen un formato de dirección estandarizado para enviar cartas.

O piensa en ello como USB-C para herramientas de IA. Hace veinte años, el mercado estaba lleno de distintos tipos de cables de carga y datos. Del mismo modo, los ecosistemas de IA han tenido múltiples formas de pasar herramientas a los modelos de lenguaje. Frameworks como LangChain, Haystack y Pydantic AI definían sus propios formatos para integrar herramientas, lo que significaba que, si un desarrollador quería escribir un conjunto de herramientas para Google Maps, tenía que hacerlo para cada tecnología específica.

Para hacerlo más concreto, veamos el protocolo más popular, HTTP (Hypertext Transfer Protocol), que impulsa los sitios web. HTTP define, entre otras cosas, cómo un navegador (cliente) solicita una página web a un servidor web y cómo debe responder el servidor.

Este es un ejemplo de un ciclo de solicitud-respuesta HTTP:

1. El navegador realiza una solicitud HTTP

Cuando escribes https://example.com en tu navegador, el navegador envía una solicitud HTTP estructurada al servidor web:

Estos son los parámetros y valores HTTP usados en nuestro ejemplo:

"GET" – Esta es la acción (solicitar una página web).
"/index.html" – La página web específica que se solicita.
"HTTP/1.1" – La versión del protocolo que se está usando.
"Host: example.com" – El nombre de dominio del sitio web.
"User-Agent: Mozilla/5.0" – Información sobre el navegador que realiza la solicitud.

El servidor web sabe cómo interpretar esta solicitud porque HTTP estandariza este formato. Entiende este “lenguaje”.

2. El servidor responde usando el protocolo HTTP

El servidor procesa la solicitud y devuelve una respuesta HTTP estructurada:

"HTTP/1.1 200 OK" – El código de respuesta (200 significa éxito).
"Content-Type: text/html" – El tipo de contenido que se devuelve.
"Content-Length: 512" – El tamaño de la respuesta.
Contenido HTML – El contenido real de la página web (solo hay un titular "Welcome to Example.com")

Importante: HTTP en sí no almacena páginas web ni las muestra. Solo define las reglas sobre cómo pueden comunicarse los navegadores web y los servidores web. Cualquier sistema que siga esas reglas puede comunicarse a través de la Internet definida por HTTP.

Cómo funciona MCP como protocolo

Ahora, apliquemos la misma lógica a MCP (Model Context Protocol).

MCP es un protocolo para que los agentes de IA hablen con herramientas externas y fuentes de datos. Al igual que HTTP, no almacena datos ni ejecuta tareas por sí mismo. Simplemente define una forma estandarizada para que la IA solicite y recupere información de herramientas.

Qué son esas “herramientas”, podrías preguntar.

En el contexto de los LLM, las herramientas son sistemas externos, API o servicios con los que la IA puede interactuar para ampliar sus capacidades más allá de la generación de texto. Permiten que los agentes de IA obtengan datos en tiempo real, reserven citas o envíen mensajes a tus amigos, lo que los hace mucho más útiles para necesidades del mundo real.

Supongamos que le preguntas a un agente de IA:

“¿Qué hora es ahora en Londres?”

Como la IA en sí no conoce la respuesta correcta, porque los modelos de IA tienen una fecha de corte de conocimiento (octubre de 2023 para los modelos de OpenAI), necesita obtener datos en vivo de un servicio horario. Pero en lugar de usar HTTP para solicitar una página web, la IA usa MCP para solicitar datos de hora.

Esto es lo que ocurre:

1. El agente de IA realiza una solicitud MCP al servicio horario (ejemplo)

"method": "tools.call" → La IA está llamando a una herramienta externa.
"tool": "get_time" → El nombre de la herramienta que quiere usar.
"args": { "location": "London" } → Los parámetros de entrada específicos.

Igual que en HTTP, esta solicitud sigue un formato estricto para que cualquier herramienta compatible con MCP sepa exactamente cómo interpretarla.

2. El servidor horario MCP responde

La herramienta externa (servidor horario) sigue las reglas de respuesta de MCP y devuelve:

"status": "success" → Confirma que la solicitud se procesó correctamente.
"result" → Contiene los datos reales de hora.

Ahora, el agente de IA puede tomar estos datos y componer una respuesta real para el usuario con:

“La hora actual en Londres es 12:20 PM (GMT).”

Para resumir y aclarar la confusión:

“MCP es una app.” → No, MCP es un conjunto de reglas. Necesitas software de IA y herramientas que implementen MCP para usarlo realmente, igual que la app de Instagram necesita servidores de Instagram activos para responder a solicitudes HTTP y entregar datos.

“MCP es una base de datos.” → No, MCP no almacena datos. Ayuda a los agentes de IA a hablar con bases de datos o API.

“MCP es como una API.” → No exactamente. Una API es una forma específica de interactuar con un sistema, mientras que un protocolo (como MCP o HTTP) define una forma universal en la que muchos sistemas diferentes pueden comunicarse. MCP es un lenguaje que un sistema de IA puede usar para interactuar con muchas API reales (hora, bases de datos, Stripe, Slack, etc.).

Por qué MCP es interesante

Ahora que sabemos que MCP es una forma estandarizada para que el software de IA interactúe con herramientas y apps externas, y que MCP no es una API, entendamos por qué la comunidad de desarrolladores de IA (nosotros incluidos) se entusiasmó con él.

Como MCP no es una API, sino que permite que las apps de IA interactúen con API reales a escala, ayuda a que los proyectos que requieren conectarse con muchos sistemas externos arranquen más rápido. Las herramientas también dan alcance a un modelo, y lo que ocurrió en el incidente de OpenAI y Hugging Face muestra cómo se ve ese alcance cuando supera la tarea. Para hacer esto, los desarrolladores a veces tendrían que pasar por un ciclo completo de desarrollo de integración con API, pero hoy suelen usar bibliotecas existentes o proyectos open-source (por ejemplo, disponibles en GitHub) que proporcionan la funcionalidad necesaria.

Usar estas bibliotecas acelera el inicio del desarrollo, pero integrarlas correctamente con tu sistema (si no es compatible con la implementación que encontraste en GitHub) todavía requiere esfuerzo para que la herramienta funcione con la IA.

Con MCP, una vez que el framework está implementado, agregar una nueva integración (por ejemplo, integrar Google Drive) podría reducirse a conectarse al servidor MCP de Google Drive con unas pocas líneas de código. No encontrarás problemas de compatibilidad porque ambos usan el mismo protocolo: MCP.

Comparemos ambos enfoques para ver las diferencias con más claridad.

Integración estándar frente a uso de Model Context Protocol (MCP)

Para hacer concreta esta comparación, veamos cómo agregar acceso a archivos de Google Drive a un AI Agent, primero manualmente y luego con una herramienta compatible con MCP.

Integración estándar

1. Encontrar y adaptar una biblioteca: buscas un cliente de la API de Google Drive o un proyecto open-source. Google proporciona bibliotecas cliente (por ejemplo, Google Drive API para Python); la incluyes en tu proyecto. Aun así, necesitas asegurarte de que funcione con el entorno de tu IA.

2. Implementar la lógica: escribes funciones para, por ejemplo, buscar archivos u obtener un documento desde Drive. Cuando la IA necesita algo, debe llamar a estas funciones. Das formato a la solicitud de la IA como llamadas específicas a la API de Google Drive. Después de recibir una respuesta de Google, extraes el contenido para devolverlo al contexto de la IA.

3. Gestionar errores y casos límite: agregas código para manejar casos como “archivo no encontrado”, errores de permisos o límites de tasa de la API. Si la API de Google devuelve un error, lo capturas y quizás respondes con un mensaje de disculpa o le pides a la IA que reformule. También necesitas protegerte contra que tu IA envíe demasiadas solicitudes demasiado rápido.

4. Mantener: con el tiempo, si Google actualiza su API o la biblioteca, debes actualizar tu código. Si encuentras un bug en la biblioteca, podrías tener que parchearlo o buscar otra fuente. En la práctica, te conviertes en el mantenedor de esta integración con Google Drive dentro de tu aplicación de IA.

Este proceso se extiende a otras herramientas: quieres agregar Slack o una base de datos a tu IA. Necesitas repetir todo el proceso para cada una.

Integración con MCP

Ahora veamos cómo sería ese proceso al usar MCP.

Primero, definamos conceptos clave:

Cliente – una aplicación de IA (ChatGPT, Claude app, Quickchat AI) que establece una conexión con uno o más servidores y solicita información o acciones para realizar tareas indicadas por un usuario.

Servidor – cada servidor puede conectarse a algo como una base de datos, una API (Google Drive) y definir un conjunto de “herramientas” o datos que puede proporcionar. En este caso, el servidor es un programa que expone estas herramientas y capacidades al Cliente (app de IA).

Los desarrolladores, según lo que quieran hacer, pueden elegir cualquiera de los dos lados: crear un servidor para exponer datos o crear un cliente de IA que pueda hablar con cualquier servidor. La mayoría quiere la segunda opción, pero aun así empecemos por el lado del servidor para entender cómo funciona MCP paso a paso:

• Inicializar un servidor MCP. Un desarrollador o administrador de sistemas configura un servidor MCP para una herramienta o fuente de datos determinada. Un servidor MCP suele ser simplemente un programa pequeño que implementa la especificación de MCP. Por ejemplo, hay un servidor MCP de Google Drive preconstruido disponible que sabe cómo buscar y obtener documentos.

  Al inicializar el servidor, le das acceso al sistema objetivo (Google Drive). Luego, el servidor expone un conjunto de herramientas correspondientes a acciones o consultas que puede manejar. Es básicamente un adaptador de API que habla MCP por un lado y el servicio nativo por el otro.

  Una vez que el servidor está en ejecución, espera solicitudes.

• Conectar un LLM (cliente) a un servidor MCP. A continuación, la aplicación de IA (el lado “cliente”) necesita conectarse a ese servidor. En la práctica, si estás usando una plataforma de IA que admite MCP (como Claude Desktop), la configurarías con la dirección o el comando para iniciar el servidor. Una vez conectado, el cliente establece una sesión con el servidor siguiendo el handshake de MCP. Si estás usando la interfaz de Claude, verías que Claude está “conectado” a ciertos servidores MCP (la UI podría indicar los conectores disponibles).

Así se ve en la UI de Claude

• Descubrir herramientas disponibles. Con la conexión establecida, lo primero que hay que hacer es averiguar qué ofrece el servidor (a veces, esto ocurre automáticamente después de conectarte al servidor). El cliente MCP envía una solicitud tools/list al servidor (esto está definido en el protocolo). El servidor responde con una lista de sus herramientas disponibles, cada una con detalles como nombre, descripción y esquema de entrada.

  Por ejemplo, un servidor podría responder que tiene disponibles las herramientas create_file(path, content), read_file(path), and search_files(query). Luego, el cliente pone esta información a disposición del LLM. En muchas implementaciones, el cliente dará formato a estas descripciones de herramientas y las incluirá en el contexto del modelo (por ejemplo, agregándolas al prompt de sistema: “Tienes acceso a las siguientes herramientas… [lista de herramientas]”).

Aquí hay un prompt de sistema de IA junto con el mensaje del usuario que solicita la hora actual

Con las herramientas MCP implementadas, se integra una herramienta llamada “get_current_time”, lo que permite que la IA acceda a un recurso externo y obtenga la hora exacta en Londres

Esto significa que no necesitas anticipar y programar todas las acciones potenciales que tu app de IA podría necesitar para completar una tarea. Con MCP, la IA puede descubrir todas las acciones posibles sobre la marcha preguntando a un servidor MCP y elegir lo que sea necesario.

• Usar una herramienta mediante MCP. Cuando la IA necesita realizar una acción u obtener datos, invocará una herramienta mediante MCP. Desde la perspectiva de la IA (especialmente para modelos como Claude que admiten de forma nativa el uso de herramientas), decidirá en su razonamiento: “Debería llamar a la herramienta X con estos parámetros.” El cliente MCP captura esa intención y envía una solicitud tools/call en el formato MCP al servidor apropiado (servidor MCP de Google Drive).

• El servidor MCP actúa como puente. Recibe una solicitud estructurada y compatible con MCP del agente de IA, la asigna al endpoint correcto de la API de Google Drive, reescribe la solicitud como una llamada real a la API de Google Drive, ejecuta la solicitud, procesa la respuesta y vuelve a formatearla como una respuesta compatible con MCP antes de enviarla de vuelta al agente de IA.

  Vale la pena señalar que los servidores MCP siguen un enfoque estructurado para gestionar errores, lo que garantiza que los AI Agents puedan interpretarlos y actuar sobre ellos de manera eficaz.

  Supongamos que un AI Agent está usando una herramienta MCP para encontrar un archivo en Google Drive. Si la solicitud incluye un ID de archivo no válido (por ejemplo, una cadena de cinco caracteres en lugar del formato esperado), el servidor MCP devolverá un mensaje de error:

  En lugar de fallar sin más, el AI Agent puede tomar esta respuesta estructurada y reformularla como retroalimentación fácil de entender para el usuario:

  “Parece que el ID de archivo que proporcionaste es demasiado corto. Los IDs de archivo de Google Drive suelen tener 28 caracteres. ¿Podrías comprobarlo y volver a intentarlo?”

  Este enfoque garantiza que los errores no lleven a callejones sin salida, sino que se conviertan en oportunidades para que el AI Agent guíe al usuario hacia una resolución correcta.

• Responder la pregunta/solicitud del usuario. Una vez que el servidor MCP devuelve un resultado, el cliente MCP entrega esos datos de vuelta a la app de IA. Luego, el modelo incorpora el resultado en su razonamiento o directamente en la salida que genera para el usuario.

  Si el usuario solicita la creación de un nuevo archivo de Google Sheets, la respuesta del servidor (que contiene el ID del archivo y un enlace generado) se pasará al modelo. Luego, el modelo responderá al usuario con: “Buenas noticias. Tu nuevo archivo de Google Sheets está listo. Puedes acceder a él aquí: [link].”

Durante todo este proceso, la IA mantiene el control del flujo: decide cuándo llamar a una herramienta y cómo usar el resultado para formar su respuesta. Mientras tanto, el desarrollador no tiene que orquestar manualmente estos pasos, el framework MCP y el modelo de IA se encargan. El resultado final es que el usuario puede hacerle a la IA preguntas o tareas complejas que requieren información o acciones externas, y la IA puede ejecutarlas de forma autónoma mediante MCP y devolver un resultado.

Beneficios de usar un MCP

Observa cómo este enfoque abstrae muchos detalles: el cliente no gestionó claves de API ni códigos de estado HTTP, eso lo gestiona el servidor MCP.

El punto principal es la simplicidad en el punto de integración: “pedimos” clientes y los recibimos. La lógica de cómo obtenerlos está encapsulada en otro lugar. Significa que un desarrollador que trabaja del lado de la IA no necesita escribir nuevas llamadas HTTP para cada nueva acción, solo invoca herramientas por nombre. El trabajo pesado (autenticación, llamadas a los endpoints de Google Drive, formato de la respuesta) se hace en el código del servidor MCP, que es reutilizable y estandarizado.

Este es un resumen de los beneficios clave:

• Reduce el código de enlace específico de API. Antes de MCP, hacer que una IA usara un servicio externo normalmente requería escribir bastante código de “enlace”: llamar a la API, transformar la respuesta en texto que el modelo pudiera procesar, luego analizar la salida del modelo para quizás llamar a otra API, etc. Con MCP, gran parte de ese enlace se elimina. El cliente del modelo y el servidor gestionan el intercambio de datos de forma estructurada, por lo que no necesitas transformar manualmente otros formatos (como JSON) a texto o viceversa, el protocolo lo hace. Tampoco tienes que escribir lógica para decidir cuándo llamar a qué. La IA (guiada por las descripciones de las herramientas y su propio razonamiento o prompt) lo hace.

• Conectores reutilizables y compartidos en lugar de wrappers de API puntuales. Con MCP, escribes una integración una vez y puedes reutilizarla en muchos proyectos y sistemas de IA. Por ejemplo, podrías crear un servidor MCP para la wiki interna de tu empresa. Cualquier app de IA que admita MCP puede conectarse a ese único servidor para consultar la wiki. No necesitas volver a implementar “búsqueda en wiki” para cada nuevo chatbot de IA o cada proveedor de LLM diferente. Esta reutilización marca un cambio respecto del pasado, cuando cada equipo podía escribir su propia integración ligeramente diferente para la misma API. MCP fomenta una biblioteca de conectores que se pueden compartir y mejorar colectivamente.

• Integración plug-and-play con distintos LLM. MCP es agnóstico al modelo. Al protocolo no le importa si el cliente es Claude, GPT-4, DeepSeek o cualquier modelo futuro, siempre que el cliente pueda manejar la interfaz MCP. En el futuro, si quieres cambiar a otro modelo, puedes hacerlo sin reescribir todas tus integraciones.

• Mantenimiento más sencillo. Como es un estándar abierto, hay una comunidad creciente que contribuye servidores preconstruidos (para bases de datos, API populares, etc.) que puedes aprovechar en lugar de construir desde cero. A medida que integras más sistemas, MCP ayuda a evitar el “espagueti” de muchas integraciones punto a punto. Y no necesitas supervisar todas las actualizaciones de API de otros proveedores.

Las integraciones con API quedarán obsoletas

Tanto las integraciones tradicionales con API como MCP tienen su lugar. El mejor enfoque puede depender de la naturaleza del proyecto, la experiencia del equipo y los objetivos a largo plazo.

Si solo necesitas integrarte con uno o dos servicios externos y las interacciones son relativamente simples, una integración directa con API suele ser la solución más rápida. Si tu app web solo necesita verificar un token de pago de Stripe en el checkout, llamar directamente a la API de Stripe es simple y eficaz. Introducir MCP en este escenario podría ser excesivo. Puedes conectar un AI Agent a cualquier API REST documentada con una HTTP Action revisada, o usar una integración de un clic como Google Sheets para registrar leads y solicitudes de demo, sin ejecutar un servidor MCP.

En casos en los que necesitas un control muy preciso sobre la solicitud/respuesta (para ajuste de rendimiento, gestión especial de datos o protocolos propietarios), escribir directamente contra la API puede ser mejor. Las integraciones tradicionales te permiten usar todas las funciones avanzadas de una API y ajustar las llamadas con exactitud. Si una API tiene requisitos inusuales o si quieres evitar cualquier capa de abstracción para lograr máxima claridad y control, el enfoque tradicional es adecuado.

Para ver un ejemplo concreto de cómo las herramientas MCP se exponen a un AI Agent de producción junto con acciones de API personalizadas, consulta cómo Quickchat AI Agents combina ambos enfoques. La discusión más profunda sobre cuándo usar MCP, AI Actions individuales o “Generate from Text” está en API para AI Agents: de MCP a endpoints personalizados. Para probarlo tú mismo, sigue la guía paso a paso para conectar tu AI Agent a un servidor MCP remoto, de modo que llame a una herramienta en vivo durante la conversación.

Lista de servidores MCP disponibles

Si quieres empezar con MCP, revisa los directorios de servidores MCP a continuación:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

También puedes ejecutar uno sin escribir código: cada Quickchat AI Agent puede convertirse en un servidor MCP con una URL alojada que Claude, ChatGPT y Cursor llaman como herramienta. La conexión también funciona en la otra dirección: un Quickchat AI Agent puede llamar al servidor MCP alojado de un proveedor como sus herramientas, que es como el asistente de programación de IA creado sobre el servidor MCP de Calendly comprueba disponibilidad real y reserva reuniones desde un chat, y como un chatbot de IA para Notion responde desde un centro de ayuda en vivo y registra solicitudes de soporte de vuelta en una base de datos de Notion.

Quickchat AI también ejecuta un servidor MCP remoto para tu propia cuenta. Conéctalo a ChatGPT, Claude, Cursor o Codex y podrás gestionar tus AI Agents desde allí: analíticas, transcripciones de conversaciones, actualizaciones de la base de conocimiento y creación de nuevos Agents, detrás de un único inicio de sesión con OAuth. La guía de configuración para cada cliente está en Gestiona tu AI Agent desde ChatGPT, Claude y Codex con MCP.

Preguntas frecuentes

¿Solo funciona con Claude?

MCP es agnóstico al modelo. Al protocolo no le importa si el cliente es Claude, GPT-4, un derivado local de LLaMA o cualquier modelo futuro, siempre que el cliente pueda manejar la interfaz MCP. Esto significa que no quedas atado a un único proveedor de IA cuando construyes tus integraciones de herramientas.

¿En qué se diferencia MCP de darle al modelo toda la información que necesita desde el principio? ¿Por qué no llenar el prompt con datos?

MCP es fundamentalmente distinto de llenar el prompt del modelo con datos porque permite que el modelo obtenga información dinámicamente cuando la necesita, en lugar de trabajar con un prompt estático y precargado. Meter texto en el prompt se encuentra con limitaciones, ya que los modelos de IA tienen una ventana de contexto fija, lo que significa que demasiados datos pueden hacer que se pierdan detalles importantes, ralentizar las respuestas y aumentar los costos de API (debido a los modelos de precios por token usados por los proveedores de LLM). También solo proporciona conocimiento en un único momento, mientras que MCP permite acceso en tiempo real a datos externos en vivo y permite que la IA actúe, no solo que lea información. Una IA con un prompt lleno podría conocer los detalles de un cliente, pero no podrá actualizar registros ni procesar transacciones.

¿Qué pasa si conectamos decenas de herramientas a la IA? ¿No saturará eso al modelo o hará que las use mal?

Depende de la implementación, pero es cierto que los LLM actuales tienen límites en cuanto a qué tan bien distinguen y eligen entre muchas opciones. Si presentas a un modelo, digamos, 50 herramientas posibles, existe el riesgo de que elija la incorrecta. El enfoque MCP en sí no te obliga a cargar todo a la vez. Debes conectar herramientas relevantes según el contexto. Una buena práctica es conectar solo las herramientas necesarias para la tarea/dominio en cuestión y aprovechar la colaboración multiagente, una especie de enrutamiento de herramientas o un agente que primero decide qué subconjunto de herramientas considerar.

MCP frente a Function Calling

El function calling tradicional (como se ve en la API de OpenAI u otros LLM) permite que un desarrollador defina un conjunto de funciones, entregue sus definiciones al modelo y haga que el modelo las “llame” por nombre con argumentos. Esto fue un gran paso para la integración de IA, pero tiene limitaciones. Una diferencia importante está en cuándo y cómo se definen las herramientas. En el function calling clásico, todas las funciones posibles deben declararse por adelantado (en tiempo de diseño) en el prompt o mediante la API. El modelo solo puede llamar esas funciones fijas. En MCP, las herramientas se pueden descubrir en tiempo de ejecución, la IA puede consultar qué hay disponible e incluso obtener nuevas herramientas durante la sesión.

MCP frente a GPT Actions y Plugins

GPT Actions/Plugins se refiere al ecosistema de OpenAI donde podías habilitar plugins (como un navegador web o un lector de PDF) para ChatGPT, o los “GPTs” (agentes personalizados de ChatGPT) que pueden usar herramientas. Eran interesantes, pero requerían desarrollo personalizado para cada plugin y estaban limitados a las plataformas de OpenAI. Si querías un plugin de ChatGPT para una tarea, tenías que crear una API y un manifiesto, y pasar por la aprobación de OpenAI o al menos habilitarlo manualmente. Cada plugin era básicamente un silo: un plugin del clima, un plugin de viajes, etc., cada uno con sus propios endpoints y lógica. MCP mejora este concepto al unificarlo y abrirlo.

MCP frente a RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) es una técnica en la que un LLM se complementa con una base de conocimiento externa. Normalmente, RAG implica una base de datos vectorial o un índice de búsqueda: la consulta del usuario se usa para obtener documentos o datos relevantes (mediante búsqueda semántica u otros métodos), y esos documentos se proporcionan al modelo como contexto adicional para “leer” al formar una respuesta. RAG consiste en darle al modelo conocimiento que no tenía originalmente, especialmente útil para preguntas y respuestas factuales o información específica de dominio. Sin embargo, RAG es de solo lectura, el modelo recupera pasajes de texto, pero no realiza acciones más allá de la recuperación.

MCP, en cambio, trata de tomar acciones o realizar operaciones arbitrarias, no solo recuperar contexto informativo. Con MCP, una IA puede hacer cosas: escribir en una base de datos, enviar un correo electrónico, ejecutar código, etc. No se limita a obtener conocimiento; puede activar cambios en sistemas externos. Así que, en muchos sentidos, RAG y MCP tienen propósitos diferentes.