La especificación de julio de 2026 lleva MCP hacia escala stateless, interacciones multivuelta explícitas, tareas en segundo plano e identidad empresarial.
La especificación del Model Context Protocol publicada el 28 de julio es menos vistosa que un nuevo modelo frontier, pero puede resultar más importante para la arquitectura empresarial. La versión hace más explícitas la operación stateless, las interacciones multivuelta, las tareas prolongadas, las cabeceras, el caching y la identidad gestionada.
En la práctica, MCP está pasando de ser una forma cómoda de conectar un modelo con una herramienta a convertirse en una capa de integración para producción.
Por qué importa el enfoque stateless
Las primeras integraciones de agentes solían mantener sesiones de transporte abiertas y guardar estado implícito dentro de ellas. Puede funcionar en un prototipo local. A escala genera fricción: routing pegajoso, recuperación difícil, contexto oculto e infraestructura obligada a conservar una conexión más tiempo que la tarea empresarial.
La especificación de julio elimina la dependencia de una sesión a nivel de protocolo. Cuando la aplicación necesita estado, la herramienta puede emitir un identificador explícito que el modelo devuelve en llamadas posteriores.
Es un límite más sano. El estado queda visible para la aplicación en lugar de oculto en el transporte. Puede versionarse, caducar, autorizarse y auditarse.
Un transporte stateless no significa procesos sin estado. Significa que el protocolo deja de confundir ambas cosas.
Las interacciones multivuelta hacen conversacionales las herramientas sin volverlas opacas
Las herramientas reales a veces necesitan información adicional a mitad de una llamada. Un pago puede requerir confirmación. Un viaje puede carecer de centro de coste. Una compra puede necesitar un identificador de proveedor.
El nuevo patrón permite que el servidor responda con input_required y solicite datos concretos antes de reanudar la operación original. La herramienta deja claro qué falta y por qué.
En sistemas empresariales es preferible a inventar parámetros silenciosamente o convertir cada excepción en otro prompt. El dato pendiente puede mostrarse a una persona, a otro agente o a un flujo de trabajo de aprobación mediante un contrato trazable.
Tasks separa el trabajo prolongado de la petición
La especificación traslada Tasks a una extensión y define consulta de estado mediante polling, además de actualizaciones. Refleja una realidad elemental: una llamada de agente puede iniciar trabajo que no cabe en una respuesta HTTP.
Por ejemplo:
- generar un informe regulatorio extenso;
- ejecutar una conciliación por lotes;
- esperar una aprobación externa;
- procesar un archivo documental;
- coordinar varios agentes.
Un objeto de tarea necesita propietario, estado, progreso, cancelación, caducidad y referencias al resultado. Las empresas deberían incorporar esos requisitos aunque el protocolo deje parte de ellos a la implementación.
Soportar el protocolo no equivale a gobernar
MCP estandariza cómo clientes y servidores describen capacidades e intercambian llamadas. No decide si un usuario concreto puede invocar una herramienta, si la acción es apropiada o cómo debe separarse una función.
Una capa MCP de producción sigue necesitando:
- autenticación y autorización;
- scopes por herramienta y acción;
- validación de parámetros;
- gestión de secretos;
- límites de frecuencia y coste;
- prevención de pérdida de datos;
- defensas frente a prompt injection;
- enforcement de políticas;
- telemetría completa;
- gestión de versiones y deprecaciones.
Un servidor MCP que expone una API interna potente sin esos controles no es una integración empresarial. Es una nueva superficie de ataque.
Los contratos de herramienta se vuelven activos estratégicos
Una buena herramienta MCP es más que un wrapper de API. Empaqueta una capacidad de negocio en un lenguaje comprensible para el agente y exigible por software.
Por ejemplo, create_refund resulta demasiado amplio. Una capacidad más segura podría exponer propose_refund, devolver política y evidencias aplicables, y exigir un token de aprobación antes de habilitar execute_approved_refund.
El nombre, los esquemas, las descripciones y los estados de error condicionan el comportamiento del modelo. Diseñar herramientas es ingeniería de APIs, políticas y experiencia a la vez.
Qué conviene estandarizar ahora
Las organizaciones que adopten MCP deberían definir un estándar interno para:
- propiedad y ciclo de vida de cada servidor;
- patrones de autenticación aprobados;
- convenciones de nombres y esquemas;
- separación entre leer, proponer y ejecutar;
- idempotencia y reintentos;
- semántica de tareas y cancelación;
- destinos de red autorizados;
- campos de auditoría obligatorios;
- pruebas de compatibilidad entre clientes;
- deprecación y respuesta a incidentes.
El objetivo no es obligar a que todas las integraciones pasen por un equipo. Es impedir que cientos de superficies incompatibles creen la siguiente deuda de integración.
La visión de Lexdatum
MCP se está convirtiendo en el tejido conectivo vertical entre agentes y capacidades empresariales.
Su valor no dependerá de cuántas herramientas exponga una compañía, sino de la calidad de sus contratos: capacidades pequeñas, gobernadas y observables que los agentes puedan utilizar sin heredar autoridad ilimitada.
El protocolo está madurando. Los estándares operativos de las empresas deben madurar con él.
Fuentes
Nota de investigación: este análisis se basa en información pública disponible a 31 de agosto de 2026. Las capacidades, los precios y las interpretaciones regulatorias pueden cambiar. Las métricas comunicadas por proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad o inversión.