Qué es MCP (Model Context Protocol) y cuándo conviene usarlo para conectar un agente de IA

Qué es MCP (Model Context Protocol)

MCP, siglas de Model Context Protocol, es un protocolo abierto que define cómo una aplicación basada en un modelo de lenguaje se conecta con fuentes de datos y herramientas externas. Cada sistema se ofrece una vez como servidor MCP y las aplicaciones compatibles pueden conectarse a él. Los mensajes viajan en formato JSON-RPC 2.0.

El protocolo fija cómo se hablan las piezas. Qué datos se exponen, qué acciones se permiten y quién las autoriza depende de cómo se monte cada una, y ahí está casi todo el trabajo.

Aplicación anfitriona, clientes y servidores

La especificación de MCP distingue tres papeles. La aplicación anfitriona (host) es donde trabaja el modelo: un asistente de escritorio, un entorno de programación o el agente que se desarrolle para tu empresa. Dentro de ella, cada cliente mantiene la conexión con un único servidor, de modo que un agente que usa tres servidores tiene tres clientes. El servidor es el programa que da acceso a algo: una base de datos, un gestor documental o la API de un proveedor.

Un servidor puede ejecutarse como proceso local en el mismo equipo o funcionar como servicio remoto. La diferencia pesa en la seguridad. El local corre con los mismos privilegios que la aplicación que lo lanza; en el remoto hay que decidir cómo se autentica quien lo llama. La anfitriona coordina el conjunto y, según los principios de diseño del protocolo, cada servidor recibe solo el contexto que necesita, sin acceso a la conversación completa ni a lo que hacen los demás servidores.

Qué expone un servidor: herramientas, recursos y prompts

Un servidor puede ofrecer tres tipos de elementos, y la especificación asigna a cada uno quién lo controla.

• Herramientas (tools): funciones que el modelo puede decidir llamar, como consultar una base de datos, enviar una petición a una API o escribir un archivo. Las controla el modelo, y por eso son la parte que más cuidado pide.
• Recursos (resources): datos de contexto, como el contenido de un archivo o el historial de un repositorio, que la aplicación anfitriona adjunta y gestiona.
• Prompts: plantillas de instrucciones que elige el usuario, por ejemplo desde un menú o con un comando.

En sentido contrario, el servidor puede pedir a la aplicación que pregunte algo al usuario cuando le falta un dato. Cada herramienta se publica con un nombre, una descripción y un esquema de los parámetros que admite. Con esa descripción el modelo decide cuándo usarla, así que redactarla bien también es parte del encargo.

Cuándo basta una llamada directa a una API

Si el agente solo tiene que hacer una cosa con un sistema, como consultar el estado de un pedido, y es el único que lo va a usar, propongo que su propio código llame a la API. Hay menos piezas que desplegar y vigilar. Un servidor MCP en ese caso añade un proceso más y otra dependencia que actualizar.

MCP empieza a compensar en otras situaciones:

• Las mismas herramientas tienen que servir a varias aplicaciones, por ejemplo al asistente que usa tu equipo y a un agente que trabaja sin supervisión directa.
• El proveedor de un sistema que ya utilizas ofrece y mantiene su propio servidor MCP.
• Prevés cambiar de aplicación anfitriona y prefieres no reescribir las integraciones al hacerlo.

Que exista un servidor del proveedor tampoco obliga a usarlo. Si expone muchas más acciones de las que necesita la tarea, a veces prefiero un servidor propio y pequeño, con dos o tres herramientas, delante de esa misma API. Si la API es de un tercero, reviso antes sus condiciones de uso, igual que con cualquier fuente de datos que se va a integrar. Y si la duda es si hace falta un agente o basta una regla, lo explico en qué reviso antes de poner un agente de IA a trabajar en una empresa.

Los riesgos que reviso antes de conectar un servidor

La especificación lo dice sin rodeos: las herramientas suponen ejecución de código arbitrario y hay que tratarlas con cautela. Entre sus principios pide que la aplicación anfitriona obtenga el consentimiento explícito del usuario antes de invocar cualquier herramienta, y considera que las descripciones de su comportamiento no son fiables salvo que procedan de un servidor de confianza. De ahí salen mis comprobaciones.

• Procedencia. Si el servidor es de un tercero, miro quién lo publica y qué ejecuta al instalarse. Cuando es local, prefiero lanzarlo aislado, con acceso limitado a archivos y red.
• Credenciales. Cada servidor usa una cuenta propia con los permisos mínimos; si una herramienta solo lee, no recibe permiso de escritura. Un servidor tampoco debe aceptar tokens que no se hayan emitido para él ni reenviarlos tal cual a otro servicio.
• Lo que vuelve al modelo. Un correo, una página o un documento devueltos por una herramienta pueden traer instrucciones escritas para desviar al agente. Marco ese contenido como externo, y después de leerlo el agente no puede ejecutar acciones de escritura sin confirmación.
• Acciones con consecuencias. Enviar, modificar, pagar o borrar pasan por una persona; la especificación recomienda que siempre haya alguien capaz de denegar una llamada.
• Registro. Qué herramienta se llamó, con qué parámetros y qué devolvió, para poder explicar después lo ocurrido.

La guía de buenas prácticas de seguridad de MCP describe estos ataques con más detalle. Seguirla reduce los riesgos conocidos, aunque ninguna lista cubre los que todavía no se han descrito.

Cómo lo pruebo

Con quien hoy hace la tarea preparo una lista de peticiones y anoto, para cada una, qué herramienta debería llamarse y con qué parámetros. Incluyo peticiones que no deberían provocar ninguna llamada, otras en las que dos herramientas parecen servir y documentos con instrucciones escondidas. Cuando el modelo elige mal, el problema suele estar en una descripción ambigua o en herramientas demasiado parecidas.

El servidor también lo pruebo sin el modelo: entradas que no cumplen el esquema, una API caída, respuestas lentas, un permiso retirado. Cada fallo debe volver con un mensaje que explique qué ha ocurrido. La especificación se publica por versiones con fecha y entre ellas cambian cosas de fondo: en la 2026-07-28 cada petición es independiente, mientras que hasta la 2025-11-25 la conexión empezaba con una negociación inicial y podía mantener una sesión. Por eso anoto con qué versión se ha probado y repito las pruebas cuando cambia el protocolo, el modelo o la API que hay detrás.

Qué entrego y qué queda fuera

Según lo que concluya la revisión, la entrega puede ser un servidor MCP propio con sus herramientas, la configuración de servidores de terceros dentro de un agente o la integración directa con la API. Siempre incluye la lista de herramientas con sus permisos, las credenciales que necesita cada una y quién las custodia, las pruebas con sus resultados y la documentación para instalar, actualizar y revocar accesos. Trabajo en remoto, con los accesos que tu empresa me facilite.

Salvo que lo acordemos, quedan fuera los fallos de las APIs de terceros, la disponibilidad de servidores que no he desarrollado y el coste de los modelos o servicios externos. Si el agente maneja datos personales, qué puede enviarse a cada proveedor lo decide tu empresa con quien lleve la protección de datos; esta nota no es asesoramiento jurídico.

Una primera fase puede limitarse a inventariar los sistemas que necesitaría el agente, decidir para cada uno entre un servidor MCP y una llamada directa, fijar los permisos y montar una prueba con un solo servidor y material autorizado. Con ese resultado decides si seguir. En la página de desarrollo de software a medida, automatización e IA aplicada explico cómo planteo el resto del trabajo.