¿Qué es el Model Context Protocol (MCP)? El estándar que conecta IA con herramientas y datos

El Model Context Protocol (MCP) es un estándar abierto que permite a las aplicaciones de IA conectarse a herramientas externas, datos, prompts y otras capacidades mediante una interfaz coherente. En lugar de crear una integración personalizada para cada combinación de modelo y sistema, los desarrolladores pueden implementar un protocolo compartido entre un host de IA y un servidor MCP.

MCP a menudo se describe como un conector universal para IA, pero la analogía es incompleta. El protocolo no solo mueve datos. Define cómo los participantes establecen capacidades, exponen recursos y acciones, intercambian mensajes estructurados y mantienen límites de seguridad. Eso lo convierte en una parte importante de la infraestructura emergente para asistentes y agentes de IA.

Por qué existe MCP

Un modelo por sí solo no puede ver los documentos privados de una empresa, inspeccionar un repositorio local, consultar una base de datos en tiempo real o llamar a un servicio interno. Históricamente, los desarrolladores conectaban esas capacidades mediante plugins puntuales y API específicas de cada aplicación.

Ese enfoque genera un problema de integración. Si diez aplicaciones de IA necesitan conectarse a diez sistemas, los equipos pueden terminar manteniendo docenas de adaptadores a medida. Cada adaptador puede representar herramientas, contexto, autenticación, errores y actualizaciones de manera diferente.

MCP crea un contrato común. Una aplicación compatible con MCP puede comunicarse con servidores MCP que exponen capacidades en un formato conocido. La especificación del Model Context Protocol define el protocolo, mientras que los hosts y servidores individuales deciden qué funciones y políticas de seguridad admiten.

La arquitectura del MCP

MCP separa la conversación y la lógica del modelo de la aplicación de IA de la lógica de integración requerida por cada fuente de datos o servicio. El host puede mantener varias conexiones de cliente simultáneamente—una para un servidor de sistema de archivos, otra para un servidor de bases de datos y otra para una aplicación empresarial—mientras presenta sus capacidades al modelo mediante una interfaz coherente.

El servidor no es necesariamente un servicio remoto de Internet. Puede ejecutarse localmente junto a una aplicación de escritorio, dentro de la red de una empresa o como un servicio remoto. Esa elección de despliegue cambia el transporte y el límite de confianza, pero no la relación central: un cliente descubre capacidades de un servidor e intercambia mensajes estructurados con él.

MCP utiliza una arquitectura host‑cliente‑servidor.

• Host: la aplicación de IA con la que el usuario interactúa, como un asistente, entorno de programación o plataforma de agentes.
• Client: un componente del protocolo creado por el host para mantener una conexión con un servidor MCP particular.
• Server: un programa que expone herramientas, recursos o prompts seleccionados a los clientes MCP.

Un host puede conectarse a varios servidores a la vez. Un servidor podría proporcionar acceso a un repositorio de archivos, otro a un sistema de gestión de proyectos y un tercero a una base de datos interna. El host sigue siendo responsable de la experiencia del usuario, la orquestación del modelo, el consentimiento y la información colocada en el contexto del modelo.

Los mensajes se estructuran siguiendo convenciones JSON‑RPC. Durante la inicialización, los participantes negocian versiones del protocolo y capacidades. Esa negociación es importante porque los clientes y servidores no necesitan implementar cada función opcional.

Herramientas, recursos y prompts

MCP organiza las capacidades proporcionadas por el servidor en varios primitivos. Los tres más familiares son herramientas, recursos e indicaciones.

Herramientas

Una herramienta es una función ejecutable que la aplicación de IA puede invocar. Los ejemplos incluyen buscar en una base de datos de clientes, crear un ticket, ejecutar una consulta o recuperar el inventario actual. Una definición de herramienta incluye un nombre, una descripción y un esquema de entrada para que el modelo y el entorno de ejecución sepan qué argumentos se esperan.

El uso de herramientas puede modificar sistemas externos, por lo que los hosts deben mostrar descripciones significativas, validar entradas, aplicar permisos y requerir confirmación para acciones con consecuencias.

Recursos

Un recurso es un contexto que una aplicación puede leer, como un archivo, un registro de base de datos, una página de documentación o un informe generado. Los recursos utilizan identificadores y pueden exponer metadatos como un nombre y un tipo de medio. Proporcionan a los hosts una forma estandarizada de descubrir y recuperar información sin pretender que cada operación de lectura sea una acción.

Indicaciones

Las indicaciones son plantillas o flujos de trabajo reutilizables que un servidor pone a disposición del host. Pueden ayudar a los usuarios a invocar una capacidad correctamente, proporcionar argumentos estructurados o combinar instrucciones específicas del dominio con el contexto relevante.

MCP también admite capacidades en la dirección opuesta. Según lo negociado, un servidor puede solicitar al host que obtenga completaciones del modelo o la entrada del usuario. El principio de diseño importante es la negociación explícita de capacidades en lugar de asumir que cada participante puede realizar cualquier operación.

¿Qué ocurre durante una llamada a herramienta MCP?

Considere un asistente de codificación de IA conectado a un servidor de análisis de repositorios.

1. El host se conecta al servidor MCP y negocia las capacidades admitidas.
2. El cliente solicita la lista de herramientas disponibles.
3. El servidor devuelve definiciones estructuradas de herramientas, incluidos sus esquemas de entrada.
4. El host pone a disposición del modelo las descripciones de herramientas seleccionadas.
5. El modelo propone una llamada a herramienta, como buscar referencias a una función.
6. El host verifica la política y, cuando es necesario, solicita la aprobación del usuario.
7. El cliente envía la solicitud validada al servidor.
8. El servidor ejecuta la operación y devuelve contenido estructurado o un error.
9. El host decide qué parte del resultado proporcionar al modelo para el siguiente paso.

MCP estandariza el intercambio, pero no decide si se debe confiar en que el modelo llame a una herramienta. Esa decisión corresponde al host y su capa de políticas.

MCP no reemplaza las API

Un servidor MCP suele envolver API existentes, kits de desarrollo de software, herramientas de línea de comandos o controladores de bases de datos. esas interfaces subyacentes siguen realizando el trabajo real. MCP añade una capa de descubrimiento e interacción orientada a IA sobre ellas.

Esta distinción explica por qué MCP es complementario a REST, GraphQL y otras interfaces de aplicación. Un servicio de pagos puede conservar su API madura mientras un servidor MCP expone un subconjunto cuidadosamente limitado de operaciones con descripciones y esquemas amigables para el modelo.

MCP vs. Llamada a funciones

La llamada a funciones o herramientas es una capacidad del modelo: el modelo puede devolver una solicitud estructurada para invocar una función. MCP es un protocolo para descubrir y comunicarse con proveedores de herramientas y contexto.

Los dos suelen trabajar juntos. Un servidor MCP indica al host qué herramientas existen. El host presenta definiciones seleccionadas a un modelo. El modelo emite una llamada a herramienta. El host entonces usa MCP para enviar esa solicitud al servidor correspondiente.

MCP vs. Agent2Agent

MCP conecta una aplicación de IA con capacidades y contexto. Agent2Agent, o A2A, se centra en la comunicación entre agentes autónomos que pueden pertenecer a diferentes sistemas u organizaciones.

Un sistema práctico puede usar ambos. Un agente podría usar MCP para acceder a sus herramientas y datos, y luego usar A2A para delegar una tarea mayor a otro agente. MCP responde “¿Cómo puede esta aplicación usar esa capacidad?” A2A responde “¿Cómo pueden estos agentes coordinar el trabajo?”

Riesgos de seguridad y controles

Un host seguro mantiene una lista de permitidos explícita de servidores y herramientas, muestra un consentimiento significativo cuando se concede el acceso y asocia cada llamada con el usuario o la identidad de la carga de trabajo que la autorizó. Los esquemas de las herramientas deben ser lo suficientemente restrictivos como para rechazar argumentos inesperados, mientras que los registros de auditoría deben registrar el servidor, la capacidad, las entradas, el estado del resultado y la ruta de aprobación.

Los recursos devueltos y los resultados de las herramientas también constituyen una superficie de inyección de indicaciones. Un documento leído a través de MCP puede contener texto que pida al modelo que ignore sus instrucciones o exfiltre datos. El host debe mantener la distinción entre contenido no confiable y la política del sistema, y debe evitar que la salida de un servidor amplíe silenciosamente los permisos de otro servidor.

La estandarización mejora la interoperabilidad, pero no hace que un servidor sea confiable. Un servidor MCP puede exponer datos sensibles, descripciones de herramientas engañosas, acciones inseguras o dependencias comprometidas. El contenido no confiable recuperado a través de un recurso también puede contener instrucciones de inyección de indicaciones destinadas a manipular el modelo.

Los controles importantes incluyen:

• Privilegio mínimo: otorgue a cada servidor solo las credenciales y el alcance necesarios para su propósito.
• Confianza en el servidor: verifique la fuente, el código, la propiedad y la ruta de actualización de los servidores antes de conectarlos.
• Visibilidad del usuario: deje claro qué servidor recibirá los datos y qué acción realizará.
• Validación de entrada: haga cumplir los esquemas y las reglas de negocio fuera del modelo.
• Límites de aprobación: confirme acciones sensibles, externas, financieras o destructivas.
• Minimización de datos: evite enviar documentos o conversaciones completos cuando solo se necesita una pequeña parte.
• Registro y revocación: registre las llamadas, supervise anomalías y haga que las credenciales y conexiones sean fáciles de desactivar.

El proyecto MCP sigue refinando su arquitectura y guía de seguridad. La actualización de la especificación 2026 del proyecto ilustra cómo el estándar está evolucionando hacia una infraestructura más simple, autorización y despliegue en producción.

¿Cuándo deberían los desarrolladores usar MCP?

MCP es una opción sólida cuando varios clientes de IA necesitan una conexión consistente a la misma capacidad, cuando las herramientas deben ser descubribles en tiempo de ejecución, o cuando un equipo desea separar la orquestación de IA del código de integración específico del sistema.

Una llamada directa a función puede seguir siendo más simple para una aplicación pequeña con un backend estrictamente controlado. La adopción del protocolo conlleva su propio trabajo operativo: gestión del ciclo de vida del servidor, pruebas de compatibilidad, autenticación, observabilidad y gobernanza.

Qué recordar sobre el Model Context Protocol (MCP)

MCP es un lenguaje común entre las aplicaciones de IA y las herramientas y el contexto que las rodean. Su valor proviene de reemplazar convenciones de integración aisladas por un protocolo descubrible, estructurado y extensible.

El estándar no elimina la necesidad de una ingeniería cuidadosa. Los hosts aún deben decidir qué servidores confiar, qué capacidades exponer, qué datos compartir y cuándo una persona debe aprobar una acción. MCP hace que las conexiones sean portátiles; la gobernanza las hace seguras y útiles.