La especificación MCP del 2026-07-28 elimina las sesiones a nivel de protocolo, mueve Tasks y MCP Apps a un marco formal de extensiones, endurece las reglas de OAuth y depreca el registro dinámico de clientes a favor de los documentos de metadatos de ID de cliente. PaidSync ejecuta en producción un servidor MCP remoto con más de 630 herramientas de anuncios en 14 plataformas para clientes de Claude y ChatGPT, y estas son notas de trabajo sobre qué significa cada cambio desde ese puesto. Nada se rompe el primer día; las funciones deprecadas tienen una ventana mínima de doce meses.
Cada afirmación de protocolo de abajo viene de la publicación de lanzamiento oficial y del registro de cambios del 2026-07-28, ambos leídos al redactar, el 1 de agosto de 2026. Las opiniones son nuestras. La publicación de lanzamiento aporta cifras de escala sobre por qué importa esta revisión: cerca de medio billón de descargas de SDK al mes entre los principales SDK, los SDK de TypeScript y Python con más de mil millones de descargas totales cada uno, y Honeycomb indicando que casi el 20 por ciento de sus consultas interactivas mensuales ya vienen de agentes. La cobertura de The Register recoge a los mantenedores calificándola como la versión más significativa desde que se lanzó el MCP remoto. Desde donde estamos, eso es más o menos cierto, y la mayor parte de su importancia es operativa más que vistosa.
Qué cambió el 28 de julio
| Cambio | En qué consiste | Desde el puesto del operador |
|---|---|---|
| Núcleo sin estado | Se eliminan el handshake initialize y Mcp-Session-Id; _meta por solicitud lleva la versión y las capacidades | Balanceo de carga simple, sin sesiones fijas |
| Reanudación eliminada | Los flujos rotos pierden la solicitud en curso; los clientes reenvían | Las herramientas de mutación necesitan claves de idempotencia |
| Extensión Tasks | io.modelcontextprotocol/tasks oficial, por sondeo, con entrada a mitad de proceso | Las operaciones largas de anuncios dejan de pelear con los tiempos de espera de la pasarela |
| MRTR | Los servidores devuelven input_required en lugar de llamar al cliente | Las preguntas a mitad de llamada pasan a ser estado reanudable |
| Refuerzo de la autenticación | Validación de iss según RFC 9207, credenciales ligadas al emisor | Se cierran los ataques de confusión en los flujos de tokens |
| DCR deprecado | Los documentos de metadatos de ID de cliente sustituyen el registro de RFC 7591 | La identidad del cliente queda respaldada por un dominio |
| MCP Apps | Extensión oficial para interfaz interactiva integrada | Gráficos y formularios de aprobación en la superficie del chat |
| Cabeceras y caché | Mcp-Method/Mcp-Name obligatorias; ttlMs en los resultados de listas | Política por herramienta en el borde sin analizar el cuerpo |
| Deprecaciones | Roots, Sampling, Logging, HTTP+SSE, ventana mínima de doce meses | Limpieza con un calendario predecible |
El núcleo sin estado y los reintentos
El cambio principal: el handshake initialize/notifications/initialized desaparece, y también la cabecera Mcp-Session-Id. Cada solicitud lleva ahora su versión de protocolo, las capacidades del cliente y la identidad del cliente en _meta, y una nueva RPC obligatoria server/discover permite a los clientes sondear las capacidades de antemano. Las notificaciones de cambios del servidor al cliente se consolidan en un único flujo opcional subscriptions/listen. El efecto práctico que buscan los mantenedores, y que The Register subraya, es que cualquier solicitud pueda llegar a cualquier instancia del servidor tras un balanceador de carga corriente, con herramientas corrientes de Kubernetes y sin almacén de sesiones compartido.
Esta es la lectura honesta desde el puesto del operador: el estado difícil nunca vivió en la sesión de protocolo. En un servidor de anuncios, el estado que importa son las concesiones OAuth, la cuenta publicitaria activa, los límites de gasto y los presupuestos de tasa por plataforma. Ese estado está en una base de datos ligada al usuario autenticado, porque debe sobrevivir a una conexión caída. Lo que añadía el handshake antiguo era una segunda sesión frágil que podía morir de forma independiente de la real, y un despliegue o el reinicio de un balanceador cortaba las sesiones de protocolo mientras las de autenticación seguían bien. Eliminar esa capa elimina toda una clase de fallos confusos. La sustitución que propone la especificación para el estado legítimo entre llamadas son manejadores emitidos por el servidor y pasados como argumentos normales de herramientas, que es como ya se leen los flujos de anuncios: eliges una cuenta, obtienes un manejador, lo pasas adelante. Fírmalos y haz que caduquen, porque cualquier instancia puede recibirlos en frío.
El punto delicado es la semántica de reintentos
Bajo la historia del modelo sin estado está el cambio con más probabilidad de causar incidentes con dinero real: se eliminan la reanudación de flujos SSE y la reentrega de mensajes. Con la versión 2026-07-28, un flujo de respuesta roto pierde la solicitud en curso, y el cliente debe reenviarla como una solicitud nueva con un ID de solicitud nuevo. Con get_campaign_performance, un reintento no cuesta nada. Con la creación de una campaña o una actualización de presupuesto, un reintento a ciegas es como un agente gasta dos veces. Si tu servidor modifica dinero, tus contratos de herramientas necesitan claves de idempotencia y tu backend necesita deduplicación, porque el transporte ya no promete reentregar el resultado original. Nuestras escrituras en producción están controladas con las marcas dry_run y confirm_destructive, que reducen el radio de impacto, pero un control no es una deduplicación. Trátalos como dos controles distintos y construye ambos.
Tasks por fin encaja con los anuncios
Tasks sale del núcleo experimental y se convierte en una extensión oficial, io.modelcontextprotocol/tasks. El rediseño sustituye la llamada bloqueante tasks/result por sondeo con tasks/get, añade tasks/update para entrada del cliente al servidor a mitad de tarea y permite a los servidores devolver manejadores de tarea sin que se soliciten, sin aceptación previa por solicitud. El artículo de The Register destaca el punto de la durabilidad: las tareas se direccionan con manejadores estables, así que un cliente puede conservar un ID de tarea y retomar el sondeo tras un fallo o reinicio.
El trabajo con anuncios es de larga duración por naturaleza. Una auditoría en un MCC de 200 campañas. Una pausa masiva en los conjuntos de anuncios de toda una temporada, el tipo de trabajo para el que existe nuestra documentación de operaciones masivas de Meta. Una descarga de informes multiplataforma de 90 días. Hoy todo eso tiene que terminar dentro del plazo que imponga el proxy delante de tu servidor, y todo despliegue en producción tiene uno. Las tareas por sondeo encajan con la infraestructura HTTP corriente: sin flujo abierto que vigilar, nada que un tiempo de espera del borde corte a medias.
tasks/update es la parte discretamente importante para los anuncios. Una tarea que acepta entrada a mitad de proceso es una tarea que puede detenerse antes de su mitad destructiva y preguntar. Hoy un control de aprobación son dos tareas: una prueba en seco y luego una confirmación explícita. Con Tasks, el mismo patrón de seguridad puede ser una única operación duradera con una pausa humana dentro, que es una forma mejor para agentes que planifican trabajo de varios pasos. La salvedad es estructural: las extensiones están desactivadas por defecto y requieren aceptación explícita de ambas partes, así que esto rinde cuando Claude y ChatGPT lancen soporte de cliente, no antes.
MRTR reemplaza las solicitudes del servidor
Las solicitudes iniciadas por el servidor (roots/list, sampling/createMessage, elicitation/create) se sustituyen por el patrón de solicitudes de múltiples idas y vueltas. Un servidor que necesita más información devuelve un resultado con resultType: "input_required" con sus preguntas; el cliente reintenta la solicitud original con las respuestas adjuntas en inputResponses. Ahora cada resultado lleva un resultType obligatorio, y los resultados de servidores de protocolos anteriores que lo omiten deben tratarse como completos, lo que mantiene sensatas las flotas de versiones mixtas.
Elicitation era como un servidor preguntaba “¿a cuál de tus 14 cuentas publicitarias te referías?” en mitad de una llamada. MRTR conserva la pregunta e invierte la mecánica. El servidor ya no puede dejar una pregunta pendiente en la memoria del proceso, porque el reintento puede llegar a otra instancia; el contexto que necesite la pregunta va en requestState. Es molesto de adaptar y correcto por diseño. También formaliza una lección que todo servidor de anuncios remoto aprende pronto: los clientes de chat desaparecen constantemente a mitad de conversación, así que toda pregunta a mitad de operación que no sea reanudable es una pregunta que dejará una operación colgada. Hemos visto suficientes flujos a medias como para considerar esto la especificación poniéndose al día con la realidad.
PaidSync es un servidor MCP remoto para trabajo con anuncios. Más de 630 herramientas en 14 plataformas, un solo endpoint, desde Claude o ChatGPT.
Ver el servidor MCP Empieza gratisLa autorización es más difícil de hacer mal
Tres refuerzos, todos con fuente en el registro de cambios. Los servidores de autorización deberían incluir el parámetro iss en las respuestas de autorización según RFC 9207, y los clientes deben validarlo con el emisor registrado antes de canjear un código. Las credenciales de cliente quedan ahora explícitamente ligadas al servidor de autorización que las emitió: indexadas por emisor, nunca reutilizadas entre emisores y registradas de nuevo cuando cambia el emisor. Y los clientes deben declarar un application_type durante el registro, lo que corrige una clase antigua de rechazos de redirección a localhost en agentes de CLI y de escritorio. La autorización gestionada por la empresa también llega como extensión formal, y da a las organizaciones control centralizado sobre qué servidores MCP pueden usar sus agentes.
Por qué esto importa más para los servidores de anuncios que para la mayoría: un token de portador a un servidor MCP de anuncios remoto da acceso a cuentas publicitarias reales en Google, Meta y LinkedIn, con presupuestos reales detrás. Es justo el tipo de objetivo para el que se inventaron los ataques de confusión de OAuth, y la validación de iss es la contramedida estándar. La mayoría de las nuevas obligaciones recaen en el código del cliente, pero solo funcionan si los servidores publican metadatos de autorización precisos contra los que validar. Para que conste, la base de PaidSync ya en producción son los metadatos del servidor de autorización de RFC 8414 y los metadatos del recurso protegido de RFC 9728 en las rutas well-known, un security.txt publicado, una tarjeta de servidor MCP y un manifiesto de autenticación de agentes, y la revocación de sesiones para que un usuario pueda cortar el acceso de un cliente conectado en cualquier momento. Es la revisión estable actual hecha con cuidado, no una implementación de la 2026-07-28; lo decimos claramente porque leer una especificación no es publicarla.
DCR sale, CIMD entra
El registro dinámico de clientes (RFC 7591) queda formalmente deprecado como mecanismo de registro de clientes de MCP a favor de los documentos de metadatos de ID de cliente. Sigue disponible por compatibilidad hacia atrás con servidores de autorización que aún no han migrado. Con CIMD, el client_id es una URL HTTPS que controla el operador del cliente, y el servidor de autorización obtiene los metadatos del cliente de esa URL.
Esto lo habríamos votado dos veces. Con DCR, cada agente desconocido se autorregistraba en tu servidor de autorización: filas anónimas, nombres autodeclarados, cero reputación y un trabajo periódico de limpieza de registros que nadie llegó a usar. CIMD cambia la pregunta en la puerta de “¿se registró esto?” a “¿quién es el dueño de este dominio?”. Para un servidor que da acceso a gasto publicitario, esa diferencia es de nivel de política. Hace posibles las listas permitidas de plataformas de agentes conocidas y hace honesta la pantalla de consentimiento: el nombre de cliente que aprueba un usuario está respaldado por un dominio, no escrito por el propio cliente. El consejo de migración se escribe solo: mantén DCR funcionando durante la ventana de deprecación, prefiere CIMD para todo cliente que lo presente y empieza a redactar ya la política de confianza, porque la política es lo difícil, no el análisis.
MCP Apps y los cambios de fontanería
MCP Apps
MCP Apps llega como extensión oficial en el nuevo marco de extensiones. La documentación de extensiones la describe como la posibilidad de que los servidores muestren elementos de interfaz interactivos, gráficos, formularios, reproductores de vídeo, dentro de las conversaciones. Para el trabajo con anuncios los candidatos son obvios: una tendencia de gasto como gráfico real en lugar de una tabla ASCII, una vista previa de la campaña antes del lanzamiento, un formulario de aprobación de un cambio masivo con una casilla por campaña. Un formulario de aprobación renderizado es una superficie de seguridad claramente mejor que un “sí, confirmo” en texto libre. Misma salvedad que con Tasks: aceptación explícita de ambas partes, así que la adopción de los clientes marca el calendario.
Cabeceras y caché
Los POST de Streamable HTTP deben llevar ahora las cabeceras Mcp-Method y Mcp-Name, para que las pasarelas puedan enrutar y limitar la tasa sin analizar cuerpos JSON. Con 438 herramientas en vivo en nuestro servidor, la política por herramienta en el borde, límites más estrictos en las herramientas de mutación y reglas de WAF que nunca tocan un cuerpo, es una capacidad barata que vamos a aprovechar. Los resultados de listas (tools/list y similares) deben llevar ahora ttlMs y cacheScope, lo que significa que los clientes por fin pueden dejar de volver a descargar un catálogo grande de herramientas en cada turno. La especificación también anima a los servidores a devolver las herramientas en orden determinista para mejorar los aciertos de caché de prompts de los LLM; para catálogos de nuestro tamaño, es una palanca directa sobre el coste de tokens. Escribimos sobre el equilibrio del tamaño del catálogo en por qué el número de herramientas es una ventaja.
Deprecaciones con fecha real
Roots, Sampling y Logging quedan deprecados, junto con el transporte heredado HTTP+SSE, bajo un nuevo ciclo de vida de funciones que garantiza una ventana de transición mínima de doce meses. Nada de eso nos duele aquí. El sampling del lado del servidor siempre tuvo mala forma en un límite de facturación, porque implica que un servidor de herramientas gasta tokens de modelo de otra persona; el logging pasa a stderr u OpenTelemetry, que es lo que ya hacen los servidores de producción. La política de ciclo de vida en sí es la ganancia: las retiradas ahora vienen con un calendario con el que puedes planificar en lugar de una sorpresa.
Lo que esto no cambia
Claro, para que nadie lea de más
PaidSync no ha lanzado la revisión del 2026-07-28. Nuestro servidor de producción habla el protocolo estable actual que hablan hoy los clientes de Claude y ChatGPT, y nuestra adopción seguirá la suya, porque una especificación que solo habla una parte es una especificación que no habla nadie. Los plazos de soporte de los clientes corresponden a sus proveedores, y no los vamos a adivinar por escrito. Las extensiones, incluidas Tasks y MCP Apps, están desactivadas por defecto y requieren aceptación de ambos extremos. Nada se elimina el primer día: las funciones deprecadas tienen una ventana mínima de doce meses y DCR sigue funcionando por compatibilidad hacia atrás. Y la especificación corrige el estado del protocolo, no el criterio publicitario. El gasto desperdiciado, el seguimiento de conversiones roto y las malas decisiones de audiencia sobreviven intactos a cualquier revisión del protocolo; esa capa se trata en cómo encontrar gasto publicitario desperdiciado con IA.
Checklist de primera semana
Si gestionas o estás creando un servidor MCP remoto, este es el orden en que trabajaríamos, basado en haber gestionado uno en producción.
1. Audita cada herramienta de mutación para ver si admite reintentos. La reanudación desaparece; los clientes reenviarán las solicitudes perdidas. Añade claves de idempotencia a toda herramienta que cree o cambie algo que cueste dinero.
2. Mueve el estado entre llamadas tras manejadores emitidos por el servidor. Todo lo que viva en la memoria del proceso ligado a una sesión de protocolo muere con esta revisión. Manejadores como argumentos de herramientas, firmados y con caducidad.
3. Revisa tus metadatos de OAuth. La nueva validación de iss en el cliente y la vinculación al emisor solo funcionan frente a documentos well-known de RFC 8414 y RFC 9728 precisos. Publícalos y mantenlos veraces.
4. Redacta una política de confianza de CIMD. Decide qué dominios de cliente permitirás y cómo será el DCR anónimo de reserva durante la ventana. Primero la política, después el código.
5. Asigna a Tasks las herramientas de larga duración. Lista todas las herramientas que pueden superar el plazo de tu pasarela y marca cuáles necesitan entrada a mitad de proceso, porque esas pasan a ser pausas de aprobación con tasks/update.
6. Haz tools/list determinista y fija TTL honestos. Un orden estable más ttlMs es ahorro gratuito de tokens para todo cliente con caché de prompts.
Gestiona anuncios desde Claude o ChatGPT con un único endpoint MCP. El plan gratuito incluye 100 tareas al mes, valoradas en $50, sin tarjeta.
Empieza gratis Ver preciosAñadir a ChatGPT: abre PaidSync.ai en el directorio de plugins de ChatGPT, instálalo e inicia sesión.
Añadir a Claude: abre PaidSync.ai en el directorio de conectores de Claude, haz clic en Conectar e inicia sesión.
Preguntas frecuentes
¿Qué cambió en la especificación MCP del 2026-07-28?
La revisión hace que MCP sea sin estado: se eliminan el handshake initialize y la cabecera Mcp-Session-Id, cada solicitud lleva su versión de protocolo y las capacidades del cliente en _meta, y una nueva RPC server/discover anuncia las capacidades del servidor. Se elimina la reanudación de flujos SSE, así que los flujos rotos implican solicitudes reenviadas. Tasks pasa del núcleo experimental a una extensión oficial con tasks/get por sondeo y entrada a mitad de proceso mediante tasks/update. Las solicitudes de múltiples idas y vueltas sustituyen las llamadas de elicitation, sampling y roots iniciadas por el servidor. La autorización se refuerza con la validación de iss según RFC 9207 y credenciales ligadas al emisor. El registro dinámico de clientes se depreca a favor de los documentos de metadatos de ID de cliente. Roots, Sampling, Logging y HTTP+SSE se deprecan con una ventana mínima de doce meses. Fuente: el registro de cambios oficial, leído el 1 de agosto de 2026.
¿Rompe la especificación del 2026-07-28 los servidores MCP existentes?
No el primer día. La versión adopta un ciclo de vida formal de funciones con una ventana de deprecación mínima de doce meses, DCR sigue funcionando por compatibilidad hacia atrás y los clientes deben tratar como completos los resultados de servidores de protocolos anteriores que omiten el nuevo campo resultType. El cambio que merece atención inmediata es la semántica de reintentos: se eliminan la reanudación y la reentrega de mensajes, así que un cliente que pierde un flujo de respuesta reenvía la solicitud. Los servidores que exponen herramientas de mutación, como la creación de campañas o los cambios de presupuesto, deberían añadir claves de idempotencia para que una escritura reenviada no se aplique dos veces.
¿Qué sustituye al registro dinámico de clientes en MCP?
Los documentos de metadatos de ID de cliente (CIMD). En lugar de autorregistrarse en cada servidor de autorización según RFC 7591, un cliente usa como client_id una URL HTTPS que controla, y el servidor de autorización obtiene los metadatos del cliente de esa URL. La identidad pasa a estar respaldada por un dominio y es verificable, lo que permite a los operadores de servidores crear políticas de listas permitidas para plataformas de agentes conocidas y mostrar pantallas de consentimiento respaldadas por un dominio y no por un nombre autodeclarado. DCR está deprecado, pero sigue disponible para servidores de autorización que aún no admiten CIMD.
¿Implementa ya PaidSync la especificación MCP del 2026-07-28?
No. El servidor MCP de producción de PaidSync funciona con el protocolo estable actual que hablan hoy los clientes de Claude y ChatGPT. La base ya en producción son los metadatos del servidor de autorización de RFC 8414 y los metadatos del recurso protegido de RFC 9728 en endpoints well-known, un security.txt y una tarjeta de servidor MCP publicados, la revocación de sesiones y escrituras con control mediante las marcas dry_run y confirm_destructive. La adopción de la nueva revisión seguirá el soporte de los clientes en Claude y ChatGPT.