Hablemos de su proyecto
Protocolos agénticos

MCP en empresa en 2026: arquitectura, autorización, gobernanza y migración hacia la especificación 2026-07-28

MCP estandariza la conexión entre aplicaciones de IA, datos y herramientas. No estandariza ni la confianza, ni los derechos comerciales, ni la gobernanza: estas responsabilidades siguen siendo de diseño.

MCP en empresa en 2026: arquitectura, autorización, gobernanza y migración hacia la especificación 2026-07-28

El Protocolo de Contexto de Modelo, o MCP, proporciona un lenguaje común para conectar una aplicación basada en un modelo con herramientas y fuentes de contexto. Un cliente puede descubrir capacidades, llamar a una herramienta o integrar una interfaz sin desarrollar un conector específico para cada par de aplicaciones.

Esta estandarización acelera la integración. No transforma un servidor en un componente confiable. La empresa siempre debe decidir quién puede usarlo, qué datos ve, qué acciones realiza y cómo se supervisa.

La especificación oficial 2026-07-28 ha introducido un núcleo sin estado y varias evoluciones importantes; los SDK y las desaprobaciones deben verificarse antes de la implementación.

Lo que MCP estandariza

MCP describe los intercambios entre una aplicación cliente y un servidor que expone capacidades. Según la versión y las extensiones, estas pueden incluir herramientas, recursos, interfaces o tareas largas.

El protocolo aporta:

  • descubrimiento estructurado ;
  • esquemas de entrada y salida;
  • transporte ;
  • ciclo de consulta ;
  • mecanismos de autorización;
  • convenciones de compatibilidad;
  • SDK en varios lenguajes.

No define las reglas de negocio, el nivel de confianza, la clasificación de los datos ni el derecho real del usuario en el sistema objetivo.

Lo que cambia la revisión 2026-07-28

La especificación publicada el 28 de julio de 2026 adopta un núcleo de protocolo sin estado. El handshake y la sesión gestionados a nivel del protocolo se eliminan, a fin de facilitar el enrutamiento, la escalabilidad y la infraestructura HTTP clásica. La aplicación puede mantener un estado, pero ya no debe depender de una sesión MCP implícita.

La revisión también refuerza la autorización, formaliza el marco de extensiones, introduce o estabiliza mecanismos como las solicitudes de varios pasos, las aplicaciones MCP y la extensión Tasks para trabajos largos. Algunas capacidades históricas están obsoletas. El equipo debe leer el registro de cambios y probar sus clientes y servidores con los SDK adecuados.

Distinguir protocolo y arquitectura empresarial

Una arquitectura empresarial generalmente añade:

  • registro de servidores aprobados;
  • pasarela o proxy;
  • identidad y delegación;
  • política de herramientas;
  • filtrado de red ;
  • secretos ;
  • observabilidad ;
  • caja de arena ;
  • aprobaciones ;
  • proceso de versión y retiro.

El cliente no debería poder conectarse libremente a cualquier servidor descubierto en Internet desde un entorno sensible.

Diseñar la identidad y la autorización

El acceso debe reflejar al usuario y el contexto. Un servidor no debe recibir un token general que otorgue más derechos que la persona. Los alcances están limitados a las capacidades y recursos necesarios.

Los principios incluyen:

  • consentimiento explícito;
  • audiencia del token;
  • duración corta;
  • separación cliente/servidor ;
  • rotación ;
  • protección contra redirecciones abusivas;
  • revocación;
  • diario de autorización.

Los derechos de negocio siempre son verificados nuevamente por el servicio de destino. Una herramienta MCP no es una vía para eludir las API habituales.

Exponer herramientas seguras

Las herramientas son pequeñas, nombradas según la ocupación y validadas por un esquema estricto. No dan acceso a un shell ni a una consulta arbitraria. Devuelven resultados estructurados y limitan los datos.

Para una acción:

  • identidad ;
  • alcance ;
  • validación ;
  • idempotencia ;
  • previsualización ;
  • aprobación ;
  • verificación;
  • auditoría ;
  • compensación.

La descripción de la herramienta ayuda al modelo, pero la política independiente determina si se puede llamar.

Tratar los recursos e interfaces como datos no confiables

Un servidor puede exponer un contenido que contenga instrucciones maliciosas. El cliente debe separar datos e instrucciones y aplicar las mismas protecciones que para la web o el correo electrónico.

Las aplicaciones MCP o interfaces ofrecidas por el servidor están aisladas, sometidas a una política de contenido y privadas de acceso implícito a los secretos. Su origen y sus capacidades deben ser visibles para el usuario.

Gestionar las tareas largas

Las tareas agenciales pueden durar más allá de una solicitud. La extensión de tareas aporta un modelo, pero la aplicación aún debe gestionar:

  • identidad y autorización durante la duración;
  • estado ;
  • anulación ;
  • reanudación;
  • vencimiento;
  • presupuesto ;
  • notificación ;
  • resultado;
  • idempotencia.

Una tarea no debe conservar un poder indefinido. Los permisos pueden expirar o requerir una nueva validación antes de un paso sensible.

Stateless no significa sin estado

El corazón sin estado simplifica la infraestructura, pero las aplicaciones conservan conversaciones, tareas, aprobaciones y resultados. Este estado debe ser explícito, almacenado en un sistema gobernado y asociado a una identidad.

El enrutamiento por encabezados y las listas en caché requieren una política de privacidad y de invalidez. Los metadatos no deben revelar capacidades prohibidas.

Gobernar un catálogo de servidores

Cada servidor es un proveedor de software, datos y acciones. El registro debe incluir:

  • propietario;
  • procedencia ;
  • versión ;
  • capacidades ;
  • datos ;
  • derechos ;
  • entornos;
  • dependencias;
  • soporte ;
  • riesgos;
  • estatus de aprobación;
  • fecha de revisión.

Arquitectura MCP 2026-07-28 con núcleo stateless, autorización, herramientas, Apps y extensión Tasks.

Calificar un servidor tercero

El equipo examina el código o el origen, la política de actualización, las vulnerabilidades, la recopilación de datos y los destinos. Un servidor puede cambiar sus herramientas; el cliente debe detectar la diferencia y solicitar una nueva aprobación cuando evoluciona el riesgo.

El piloto se ejecuta en un entorno aislado, con datos sintéticos y tokens limitados. Se prueban los comportamientos de error y de retirada.

Pasarela y proxy

Una pasarela empresarial puede centralizar la autenticación, la lista autorizada, los límites, los registros y el enrutamiento. Reduce la dispersión, pero se convierte en un componente crítico. Debe preservar la identidad del usuario y evitar convertirse en una supercuenta.

Ella puede bloquear algunas herramientas, transformar los ámbitos, aplicar una política de destinos y proporcionar métricas. Los registros minimizan los parámetros sensibles.

Observabilidad

Cada llamada está correlacionada con la aplicación, el usuario, el servidor, la herramienta, la versión y el resultado. Las métricas siguen la latencia, los errores, el volumen, los costos, los rechazos, las aprobaciones y los destinos.

Un aumento de llamadas, una herramienta nueva o un destino inusual desencadena una alerta. La capacidad de corte permite suspender un servidor sin desplegar todos los clientes.

Migración hacia 2026-07-28

La migración debe comenzar con un inventario de los clientes, servidores, SDK y funciones utilizadas. El registro de cambios identifica los elementos obsoletos y los cambios de transporte o de autorización.

El procedimiento comprende:

  1. pruebas de compatibilidad en un entorno separado;
  2. actualización de los SDK;
  3. eliminación de las dependencias de la sesión protocolaria;
  4. adaptación de la autorización;
  5. validación de esquemas;
  6. pruebas de extensiones;
  7. despliegue progresivo;
  8. observación ;
  9. retiro del antiguo camino.

Los clientes y servidores pueden requerir un período de coexistencia versionada.

Pruebas de seguridad

Probar:

  • servidor no aprobado;
  • cambio de herramienta;
  • alcance demasiado amplio;
  • ficha destinada a otro servidor;
  • contenido inyectado ;
  • herramienta genérica ;
  • respuesta malformada;
  • tarea sin fin;
  • anulación ;
  • destino externo;
  • pérdida de conexión;
  • revocación.

Los escenarios se convierten en una serie de regresión.

MCP como contrato de integración

MCP reduce el costo de los conectores y favorece un ecosistema abierto. Su adopción en la empresa exige la misma disciplina que las API: catálogo, versión, seguridad, observabilidad y responsabilidad.

Partitech puede desarrollar servidores y clientes MCP, diseñar la puerta de enlace, calificar las herramientas y acompañar la migración hacia la especificación 2026-07-28. El protocolo se convierte entonces en un componente controlado de la plataforma agentica, no en una puerta abierta hacia todas las herramientas.

Hablemos de su proyecto

Diseñar un catálogo MCP seguro y gobernado con Partitech. Contacte a Partitech.

Compartir este artículo