Anthropic presenta MCP, un estándar para conectar IA y herramientas

El 25 de noviembre de 2024, Anthropic presentó Model Context Protocol; la capacidad duradera es auditar por separado conexión, permiso, dato recuperado y acción.

Anthropic ha presentado este lunes Model Context Protocol (MCP), un protocolo abierto para conectar asistentes de inteligencia artificial con fuentes de datos y herramientas externas. La iniciativa aborda un problema práctico: cada aplicación de IA suele necesitar integraciones a medida para consultar archivos, bases de datos, repositorios de código o servicios corporativos.

MCP propone una interfaz común para esas conexiones. En lugar de desarrollar una integración distinta para cada modelo y cada servicio, los desarrolladores podrían crear un conector compatible con el protocolo y reutilizarlo en diferentes aplicaciones.

El problema: la IA no trabaja sola

Un modelo de lenguaje puede redactar, resumir o responder preguntas, pero no conoce por sí mismo el contenido de una carpeta de Google Drive, el estado de un proyecto en GitHub ni los datos actualizados de una base de datos. Para usar esa información necesita permisos y una vía técnica para consultarla.

Hasta ahora, esas conexiones suelen construirse de forma específica. Una empresa que quiera dotar a un asistente de acceso a Slack, PostgreSQL y su documentación interna debe unir cada servicio con la aplicación de IA que haya elegido. Si cambia de proveedor o crea otro asistente, parte de ese trabajo puede tener que repetirse.

Anthropic compara este escenario con los primeros tiempos de los dispositivos periféricos: sin un estándar compartido, cada conexión requiere soluciones particulares. MCP pretende ser esa capa común entre una aplicación de IA y los sistemas donde reside la información o se ejecutan acciones.

Cómo funciona el protocolo

La arquitectura de MCP separa tres elementos. El host es la aplicación que utiliza el usuario, como un asistente de escritorio. Dentro de ella, un cliente MCP establece la conexión con un servidor MCP, que expone datos o herramientas concretas.

Por ejemplo, un servidor puede permitir que un asistente consulte un repositorio de GitHub, lea archivos locales, ejecute una consulta en PostgreSQL o automatice tareas en el navegador. El protocolo define cómo se describen y solicitan esas capacidades, sin obligar a que cada aplicación invente su propio formato.

Esto no significa que el modelo reciba acceso ilimitado a los sistemas conectados. Los permisos siguen siendo una cuestión decisiva: una integración bien diseñada debe delimitar qué información puede leer el asistente y qué acciones puede realizar. El estándar facilita la conexión técnica, pero no sustituye las políticas de seguridad ni el control humano.

Claude Desktop estrena soporte y Anthropic publica ejemplos

Anthropic ha incorporado soporte para MCP en Claude Desktop y ha publicado especificaciones, kits de desarrollo para TypeScript y Python, además de varios servidores de referencia. Entre ellos figuran conectores para Google Drive, Slack, GitHub, Git, PostgreSQL, almacenamiento local y automatización web mediante Puppeteer.

La compañía también ha abierto el protocolo para que otros desarrolladores y proveedores lo implementen. Esa decisión es relevante porque un estándar solo resulta útil si no queda limitado a un único producto. Si las aplicaciones de IA, los servicios de datos y los proveedores de herramientas adoptan interfaces incompatibles, MCP sería una integración más; si logra apoyo externo, puede reducir una parte importante del coste de construir asistentes conectados al trabajo real.

Una pieza para asistentes más útiles, pero también más delicados

El anuncio llega cuando la utilidad de los asistentes depende cada vez menos de mantener una conversación y más de acceder al contexto adecuado. Un sistema que conoce los documentos, calendarios, incidencias y repositorios de una organización puede responder con mayor precisión y ejecutar tareas. A cambio, concentra riesgos de privacidad, permisos excesivos y acciones equivocadas.

Para las empresas, el atractivo de MCP está en evitar integraciones repetidas y conservar una arquitectura más intercambiable entre modelos y aplicaciones. Para los desarrolladores, puede simplificar la creación de conectores que sirvan a varios clientes. Y para los usuarios, la promesa es que un asistente deje de pedirles que copien y peguen información entre herramientas.

La prueba real será la adopción fuera de Anthropic y la calidad de las implementaciones. Un protocolo común puede hacer más accesible la IA conectada a datos corporativos, pero su valor dependerá de que esa comodidad no se traduzca en accesos opacos o difíciles de supervisar.

Un estándar de conexión no es un permiso

MCP define mensajes y papeles para que una aplicación descubra recursos, herramientas y plantillas expuestos por un servidor. La especificación inicial también deja claro que el host coordina conexiones y controles. Que dos componentes hablen el mismo protocolo no decide qué archivos puede leer un usuario, qué consulta debe ejecutarse ni qué acción merece confirmación.

Para evaluar una integración conviene dibujar cuatro límites: usuario-host, host-cliente, cliente-servidor y servidor-sistema real. En cada uno se anota identidad, credencial, datos que cruzan, operación permitida y registro disponible. Ese mapa revela si un conector aparentemente simple concentra privilegios o envía contexto a un modelo remoto que el usuario no esperaba.

Recursos y herramientas tampoco tienen el mismo riesgo. Leer un documento puede filtrar información; invocar una herramienta puede modificar estado. Una implementación segura reduce el alcance por defecto, muestra parámetros antes de ejecutar acciones sensibles y registra respuesta, error y usuario. La confirmación genérica “permitir MCP” es demasiado amplia para sustituir permisos por operación.

Cómo probar un conector antes de confiar en él

La prueba mínima usa una cuenta de pocos privilegios, un documento permitido, otro prohibido y una herramienta reversible. Se comprueba que el servidor descubre solo lo necesario, que no resume el recurso restringido y que una acción requiere aprobación. Después se revoca el permiso y se repite: las cachés pueden conservar acceso después de que el sistema de origen lo haya retirado.

También hay que tratar el contenido recuperado como no confiable. Un archivo puede incluir instrucciones dirigidas al modelo para que ignore al usuario o extraiga otros datos. El protocolo transporta contexto; no determina que ese contexto sea seguro. Separar datos de instrucciones, limitar herramientas y validar parámetros sigue siendo responsabilidad de la aplicación.

La interoperabilidad se demuestra con implementaciones independientes, no con la publicación del nombre. Un conector reutilizable reduce trabajo si distintos clientes interpretan igual la especificación, gestionan versiones y comunican errores. El anuncio de Anthropic abrió ese camino, pero la adopción y la compatibilidad debían observarse con el tiempo.

La capacidad transferible es auditar toda conexión de IA como una cadena: quién pide, qué puede leer, qué se envía al modelo, qué puede cambiar y dónde queda registrado. Un protocolo común reduce integración; no reduce automáticamente privilegios ni responsabilidad.

La gestión de versiones es parte del contrato técnico. Un cliente y un servidor pueden implementar revisiones distintas y coincidir en la conexión mientras discrepan en una capacidad concreta. Fijar la versión soportada, probar negociación y fallar de forma cerrada evita que una actualización silenciosa conceda una operación inesperada.

Cuando un servidor procede de terceros, la revisión incluye su código o proveedor, dependencias, mecanismo de actualización y destino de telemetría. Instalarlo equivale a añadir software con acceso a los sistemas que expone. La comodidad de un catálogo no elimina la necesidad de inventario, mínimos privilegios y retirada rápida.

El protocolo puede cambiar de proveedor sin cambiar este método. Se vuelve a ejecutar la misma matriz con otro host o servidor y se comparan permisos, trazas y fallos observados. Esa portabilidad de la evaluación es tan importante como la del conector: evita que la arquitectura abierta se convierta en confianza ciega hacia una implementación concreta.

La comparación debe repetirse tras cada cambio material.