Empecé a usar MCP con GitHub Copilot a principios de 2025, antes de que la mayoría de las organizaciones conocieran el protocolo. En mayo de ese año ya presentaba sobre ello en Global Azure Madrid, y unas semanas después en AWS Community Day Colombia. En ambas charlas expliqué la arquitectura, demostré composiciones de servidores y advertí a la audiencia de que la gestión de credenciales era un problema no resuelto en el ecosistema. Ese septiembre escribí una entrada de blog centrada en aspectos no funcionales sobre ello .

Eso fue hace más de un año. He estado construyendo con MCP de forma continua desde entonces, y ahora gestiono múltiples servidores personalizados que impulsan flujos de trabajo desde la entrega de consultoría, evaluación de contenidos, gestión de cumplimiento y revisión de arquitectura. Esto es lo que aprendí, lo que fracasó y lo que la empresa está viviendo ahora mismo.

En qué se convierten realmente los servidores MCP

La conversación sobre MCP lo trata como una forma de conectar agentes de IA a APIs. Después de un uso diario sostenido, puedo decir que el encuadre lo subestima. Los interesantes servidores MCP llevan una lógica de dominio que no tendría sentido como endpoint REST.

Esto importa porque hubo un debate real sobre si MCP es realmente necesario. A principios de 2026, los desarrolladores argumentaron en X que dar acceso directo a los agentes a la shell mediante CLI era más sencillo, barato y fiable que el enfoque MCP estructurado. El CTO de Perplexity se alejó públicamente de MCP internamente. Los benchmarks mostraban que CLI era entre 10 y 32 veces más barata para algunas tareas. La narrativa se convirtió en «MCP está muriendo.»

Luego , Scale AI realizó una comparación controlada en julio de 2026: cincuenta tareas de largo horizonte, las mismas herramientas de backend expuestas a través de ambas interfaces. Su hallazgo fue que la brecha de interfaz se reduce drásticamente con los modelos frontera. Opus 4.8 y GPT-5.5 tuvieron un rendimiento similar en configuraciones MCP, CLI e híbridas, y donde apareció una brecha, funcionó en ambas direcciones, con CLI por delante en la recuperación masiva de datos y MCP por delante en lecturas y escrituras dirigidas. El argumento de rendimiento para declarar MCP obsoleto es más débil de lo que sugerían los primeros benchmarks.

Lo que ningún benchmark mide es la gobernanza, y eso es lo que cambia cuando los servidores MCP dejan de ser envoltorios de API y empiezan a llevar lógica de dominio. Un comando CLI se ejecuta y devuelve. Un servidor MCP puede mantener el estado entre llamadas, hacer cumplir reglas que el agente no puede sobrescribir, componer con otros servidores en flujos de trabajo de varios pasos y ser inventariado y gobernado a través de un registro. Ningún registro empresarial puede responder «qué comandos CLI puede ejecutar este agente» como el Registro MCP de Kiro puede responder «qué servidores puede usar este desarrollador.» La arquitectura de gobernanza que necesitan las empresas depende de la superficie estructurada que proporcione MCP.

Durante este periodo construí varios servidores personalizados. Uno analiza una DSL personalizada que describe una imagen prevista, luego enruta entre la generación determinista de código y la generación de imágenes con IA, a veces componiendo ambas en una sola salida. La misma entrada produce siempre la misma imagen de marca: un sistema de identidad visual con interfaz MCP. Un escáner de señales supervisa las discusiones públicas para conversaciones con profesionales, ejecuta puntuación por niveles para detectar publicaciones que obtienen tracción inusual y resume lo que importa. Un gestor de cumplimiento integra una API de formularios en un ciclo de vida completo de evaluación. Una capa de integración de Workspace vincula documentos, hojas de cálculo, almacenamiento de archivos y paneles en un solo servidor.

Cada uno de estos servidores empezó de forma más sencilla. La lógica de dominio creció porque el uso diario seguía revelando lo que el agente no podía llevar en su ventana de contexto.

El valor está en cómo se combinan los servidores

Un servidor individual es útil. Una composición de servidores es donde el trabajo cambia cualitativamente.

Un flujo de trabajo de revisión de arquitectura lee un entregable de consultoría de una hoja de cálculo compartida, descarga y analiza el diagrama de arquitectura, valida que los servicios propuestos están disponibles en la región objetivo del cliente, califica el diseño según los principios de Well-Architected con severas penalizaciones por falta de detalles, cruza el resumen ejecutivo con los datos fuente para garantizar la consistencia, luego escribe los resultados estructurados en la hoja de cálculo y notifica al consultor responsable. Seis servidores trabajando juntos: acceso a documentos, verificación de documentación, comprobaciones regionales de disponibilidad, modelado de amenazas, seguimiento de resultados y notificación al equipo.

Un flujo de trabajo de preparación previa a la venta lee una tarea de compromiso del sistema de gestión de proyectos, descarga y convierte documentos anexos del cliente, investiga la presencia pública del cliente, mapea su situación con el portafolio de soluciones de la empresa, comprueba la disponibilidad y los precios del servicio en la región del cliente, y produce un brief estructurado con mapeo de soluciones, puntos de diálogo por rol y contenido de diapositivas de presentación en el idioma del cliente. Siete servidores de nuevo, composición completamente diferente.

En ambos casos, el resultado es un punto de partida que acelera el trabajo del experto. Es una entrada para el juicio humano, nunca un reemplazo para el mismo. La revisión de arquitectura produce una evaluación puntuada que el consultor adapta en función de su conocimiento del cliente, las limitaciones que discutió en la sala y los sacrificios que solo el juicio humano puede sopesar. El brief previo a la venta ofrece al equipo una base estructurada que amplían con lo que saben sobre la relación, la política y la verdadera urgencia detrás de la petición. La revisión humana es donde se acumula el valor. La automatización lleva al experto a esa revisión más rápido y con entradas mejor organizadas que las que habrían ensamblado manualmente.

Esa es la idea que la mayoría de los comentarios de MCP pasan por alto: el protocolo es el transporte, el valor es la lógica de dominio dentro de los servidores, y la verdadera palanca proviene de cómo combinaciones específicas producen flujos de trabajo distintos donde cada salida alimenta una decisión humana.

Lo que se rompió

Los límites de credenciales obligan a la duplicación de agentes. Dos de mis configuraciones de agentes cargan instrucciones idénticas y existen únicamente porque una se autentica como cuenta de servicio para contenido de equipo y la otra como cuenta personal para contenido privado. Dispersión de agentes, debido a la segregación de alcance.

Las abstracciones de nomenclatura de servidores tienen filtraciones.. El mismo nombre de servidor en un archivo de configuración puede resolver en código completamente diferente dependiendo de qué agente lo cargue. Tengo dos instancias en las que un nombre de servidor ejecuta rutas de autenticación diferentes en diferentes almacenes de datos. La configuración te dice cómo se llama el servidor. No te dice nada sobre lo que realmente se está ejecutando.

Los servidores de gobernanza no pueden optimizarse para eliminarlos. Diseñé un agente ligero con tres servidores para la velocidad de arranque. En pocas semanas tuve que volver a añadir el servidor de control de calidad, porque sin él el agente producía una salida que violaba las reglas que no podía autodetectar. La lección es estructural: los servidores que aplican reglas de gobernanza no pueden ser eliminados por rendimiento sin perder la aplicación.

Las interacciones de IAM entre servicios generan errores que no puedes corregir desde donde estás. Activar una función en un servidor de base de conocimiento falló con un error de permiso que nombraba un principal que no controlo, el rol de ejecución de la base de conocimiento en lugar del el usuario que realiza la llamada. La política de IAM que puedo escribir es irrelevante para el error. Horas de diagnóstico para un vacío entre dos modelos de autorización en servicios diferentes.

Escribí el estándar de gobernanza y no puedo hacerlo cumplir de forma íntegra . El estándar interno dice: no hay credenciales en repositorios controlados de versiones, personales en lugar de compartidas, rotadas al menos dos veces al año, no hay exposición pública sin una revisión de seguridad. Incluso para hacer cumplir eso requería construir un escáner de postura personalizada para estaciones de trabajo, porque las plataformas de herramientas de IA no ofrecen ninguna visibilidad sobre qué servidores están en funcionamiento, qué credenciales poseen o qué datos fluyen por ellos. La persona que redactó el estándar tuvo que construir la herramienta de cumplimiento a mano.

Lo que la empresa está viviendo ahora mismo

Un servidor que transporta lógica de dominio, credenciales y acceso a sistemas empresariales es infraestructura, y la infraestructura necesita un propietario, una identidad y un ciclo de vida. Ahí es donde empieza el problema del despliegue.

Muchas organizaciones con las que trabajo adoptaron servidores MCP durante el último año y no pueden responder tres preguntas básicas: cuántos servidores funcionan en sus estaciones de trabajo de los desarrolladores, qué credenciales tienen esos servidores y qué datos fluyen a través de ellos.

En el trabajo con clientes, es común ver equipos pasar directamente de stdio local a registros o gateways alojados, mientras que los controles entre esos dos extremos permanecen en gran medida indefinidos.

El stdio local es el predeterminado. Los servidores MCP que funcionan localmente suelen heredar el alcance completo de credenciales de la sesión del desarrollador, a menos que la organización añada aislamiento y controles de identidad. Las principales herramientas de codificación de IA documentan esto explícitamente, ya que los servidores stdio ejecutan comandos arbitrarios con los mismos privilegios que el propio agente. Funcional para un solo constructor. Ingobernable para doscientos desarrolladores.

Los contenedores Docker mejoran el aislamiento con privilegios restringidos, controles de red y registro de eventos incorporado, aunque los contenedores comparten el núcleo del host, lo cual es importante para procesos que generan y ejecutan código dinámicamente.

Los registros MCP alojados concentran el riesgo en la capa de plataforma. En junio de 2025, una vulnerabilidad en el recorrido de rutas en Smithery, un registro compartido de servidores MCP, pudo exfiltrar un token de autenticación a nivel de plataforma que otorgaba control sobre todos los servidores alojados por la plataforma, más de tres mil de ellos. Por separado, un servidor MCP no oficial de Postmark con 1.500 descargas semanales de npm fue modificado en septiembre de 2025 para copiar silenciosamente cada mensaje saliente a una dirección controlada por el atacante durante más de una semana. El análisis de octubre de 2025 de Astrix de 5.205 implementaciones de servidores MCP de código abierto encontró que solo el 8,5% documentaba OAuth, mientras que el 53% dependía de claves API estáticas o tokens de acceso personal.

Los gateways de IA que se incorporaban a las funciones MCP creaban una superficie de ataque diferente. LiteLLM y Bifrost son gateways de enrutamiento LLM que añadieron endpoints utilitarios MCP heredando semántica de ejecución de procesos. Las rutas de prueba MCP de LiteLLM aceptaban parámetros de comandos y generaban procesos en el host de gateway; encadenados con un bypass del framework, esto se convertía en ejecución remota de código no autenticado en un servicio que contenía todas las claves API de modelo (CVE-2026-42271, catálogo CISA Known Exploited Vulnerabilities, junio de 2026). El registro de cliente MCP de Bifrost permitía la ejecución de comandos no autenticados con una sola solicitud HTTP contra un enrutamiento de gateway a más de veinte proveedores LLM (CVE-2026-90898, divulgado en septiembre de 2026). Estos son gateways LLM con MCP añadido, y el fallo común es colocar la ejecución del proceso junto a un punto de concentración de credenciales.

Los registros nativos de plataforma gobiernan lo que está permitido, pero no lo que ocurrió en tiempo de ejecución. El Registro MCP de Kiro permite a los administradores crear una lista de servidores aprobados y la hace cumplir dentro del cliente: los desarrolladores solo pueden usar los servidores de la lista, y los servidores no listados están ocultos y terminados. Se sincroniza cada 24 horas, fija la versión de los servidores y soporta servidores tanto remotos como locales. Está construido sobre el estándar abierto MCP Registry y requiere IAM Identity Center. La limitación honesta: la aplicación es del lado del cliente y puede ser eludida por un usuario con acceso administrativo local. El Registro de Agentes de AWS, disponible en general desde agosto de 2026, proporciona un catálogo centralizado con flujos de trabajo de aprobación y descubrimiento a nivel organizacional. En el lado de Microsoft, Azure API Center es un registro privado de MCP para revisión antes de su uso, Foundry Agent Service gobierna las conexiones agente-MCP, y el nivel API Management AI Gateway añade observabilidad y autenticación a nivel de proxy. Estos controles responden a lo que puede ser aprobado, y varios exponen telemetría para los servidores que afrontan. Ninguno responde aún a la pregunta a nivel empresarial: qué servidores están funcionando en cada estación de trabajo ahora mismo y qué hacía cada uno.

Los runtimes gestionados se acercan más a estar gobernados, aunque a costa de reconstruir el servidor. AWS Bedrock AgentCore ejecuta cada sesión en una microVM dedicada con IAM gestionado por plataforma. Microsoft Foundry Agent Service y Azure Container Apps alojan servidores MCP como contenedores gestionados con integración de identidad. Los Workers de Cloudflare los despliegan en el edge con flujos OAuth. Estas opciones otorgan a un servidor una identidad y aislamiento de sesión más fuertes que una estación de trabajo de desarrollador, con capacidades de telemetría y auditoría que varían según la plataforma y configuración. Pero un servidor personalizado con análisis de contexto del sistema de archivos, integración de IA multiproveedor y lógica de puntuación específica de dominio no cae en un entorno gestionado sin rearquitectura. La lógica de dominio que hace valioso a un servidor MCP es lo que hace que el traslado a un entorno gobernado sea costoso.

Veo que hay un punto intermedio práctico en la entrega al cliente. Cuando construimos soluciones agenticas en plataformas gestionadas como AgentCore, las herramientas se ajustan desde el principio a los objetivos específicos del agente y a los límites de acceso. Una herramienta gestionada que puede leer los datos de costes de un cliente y generar recomendaciones de optimización no necesita acceso a todo su espacio de trabajo ni la capacidad de escribir en sistemas de producción. El alcance más limitado es lo que hace que la herramienta sea gobernable por diseño. Construir herramientas gestionadas para un agente específico es arquitectónicamente diferente a portar un servidor MCP local a un entorno de ejecución. La migración a entornos alojados suele revelar que el servidor local estaba realizando tres trabajos que deberían haber sido tres herramientas separadas con tres conjuntos de permisos distintos.

Lo que recomendaría

Si estuviera asesorando a un CTO que adopta MCP hoy, empezaría con tres cosas.

Haz el inventario antes de construir el segundo servidor. Antes de que el segundo desarrollador añada un servidor MCP, conoce qué instaló el primero. Un registro, ya sea Kiro’s, AWS Agent Registry, Azure API Center o una hoja de cálculo con nombre del servidor, propietario, alcance de credenciales y clasificación de datos, es el control de gobernanza más barato y el que la mayoría de organizaciones evita.

Clasifica los servidores según lo que tocan. Un servidor que lee documentación pública es fundamentalmente diferente de uno que escribe en una hoja de cálculo de cliente o accede a credenciales de producción. La clasificación determina si el stdio local es aceptable, si se necesita aislamiento de contenedores o si el servidor pertenece a un entorno de ejecución gestionado. No todo necesita pasar a AgentCore. Algunas cosas deben hacerlo.

Prueba la migración a un entorno de ejecución gestionado con un servidor antes de necesitarlo. El coste de reconstrucción es real, y descubrirlo antes de un plazo de cumplimiento no es el momento adecuado. Elige el servidor con mayor exposición a credenciales, portarlo a un entorno de ejecución gestionado y mide qué falla. Esa medición es tu aportación de planificación para todo lo demás.

El propio protocolo va en la misma dirección. La hoja de ruta MCP publicada en agosto de 2026 nombra cinco áreas prioritarias, y tres de ellas abordan directamente la brecha de gobernanza que describe esta publicación. La más relevante para las empresas es la unificación del transporte: extender Streamable HTTP para cubrir los servidores locales que actualmente funcionan sobre stdio. Esto las sitúa bajo los mismos controles que las organizaciones ya aplican a los servicios remotos: autenticación, registro, observabilidad a nivel de proxy y aplicación de gateway. Eso supone un cambio estructural en cómo se pueden gobernar los servidores locales. La hoja de ruta también prioriza la identidad de los agentes a través de la Federación de Identidad de Carga de Trabajo y DPoP, para que los agentes se autenticen con sus propias credenciales en lugar de heredar lo que tenga la sesión del desarrollador. La Autorización Gestionada por la Empresa se convirtió en una extensión estable en junio de 2026. La hoja de ruta convierte estas preocupaciones en trabajo de ingeniería actual, con los Grupos de Trabajo, SEPs y cambios en SDK ya en marcha. Las inversiones que realiza un CTO ahora en inventario, clasificación y pruebas en tiempo de ejecución gestionado coinciden con el avance del protocolo.

Dónde nos deja esto

Advertí a las audiencias sobre la gestión de credenciales en mayo de 2025. Más de un año después, el protocolo forma parte de mi trabajo diario, los sistemas de dominio que construí sobre él son algunas de las herramientas más productivas que poseo, y el problema de credenciales ahora está documentado, activamente explotado en infraestructuras adyacentes y sigue estructuralmente sin resolverse en la capa de despliegue.

MCP me proporciona una interfaz sólida para componer sistemas de dominio, pero el protocolo aún no proporciona los controles de despliegue que requiere el uso empresarial. La hoja de ruta muestra que los mantenedores del protocolo lo saben: la unificación de transporte, la identidad del agente y la autorización gestionada por la empresa son trabajo de ingeniería activo, y cada uno cierra una parte de la brecha de gobernanza con la que he estado viviendo. Lo que puedes construir dentro de MCP, cuando tratas los servidores como sistemas de dominio y los compones en flujos de trabajo que aceleran a los expertos humanos, es realmente potente. La arquitectura de despliegue está poniéndose a la altura y la dirección es la adecuada.

Lo que puede hacer un CTO hoy es sencillo: inventariar lo que está en ejecución, clasificarlo según lo que toque y probar la ruta de migración para los servidores que conllevan más riesgos. El protocolo avanza hacia un despliegue gobernado. Si tu organización estará lista cuando llegue, o si aún está descubriendo cuántos servidores no gestionados están funcionando en portátiles de desarrolladores, es la pregunta que debes hacerte.

Ricardo