Hace poco más de un año, el Model Context Protocol (MCP) era una especificación prometedora que algunos equipos probaban en paralelo a sus integraciones propias. Hoy es la forma por defecto de conectar agentes de IA con datos y herramientas. Los principales proveedores de modelos, IDEs y plataformas de agentes lo soportan, y miles de servidores MCP cubren desde bases de datos hasta herramientas de diseño.
Si en su momento te explicamos qué es MCP, en este artículo vemos qué ha cambiado y por qué importa.
De un proveedor a una fundación
El hito más relevante para las empresas fue la cesión del protocolo a una gobernanza abierta y neutral bajo el paraguas de la Linux Foundation, junto con otras iniciativas del ecosistema de agentes. Para un equipo de arquitectura esto tiene consecuencias muy concretas:
- Menos riesgo de dependencia. Apostar por MCP ya no significa atarse a un proveedor de modelos.
- Evolución predecible. Las versiones de la especificación pasan por un proceso público de propuestas y revisión.
- Ecosistema más amplio. Más fabricantes publican servidores MCP oficiales para sus productos.
Qué ha madurado en la especificación
Las últimas revisiones han resuelto muchas de las carencias que frenaban su uso en producción:
- Autorización robusta. Integración con flujos OAuth estándar para que un servidor MCP sepa quién está pidiendo qué, en lugar de compartir una clave global.
- Tareas de larga duración. Operaciones asíncronas que pueden tardar minutos u horas sin mantener una conexión abierta.
- Transporte HTTP remoto. Servidores MCP desplegados como servicios, no solo como procesos locales.
- Descubrimiento y metadatos. Formas estandarizadas de describir qué ofrece un servidor y registrarlo en catálogos.
La pregunta ya no es si MCP está listo para producción. Es cómo operas decenas de servidores MCP sin perder el control.
El nuevo reto: gobernar los servidores MCP
Cuando conectar una herramienta cuesta minutos, el número de conexiones crece rápido. Y cada servidor MCP es, en la práctica, una puerta a tus sistemas. Esto plantea preguntas que el protocolo por sí solo no responde:
- ¿Qué servidores MCP están aprobados en la organización?
- ¿Qué agentes y qué usuarios pueden usar cada uno?
- ¿Qué herramientas concretas de un servidor están habilitadas y cuáles bloqueadas?
- ¿Quién ha invocado qué herramienta, cuándo y con qué resultado?
Buenas prácticas que recomendamos
- Registro central de servidores con responsable, versión y nivel de riesgo.
- Credenciales gestionadas, nunca embebidas en el agente.
- Habilitar herramientas de forma granular: un servidor puede exponer lectura y escritura; no todos los agentes necesitan ambas.
- Revisar servidores de terceros antes de aprobarlos, igual que harías con cualquier dependencia de software.
- Registrar cada invocación para auditoría y depuración.
MCP en Root
En Root, MCP es la columna vertebral. Todos los CLI registran la misma URL, sin secretos dentro: la primera vez abren el navegador para iniciar sesión por OAuth 2.1 y elegir la empresa en la que trabajarán. Cada herramienta tiene su audiencia —agente u operador—, así que nadie invoca lo que no puede ver, y revocar un agente corta su acceso en la siguiente petición. Tus agentes ganan capacidades sin que se multipliquen las credenciales ni los puntos ciegos.
¿Estás estandarizando tus integraciones con MCP? Cuéntanos tu caso.