MCP: el estándar que conecta la IA con herramientas y datos
El Model Context Protocol propone un idioma común para que las aplicaciones de IA consulten datos y usen herramientas. Su adopción crece, pero no elimina los permisos ni los riesgos de seguridad.
Una IA puede redactar, resumir o programar dentro de una conversación. Pero, para consultar el calendario de una empresa, buscar en una base de datos o crear una incidencia, necesita salir de esa conversación de una forma controlada. Durante años, cada aplicación resolvió ese paso con conectores propios. El Model Context Protocol, o MCP, intenta que esa conexión deje de ser un trabajo artesanal distinto para cada combinación de modelo, herramienta y fuente de datos.
Un idioma común, no un cerebro nuevo
MCP es un protocolo abierto para integrar aplicaciones basadas en modelos de lenguaje con datos y herramientas externas. La especificación oficial describe tres papeles: el host, que es la aplicación de IA; el client, el componente que gestiona la conexión dentro de ella; y el server, que expone capacidades. Esas capacidades pueden ser recursos —por ejemplo, documentos o datos—, prompts reutilizables o herramientas que ejecutan una función.
La comparación más útil para alguien no técnico es el USB-C. Un puerto USB-C no convierte una cámara en un ordenador ni decide qué archivos puede leer; establece unas reglas para que muchos dispositivos puedan conectarse sin inventar un cable nuevo en cada caso. MCP persigue algo parecido: una aplicación de IA y un servicio externo pueden entenderse mediante un contrato compartido. El servidor anuncia qué ofrece; el cliente negocia qué sabe usar; y los mensajes siguen un formato común basado en JSON-RPC.
La analogía tiene un límite importante. Un conector físico no suele interpretar instrucciones. En MCP, las descripciones de una herramienta, sus datos y sus respuestas pueden entrar en el contexto de un modelo. Por eso el protocolo no equivale a una llave maestra: la aplicación que lo utiliza sigue teniendo que decidir qué servidor acepta, qué identidad se autentica, qué permisos recibe y qué acciones requieren confirmación humana.
De proyecto abierto a infraestructura compartida
Anthropic presentó y liberó MCP el 25 de noviembre de 2024. Su anuncio incluía la especificación y SDK, soporte local en Claude Desktop y un repositorio de servidores para sistemas como Google Drive, Slack, GitHub, Git o Postgres. El problema que planteaba era concreto: si cada nueva fuente de datos exige una integración exclusiva, conectar asistentes a sistemas reales se vuelve difícil de mantener.
Desde entonces, el interés no se ha limitado al entorno original. El 21 de mayo de 2025, OpenAI anunció soporte para servidores MCP remotos en su Responses API, después del soporte en su Agents SDK. La compañía explicó que un desarrollador podía conectar sus modelos a herramientas alojadas en un servidor MCP sin diseñar un formato de integración específico para ese caso.
Google Cloud también incorporó MCP a productos orientados a datos y agentes. En abril de 2025 presentó MCP Toolbox for Databases, un servidor de código abierto para acercar agentes a varias bases de datos. En diciembre anunció servidores MCP remotos y gestionados para servicios de Google y Google Cloud. Estas decisiones no prueban que todos los sistemas de IA vayan a usar MCP, pero sí explican por qué empieza a funcionar como estándar de facto: un proveedor puede publicar una integración una vez y llegar a clientes compatibles de distintos fabricantes.
Ahí está la diferencia práctica. Sin un protocolo compartido, una empresa que ofrece, por ejemplo, acceso a inventario tendría que mantener adaptadores para cada asistente. Con MCP puede exponer herramientas como «consultar existencias» o «crear pedido» con un esquema común. Cada cliente seguirá necesitando su configuración y autorización, pero el lenguaje de la conexión deja de reinventarse desde cero.
Lo que MCP no resuelve
La expansión del estándar no borra la parte más difícil: decidir en quién confiar. La propia especificación advierte que las herramientas pueden abrir rutas de acceso a datos arbitrarios y de ejecución de código. Por eso pide consentimiento explícito del usuario, interfaces claras para revisar operaciones y precaución ante las anotaciones y descripciones que proceden de servidores no confiables.
La guía oficial de buenas prácticas de seguridad documenta riesgos como la inyección de prompts, el secuestro de sesión y las solicitudes a servicios internos (SSRF). Sus mitigaciones incluyen verificar las peticiones entrantes, no usar la sesión como mecanismo de autenticación, emplear identificadores seguros y ligar las sesiones a información del usuario autorizado. Son requisitos de ingeniería y operación, no efectos automáticos de instalar MCP.
También hay una cuestión menos visible: la madurez del despliegue. Google Cloud reconoció al anunciar sus servidores gestionados que localizar, instalar y mantener servidores comunitarios locales podía trasladar carga al desarrollador y producir implementaciones frágiles. La interoperabilidad reduce trabajo repetido; no sustituye la observabilidad, las pruebas, la gestión de secretos ni una política de permisos de mínimo privilegio.
MCP importa porque sitúa una pieza hasta ahora dispersa —la conexión entre una IA y el mundo de herramientas— detrás de un contrato abierto. Su valor no está en prometer agentes sin límites, sino en hacer esa conexión más reutilizable y auditable. La pregunta responsable para cada organización no es solo «¿podemos conectar esta herramienta?», sino «¿qué datos y acciones queremos permitir, a quién y con qué supervisión?».
