Cómo el Protocolo de Contexto del Modelo permite a los agentes de IA descubrir y utilizar herramientas

Pide a un asistente de IA que “cree una página de aterrizaje mínima en Figma para un SaaS de IA llamado FlowAI, con fondo oscuro, un título principal, un botón de llamada a la acción y tres tarjetas con características”, y un asistente bien conectado puede hacerlo: genera el diseño en Figma sin que tengas que abrir la aplicación ni que nadie escriba una integración personalizada para Figma. El primer resultado sirve como punto de partida, y puedes seguir iterando solicitando nuevas pantallas o cambios en la tipografía. El mismo enfoque funciona con muchas otras aplicaciones.

Eso plantea preguntas obvias. ¿Cómo controla un modelo de lenguaje otra aplicación? ¿Es MCP simplemente otra API? ¿Qué ocurre realmente entre la solicitud y el resultado, y por qué este protocolo se ha discutido tanto? Este artículo responde a cada una de ellas, para que puedas entender MCP como ingeniero en lugar de tratarlo como una caja negra.

Qué es MCP

MCP, el Protocolo de Contexto del Modelo, es una forma estándar para que las aplicaciones de IA descubran herramientas externas y las utilicen. En el escenario de Figma, la imagen mental más sencilla es una cadena: la aplicación de IA se comunica con MCP, y MCP se comunica con Figma. Usted describe lo que desea, el modelo interpreta la solicitud, verifica qué herramientas están disponibles a través de MCP y activa aquella que se adapta a la tarea.

Figma es solo un ejemplo. A través del mismo protocolo, una aplicación de IA puede acceder a una base de datos, Slack, GitHub y prácticamente cualquier otro sistema que ofrezca un servidor MCP.

En este contexto, una “herramienta” simplemente se refiere a una función que un servicio expone para que el modelo la invoque, como “crear un marco”, “buscar mensajes” o “ejecutar una consulta”. MCP les da a esas funciones una estructura común, de modo que cualquier aplicación de IA compatible puede encontrarlas y utilizarlas.

El problema de integración que resuelve MCP

Sin un protocolo compartido, cada combinación de aplicación de IA y herramienta necesita su propio código personalizado. Conectar un asistente a Figma es una integración; conectar un segundo asistente a Figma es otra. Agregar Slack implica otra integración, y una base de datos, aún otra más. La cantidad de integraciones crece con cada aplicación multiplicada por cada herramienta, y mantenerlas rápidamente se vuelve inviable.

Con MCP, cada proveedor de herramientas expone sus funciones una sola vez a través del protocolo, y cada aplicación de IA implementa dicho protocolo también una sola vez. Cualquier aplicación compatible puede entonces utilizar cualquier herramienta compatible. Una forma útil de recordarlo: MCP funciona como un adaptador universal entre los modelos de IA y las herramientas que necesitan.

¿Es MCP un reemplazo para las APIs?

No. Las APIs no van a desaparecer. Figma, Stripe y Slack siguen teniendo sus APIs, y su base de datos PostgreSQL sigue existiendo detrás de todo lo que se construya sobre ella. En la práctica, muchos servidores MCP son capas ligeras sobre APIs existentes.

Lo que cambia es la forma en que esas capacidades se presentan y se consumen por una aplicación de IA. En una integración tradicional, un desarrollador lee la documentación de la API, elige el endpoint adecuado, escribe el código del cliente, se ocupa de la autenticación, envía solicitudes y analiza las respuestas. Todas esas decisiones se toman de antemano y quedan fijadas en el código.

Con MCP, la aplicación de IA puede preguntarle al servidor en tiempo de ejecución qué herramientas ofrece. Un servidor para una tienda en línea podría responder con herramientas como:

• buscar productos
• obtener un pedido
• crear un reembolso

Cada herramienta cuenta con un nombre, una descripción de su propósito y un esquema de entrada estructurado que el modelo puede leer. Según la solicitud del usuario, el modelo elige la herramienta adecuada y proporciona argumentos que coinciden con dicho esquema. La decisión sobre qué operación realizar pasa de un código escrito por adelantado al razonamiento del modelo en el momento de la solicitud.

Los tres componentes básicos: anfitrión, cliente y servidor

MCP está organizado en torno a tres roles.

El anfitrión

El anfitrión es la aplicación de IA con la que el usuario interactúa realmente: un asistente de chat, una herramienta de programación con IA o cualquier aplicación que tenga un modelo de lenguaje como núcleo. Él controla la conversación y el modelo, y decide qué servidores puede utilizar el modelo.

El cliente MCP

El cliente es el componente dentro del anfitrión que gestiona la comunicación con un servidor MCP. En el diseño del protocolo, un anfitrión suele ejecutar un cliente por cada conexión al servidor; por lo tanto, un asistente conectado a Figma y GitHub mantiene dos sesiones de cliente separadas.

El servidor MCP

El servidor expone herramientas a la aplicación de IA y las conecta con sistemas reales. Cuando se llama a una herramienta, es el servidor quien realmente se comunica con la API de Figma, ejecuta la consulta a la base de datos o envía el mensaje a Slack.

Qué ocurre durante la llamada a una herramienta

Al combinar estos tres roles, el flujo se vuelve claro: el cliente permite que el anfitrión descubra las herramientas que ofrece un servidor y las llame con parámetros debidamente estructurados cuando el modelo decide que son necesarias.

Esto no es una solicitud sencilla que se envía y se olvida. Se trata de una conversación entre el cliente y el servidor. Primero establecen una sesión y acuerdan las capacidades, luego el cliente solicita la lista de herramientas y, posteriormente, envía llamadas a dichas herramientas y recibe sus resultados. En el fondo, estos mensajes utilizan JSON-RPC, transmitido ya sea a través de la entrada y salida estándar para servidores locales o por HTTP para los remotos.

El modelo de lenguaje es lo que diferencia esto de una integración convencional. No existen secuencias de llamadas predefinidas; el modelo lee las descripciones de las herramientas, determina cuáles sirven al objetivo del usuario y las solicita en el orden que requiera la conversación.

Explorando un asistente de comercio electrónico

Imaginemos un asistente de soporte para una tienda en línea cuyo servidor MCP expone tres herramientas:

• get_order

search_products

create_refund

Un cliente escribe: “¿Dónde está mi pedido?”. El modelo reconoce la intención, observa que existe una herramienta get_order disponible y decide utilizarla con el ID del pedido del cliente. La solicitud se envía desde el cliente al servidor, el cual consulta la base de datos de pedidos o la API interna de pedidos y devuelve datos estructurados sobre el pedido. Luego, el modelo convierte esos datos en una respuesta natural, por ejemplo: “Su pedido fue enviado ayer y debería llegar el jueves.”

El cliente vuelve a contactar y dice: “En realidad, reembóselo”. Dado que el modelo aún conserva el contexto de la conversación, sabe a qué pedido se refiere “eso”. Observa que create_refund está disponible y lo llama con los mismos detalles del pedido. Si el servidor también expone una herramienta como notify_finance, el modelo podría incluir también ese paso en el flujo de trabajo.

Esta división del trabajo es la idea central de MCP. El modelo decide qué herramienta utilizar y con qué argumentos. El servidor lleva a cabo la operación real. En un sistema de producción se añadiría otro elemento a este flujo: como el reembolso es una acción irreversible con consecuencias, muchos equipos exigen una confirmación explícita del usuario o verificaciones de políticas en el servidor antes de ejecutarlo, en lugar de confiar únicamente en el juicio del modelo.

Qué te ofrece MCP

Se destacan tres beneficios principales.

1. Estandarización: las aplicaciones de IA interactúan con herramientas externas de una manera consistente, en lugar de seguir un patrón diferente para cada integración.
2. Flexibilidad: el modelo descubre las herramientas disponibles y lee sus esquemas directamente, por lo que ya no es necesario describir cada función a mano dentro de un extenso prompt del sistema.
3. Reutilización: un servidor MCP se crea una sola vez y puede luego servir a muchas aplicaciones de IA compatibles.

Qué no hace MCP

Es útil ser preciso respecto a sus limitaciones, ya que el entusiasmo por el protocolo puede hacerlas menos claras.

• MCP no es magia, y no hace que una API subyacente sea más capaz de lo que ya es.

No hace que un sistema de IA sea fiable. El modelo aún puede elegir la herramienta incorrecta o pasar argumentos erróneos, por lo que la validación y un manejo adecuado de errores en el servidor siguen siendo esenciales.

Tampoco elimina las preocupaciones relacionadas con la autenticación o la seguridad. Los servidores siguen necesitando credenciales, control de acceso y auditoría, y las salidas de las herramientas pueden contener contenido no fiable que intenta influir en el modelo.

No implica que todo sistema interno deba estar expuesto a un agente de IA. Se debe otorgar solo el conjunto mínimo de herramientas y permisos que realmente necesite un caso de uso específico.

Que la IA llame a una API no es algo nuevo; los desarrolladores han conectado modelos a APIs durante años. Lo que añade MCP es una interfaz estandarizada a través de la cual un modelo puede descubrir y utilizar muchas herramientas diferentes sin necesidad de una integración personalizada para cada una.

Puntos clave

• MCP es un protocolo para conectar aplicaciones de IA con herramientas. Se basa en las APIs en lugar de reemplazarlas.
• Los servidores exponen herramientas junto con descripciones y esquemas de entrada; el host y sus clientes se encargan del descubrimiento y la comunicación.
• El modelo elige qué herramienta llamar y con qué argumentos; el servidor realiza la operación real.
• La estandarización convierte una red cada vez mayor de integraciones puntuales en componentes que se crean una sola vez y se reutilizan.
• La fiabilidad, la autenticación, el principio de mínimo privilegio y la confirmación de acciones riesgosas siguen siendo su responsabilidad.

Si estás comenzando, empieza conectando servidores MCP existentes, como los de GitHub, Slack o Figma, a un asistente que ya utilices y observa cómo el modelo selecciona las herramientas. Una vez que quede claro su valor, crear tu propio servidor para una base de datos o servicio interno es el siguiente paso lógico. Para conocer cómo MCP se integra en marcos de agentes más amplios, consulta nuestro artículo sobre estandarizar la integración de herramientas en LangGraph con MCP.