MCP se diseñó para una persona sentada frente a un portátil. La hoja de ruta de 2026 consiste en quitarla de en medio
By Surya Pratap
24 de agosto de 2026
12 min de lectura
IA y tecnología
24 de agosto de 2026
12 min de lectura
Cuatro suposiciones, cuatro sustitutosHover to exploreLa hoja de ruta del Model Context Protocol se actualizó el 22 de agosto de 2026 y, enterrada en la tercera área prioritaria, aparece la frase más esclarecedora que se ha escrito este año sobre infraestructura de agentes:
La autorización de MCP da por hecho que hay una persona con un navegador en el momento del consentimiento.
Léanse las otras cuatro áreas prioritarias después de esa y dejan de parecer una lista de funciones. Son un único proyecto con cinco frentes: el protocolo se diseñó para alguien sentado frente a un portátil, y producción no deja de descubrir que ahí no hay nadie.
Ese cambio de encuadre merece una tarde de atención, porque cada punto de la hoja de ruta es algo que usted resuelve hoy a mano, normalmente mal y normalmente sin haberse dado cuenta de que tomaba una decisión.
La hoja de ruta es explícita en que se trata de un documento de priorización, no de un calendario de entregas: las SEP —Specification Enhancement Proposals— que caen dentro de estas áreas «reciben revisión acelerada y tienen las mejores opciones de ser aceptadas». Todo lo demás espera.
Las cinco áreas y la suposición humana que elimina cada una
Áreas prioritarias de la hoja de ruta de 2026
stdio convertido en HTTP hablado sobre stdin/stdout.tools/call que todos interpretarían igual. Ninguna de las dos se sostuvo.Las cuatro primeras son arquitectura. La quinta trata de cómo le llegan a usted las otras cuatro, y eso importa más de lo que parece: es la diferencia entre que un cambio de especificación aterrice en su SDK en semanas o en meses.
Antes de la hoja de ruta hubo una versión. La especificación 2026-07-28 volvió sin estado el núcleo del protocolo, y ese es el cambio con más probabilidades de tocar un sistema que usted tenga hoy en marcha.
En concreto, eliminó el saludo initialize/initialized y la cabecera Mcp-Session-Id. Cada petición lleva ahora su propia versión de protocolo, identidad de cliente y capacidades en _meta. La consecuencia, en palabras de la propia especificación, es que cualquier petición puede aterrizar en cualquier instancia del servidor detrás de un balanceador de carga round-robin corriente, sin almacenamiento compartido.
Por qué a un fundador debería importarle que se elimine un saludo
Las sesiones con estado se pelean con los balanceadores de carga. Si desplegó un servidor MCP remoto en más de una instancia, o fijó sesiones, o compartió estado a través de Redis, o mantuvo en silencio una sola máquina y cruzó los dedos. Las tres cosas son parches para una suposición que ya se ha eliminado del protocolo. Si construyó uno de esos parches, ahora es lastre en lugar de complejidad necesaria, y conviene borrarlo de forma deliberada en vez de arrastrarlo a lo siguiente que construya.
En la misma versión aterrizaron otras tres cosas fáciles de pasar por alto y de utilidad inmediata:
resultType: "input_required" y el cliente reintenta la llamada original con las respuestas en inputResponses. Aprobación humana sin que la conexión sea lo que sostiene el estado.Mcp-Method y Mcp-Name, de modo que pasarelas, limitadores de tasa y WAF pueden enrutar y medir por cabecera en lugar de desempaquetar JSON. Si alguna vez quiso límites de tasa por herramienta en el borde, este es el gancho que le faltaba.ttlMs y cacheScope en resultados de listado y lecturas de recursos. Campo pequeño, factura grande: es la diferencia entre volver a pedir el catálogo de herramientas en cada sesión y pedirlo cuando cambia.De todo lo que hay en la hoja de ruta, este es el punto que un fundador nota primero y el que más fácilmente se archiva como una comodidad.
El planteamiento de la hoja de ruta es que los servidores «necesitan más opciones para guiar a los clientes a través de conjuntos grandes de herramientas» y que los clientes deberían «conocer las herramientas y los recursos de un servidor a medida que los necesitan, en lugar de ingerir el catálogo completo por adelantado».
He aquí por qué eso es una línea en su factura. Hoy, el catálogo de herramientas entra en la ventana de contexto al empezar la sesión. Todas las herramientas. Todas las descripciones. Todos los esquemas de parámetros. En cada tarea. Conecte cuatro o cinco servidores MCP de cierta envergadura y estará gastando miles de tokens antes de que el modelo haya leído la primera frase del usuario, y volverá a pagarlo en la tarea siguiente, y en la de después.
Es el mismo fallo que un AGENTS.md demasiado exhaustivo, entrando por otra puerta: contenido que se carga sin condiciones, lo necesite o no la tarea. La solución es la misma en ambos casos —hacer que la carga sea condicional— y solo uno de los dos tiene un grupo de trabajo construyendo el mecanismo por usted.
De ahí se siguen dos cosas. Mientras no exista el descubrimiento progresivo, el número de servidores MCP que conecta es una decisión de coste en vivo, no de capacidad, y lo sensato por defecto son menos servidores con conjuntos de herramientas más estrechos. Y cuando exista, los servidores que se beneficiarán serán aquellos cuyas herramientas estuvieran organizadas en algo que un cliente pudiera recorrer, que es una decisión de diseño que puede tomar ya, en cómo agrupa y nombra sus herramientas, antes de que se publique ningún mecanismo.
La hoja de ruta señala además que el descubrimiento progresivo tiene una «interacción definida con el trabajo de caché», es decir, que descubrimiento y caché por TTL se están diseñando para funcionar juntos en vez de chocar. Ese es el tipo de detalle que decide si una función es utilizable en el primer año o en el tercero.
La tercera área prioritaria es la que nombra el problema en voz alta. La descripción que la propia hoja de ruta hace del estado actual:
Los servidores MCP existentes se apoyan en claves de API pegadas y tokens de refresco de larga duración.
Es una descripción exacta de casi todos los sistemas de agentes hoy en producción, incluidos muchos que se describirían a sí mismos como seguros. El trabajo que se prioriza frente a ello:
Qué se está estandarizando y a qué sustituye
Grupo de trabajo de identidad de agentes, en formación durante este periodo
La mitad de la delegación merece énfasis, porque es la que se corresponde con un error arquitectónico real. Cuando hoy un agente lanza un subagente, este casi siempre corre con las credenciales del padre, porque estrecharlas exige maquinaria que nadie construyó. Eso significa que el radio de impacto del paso menos fiable de su cadena es el radio de impacto de toda la cadena. Es el mecanismo, no una hipótesis, y es la misma conclusión a la que llegamos desde el otro lado en Los agentes de IA necesitan sistemas de permisos, no mejores prompts.
Una advertencia, la misma que se aplica a la consolidación de protocolos que tratamos la semana pasada: la identidad responde a quién llama. No responde a si lo que pide es buena idea. Un agente perfectamente autenticado que ha leído una instrucción maliciosa en una página web hará su llamada maliciosa con credenciales impecables. Todo lo que dice la guía de seguridad de agentes sobre tratar como no fiable el contenido visible para el modelo sobrevive intacto a todo esto.
Una hoja de ruta no es una fecha de entrega. El propio documento lo dice: «pensamiento actual más que compromisos firmes», con un horizonte de seis a doce meses. Aún se están formando grupos de trabajo para dos de las cinco áreas.
Así que la pregunta útil no es qué conviene esperar. Es qué le dice esto sobre dónde deben ir las costuras.
tools/call se está rehaciendo porque content y structuredContent produjeron implementaciones divergentes. No invierta en un tratamiento ingenioso de una forma que está en la lista de cambios.La tarjeta del medio es la que carga con el peso. Todo lo que hay en las cuatro primeras áreas prioritarias es algo que un equipo que lanza hoy resuelve de manera informal. El valor de la hoja de ruta para un fundador es que le dice cuáles de sus soluciones informales son temporales por diseño, y esas son exactamente las que merecen una interfaz en lugar de quedar repartidas por el código.
En concreto, para un equipo que construye un producto con agentes este trimestre: si el manejo de credenciales, el de tareas largas y el armado del catálogo de herramientas viven cada uno en un solo sitio con una superficie pequeña, adoptará los estándares cuando lleguen a su SDK y será un no-evento. Si están embadurnados por los puntos de llamada, no los adoptará, y describirá eso como una decisión de priorización.
Tres cosas que conviene decir claramente, porque una hoja de ruta bien escrita crea una leve ilusión de cobertura.
No hace fiables a los agentes. Todo lo de aquí es transporte, identidad y descubrimiento. Nada toca si el modelo eligió la herramienta correcta, leyó bien el resultado o debería haberse detenido. Eso sigue siendo un problema de evaluación y sigue siendo suyo.
No acorta su cadena de dependencias. Un núcleo sin estado y un transporte unificado hacen más fácil conectar más servidores. Fácil no es gratis: cada servidor conectado es coste de contexto, un modo de fallo y una frontera de confianza. Que el protocolo mejore en conexiones no es un argumento para tener más conexiones.
No llega en un calendario con el que pueda planificar. Dos grupos de trabajo aún se están formando. Las tareas siguen siendo una extensión camino de «su eventual inclusión en el protocolo central». Planificar con sensatez es tratar cada punto de la hoja de ruta como algo que quizá llegue a su SDK el año que viene, y construir como si pudiera no llegar.
La hoja de ruta de MCP actualizada el 22 de agosto es un documento estratégico mejor que el que escriben sobre sí mismas la mayoría de las empresas, porque nombra su propia suposición equivocada en lenguaje llano en vez de presentar el arreglo como una innovación. El protocolo se diseñó para una persona con navegador, en un portátil, esperando un par de segundos la respuesta de un puñado de herramientas. Las cuatro cláusulas son hoy falsas en producción, y la hoja de ruta es el trabajo de deshacerlas.
Para un fundador, el contenido práctico no es la lista de funciones. Es la confirmación de que cuatro de las cosas que hoy parchea —credenciales para usuarios ausentes, trabajo que sobrevive a una petición, catálogos demasiado grandes para cargarlos y un transporte que se comporta distinto en un portátil que en un clúster— son temporales por diseño, están en manos de personas con nombre y apellidos y merecen una interfaz ya.
Construya la versión tosca. Deje la costura. Borre los parches que ya tienen un estándar.
Fuentes: Model Context Protocol — hoja de ruta, actualizada el 2026-08-22 · La especificación 2026-07-28, blog de MCP · SEP-2575, MCP sin estado · SEP-2549, TTL para resultados de listado · SEP-2663, extensión de tareas · Grupos de trabajo y de interés
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
