Anthropic, Simon Willison y el giro hacia MCP sin estado

Anthropic presentó MCP en 2024, pero Simon Willison más tarde consideró que las herramientas de terminal eran más flexibles. La especificación del 28 de julio de 2026 ha revertido ahora parte de esa conclusión. Elimina las sesiones de protocolo y convierte las llamadas MCP remotas en solicitudes autocontenidas.

Este cambio ha renovado el interés de Willison e inspirado dos proyectos, mcp-explorer y datasette-mcp. Más importante aún, aborda la debilidad arquitectónica que hacía que los servidores MCP remotos fueran más difíciles de desplegar que los servicios HTTP convencionales.

Por tanto, la historia de Anthropic y Simon Willison no es otra actualización de protocolo. Es una prueba de si MCP puede dejar de competir con las herramientas de línea de comandos y asentarse en un papel más defendible. Skills sigue siendo atractivo para enseñar a los agentes a utilizar software existente, mientras que MCP sin estado ofrece herramientas remotas estructuradas, descubrimiento, autorización e infraestructura compartida.

MCP sin estado elimina la sesión de cada ruta de solicitud

La nueva especificación transforma MCP de un protocolo centrado en conexiones en uno centrado en solicitudes.

El Model Context Protocol define una interfaz estándar mediante la cual los agentes de IA pueden descubrir y llamar herramientas externas. Anthropic lo presentó en noviembre de 2024, y los desarrolladores produjeron rápidamente servidores para bases de datos, navegadores, plataformas de comunicación y aplicaciones empresariales.

Las versiones anteriores imponían un proceso de inicialización antes de las llamadas regulares a herramientas. El cliente y el servidor intercambiaban sus versiones de protocolo, capacidades e información de identificación. Esa negociación establecía un contexto que se esperaba que los mensajes posteriores conservaran.

Los servidores HTTP también podían emitir un Mcp-Session-Id. Después, los clientes devolvían ese identificador en solicitudes posteriores. El acuerdo hacía que una secuencia de llamadas se comportara como una conversación continua entre un cliente específico y una instancia concreta del servidor.

Ese diseño generaba consecuencias para la infraestructura. Un balanceador de carga debía dirigir las llamadas relacionadas a la instancia correcta o almacenar los datos de sesión en un repositorio compartido. Los operadores también necesitaban políticas de expiración, reconexión, recuperación y limpieza.

La revisión final 2026-07-28 elimina el intercambio obligatorio initialize. También elimina la sesión a nivel de protocolo y su cabecera asociada. Ahora cada solicitud incluye la información necesaria para interpretarla de forma independiente.

El lanzamiento oficial de MCP describe la revisión como el mayor cambio desde el lanzamiento del protocolo. Su núcleo sin estado se acompaña de extensiones, un soporte de Tasks revisado, cambios en la autorización y un ciclo de vida formal de funcionalidades.

Ahora un cliente puede enviar directamente una llamada a una herramienta. La solicitud incluye su versión de protocolo, método, nombre de herramienta, información del cliente y capacidades relevantes. Cualquier instancia de servidor compatible puede procesarla sin depender de un intercambio previo.

El cambio también añade server/discover, que permite a los clientes solicitar capacidades del servidor cuando las necesiten. El descubrimiento ya no obliga a cada llamante a crear y mantener una sesión de protocolo.

Esto es distinto de afirmar que toda aplicación debe descartar el estado. Un servicio de automatización de navegador, carrito de compra, transacción de base de datos o flujo de investigación todavía puede conservar información entre llamadas.

La diferencia radica en dónde vive esa información y cómo se direcciona. En lugar de ocultarla tras una sesión, el servidor puede devolver un identificador explícito. El modelo proporciona ese identificador en llamadas posteriores.

Un servidor de navegador podría devolver un browser_id después de iniciar una instancia. Las herramientas posteriores pueden aceptar ese valor al navegar, capturar una página o cerrar el navegador. Una herramienta de base de datos puede aplicar el mismo patrón a un identificador de transacción.

La propuesta sin sesiones aceptada describe estos valores como manejadores de estado explícitos. No son un nuevo tipo de datos de MCP. Son entradas y salidas de herramientas ordinarias que hacen visible el estado de la aplicación.

Esa visibilidad es importante para los agentes. Un orquestador puede compartir un manejador con un subagente mientras mantiene otro aislado. También puede registrar el identificador para trabajo posterior o entregarlo a otro proceso autorizado.

Las operaciones de listado obtienen una ventaja adicional. Cuando las herramientas y recursos ya no pueden cambiar según una sesión ambigua, los clientes pueden almacenar en caché los resultados de descubrimiento con mayor seguridad. Esto reduce las llamadas repetidas entre agentes de corta duración.

MCP sin estado también se adapta mejor a las operaciones HTTP conocidas. Los servidores remotos pueden usar balanceo estándar de tipo round-robin, enrutamiento habitual mediante gateways, autenticación por solicitud y sistemas de observabilidad consolidados.

Esta combinación es la que renovó la atención de Willison. La actualización no se limita a acortar el intercambio inicial. Elimina un compromiso arquitectónico que antes se filtraba en cada despliegue y en cada implementación de cliente.

Por qué importa el giro de Anthropic y Simon Willison

El renovado interés de Willison importa porque su crítica anterior reflejaba un alejamiento real de MCP entre los usuarios de agentes de programación.

MCP atrajo una intensa atención durante gran parte de 2025. Su propuesta de valor era fácil de entender: implementar una interfaz de servidor y exponer las mismas herramientas a varios clientes de IA compatibles.

Sin embargo, los agentes de programación mejoraban al mismo tiempo. Obtuvieron acceso fiable a terminales, un mejor uso de la shell y mayores capacidades para inspeccionar documentación. Muchos podían instalar una biblioteca o llamar a una API convencional con curl.

Eso generó un desafío directo. Un programa de línea de comandos bien documentado ya proporciona una interfaz de herramientas componible. El agente puede combinar comandos, redirigir la salida, escribir pequeños scripts e inspeccionar errores sin un adaptador de protocolo.

Skills reforzó esa vía. Una skill es un paquete de instrucciones, scripts y referencias que enseña a un agente a realizar una tarea. Puede explicar una API existente sin exigir a su propietario operar un servidor MCP.

Willison resumió su escepticismo en su análisis de 2025. Para los agentes de programación, prefería las utilidades de línea de comandos y las bibliotecas frente a MCP. Esas opciones otorgaban más libertad al modelo al tiempo que evitaban otra capa de servicio.

La crítica nunca fue que las llamadas estructuradas a herramientas carecieran de valor. La cuestión más difícil era si MCP aportaba suficiente valor adicional como para justificar sesiones, gestión de transporte, trabajo de compatibilidad de clientes y sobrecarga de contexto.

MCP sin estado reduce esa brecha. Una pequeña herramienta remota ahora puede comportarse más como un endpoint web convencional, al tiempo que conserva un contrato legible por máquina para los clientes de agentes.

El análisis de Willison sobre MCP sin estado vincula ese cambio con dos experimentos. El primero es mcp-explorer, pensado para facilitar la inspección y comprensión de servidores MCP. El segundo es datasette-mcp, que aplica el nuevo enfoque a Datasette.

Datasette es el sistema de código abierto de Willison para explorar y publicar datos estructurados. Ya expone bases de datos mediante interfaces web y APIs. MCP ofrece otra superficie diseñada específicamente para modelos de lenguaje que utilizan herramientas.

La combinación es ilustrativa. Un despliegue de Datasette es naturalmente remoto, estructurado y compartido entre usuarios. No encaja tan limpiamente en el modelo local de línea de comandos como una utilidad para desarrolladores instalada junto a un agente.

Un servidor MCP puede anunciar herramientas de base de datos mediante esquemas que los clientes comprenden. Los agentes pueden inspeccionar las operaciones disponibles antes de enviar consultas. Los operadores del servidor mantienen el control sobre autenticación, permisos, límites y detalles de implementación.

Esto hace que la comparación entre Anthropic y Simon sea más matizada que MCP frente a Skills. Una skill puede enseñar a un agente a consultar una API. MCP puede proporcionar a muchos clientes un contrato compartido para descubrir e invocar esa API.

Los dos enfoques también pueden funcionar juntos. Una skill puede describir cuándo usar un servidor MCP, explicar sus conceptos de dominio o proporcionar un flujo de trabajo que abarque varias herramientas. MCP puede gestionar el límite de ejecución remota.

Esta división reduce la presión sobre MCP para convertirse en la respuesta universal a cada acción de un agente. Los comandos locales pueden seguir siendo locales. Las bibliotecas pueden servir para tareas de programación flexibles. Skills puede empaquetar conocimiento operativo.

MCP obtiene un papel más claro allí donde el servidor controla la ejecución y varios clientes necesitan la misma interfaz detectable. Los datos empresariales, la búsqueda alojada, los servicios compartidos y los sistemas empresariales autenticados encajan en ese patrón.

Por ello, la simplicidad del protocolo cambia la cuestión competitiva. Los desarrolladores ya no necesitan preguntarse si cada herramienta merece un wrapper de MCP. Pueden preguntarse si una capacidad remota se beneficia de descubrimiento e invocación estandarizados.

Es una promesa menor que las interpretaciones iniciales más amplias de MCP. También es más creíble. Los estándares suelen resultar útiles cuando sus límites quedan más claros.

Las solicitudes sin estado hacen que MCP encaje en la infraestructura cloud convencional

MCP 2.0 importa porque elimina la coordinación especializada de la ruta de despliegue común.

La propuesta sin estado aceptada identifica tres problemas del antiguo modelo de inicialización. Las sesiones complicaban el escalado, debilitaban la recuperación ante fallos e incrementaban el trabajo de implementación en ambos lados.

Consideremos una herramienta de búsqueda remota ejecutándose en tres instancias de servidor. En un diseño orientado a sesiones, las llamadas posteriores podrían necesitar la misma instancia que procesó la inicialización. Un balanceador de carga básico de tipo round-robin no puede garantizar ese resultado.

Los operadores pueden resolver el problema mediante enrutamiento persistente. También pueden almacenar los datos de sesión en un servicio compartido. Ambos enfoques introducen estado operativo, modos de fallo adicionales y nuevos requisitos de monitorización.

Las sesiones persistentes pueden distribuir el trabajo de forma desigual. Los repositorios compartidos crean otra dependencia. Los reinicios de servidores pueden invalidar el estado local, mientras que los clientes deben detectar fallos y repetir la inicialización.

Con el nuevo modelo de solicitud, cualquier instancia en buen estado puede procesar una llamada a herramienta compatible. El gateway puede enrutar por método y metadatos de herramienta, en lugar de por historial de conexión.

Este cambio también hace más plausible el despliegue serverless. Las plataformas que inician y detienen instancias según la demanda funcionan mejor cuando las solicitudes no dependen de la memoria dejada por una solicitud anterior.

El servidor aún necesita almacenamiento duradero para un estado de aplicación que sea genuinamente duradero. MCP sin estado no elimina bases de datos, almacenes de objetos, workers de navegador ni colas de trabajos. Elimina la suposición de que el estado del protocolo debe acompañarlos.

Las operaciones de larga duración ahora se sitúan dentro de un modelo basado en extensiones. Un servidor puede devolver un manejador de tarea, mientras que el cliente posteriormente consulta, actualiza o cancela esa tarea mediante operaciones explícitas.

La distinción es importante. El estado oculto de sesión vincula un flujo de trabajo a una relación de transporte. Un manejador de tarea convierte el flujo de trabajo en un recurso direccionable que otros componentes autorizados pueden gestionar.

Las solicitudes de múltiples rondas abordan otro caso difícil. Algunas herramientas necesitan más información de un usuario o cliente antes de completarse. Las implementaciones anteriores asociaban ese intercambio con una sesión ya establecida.

El nuevo diseño permite una solicitud iniciada por el servidor únicamente mientras procesa una solicitud del cliente. Los datos de correlación viajan a través del ciclo de solicitud y respuesta, evitando una sesión de protocolo permanente.

Esto restringe ciertos comportamientos. Un servidor no puede contactar inesperadamente con un cliente mucho después de la llamada inicial. Ese límite reduce la flexibilidad, pero da a las indicaciones de usuario un origen y un ciclo de vida más claros.

El descubrimiento de herramientas también se vuelve más fácil de enrutar y almacenar en caché. La especificación añade metadatos de métodos y herramientas a las cabeceras HTTP. Las pasarelas pueden inspeccionar esos metadatos sin analizar cada cuerpo de solicitud.

Los servidores pueden adjuntar un valor de tiempo de vida a las respuestas de listado. Los clientes pueden reutilizar entonces la información de las herramientas dentro del periodo permitido, en lugar de solicitar la misma lista para cada subagente de corta duración.

La propuesta sin sesiones advierte que el comportamiento anterior podía generar tráfico repetido de descubrimiento proporcional al número de subagentes multiplicado por el de servidores. Las listas sin estado dan a los orquestadores una mejor base para evitar ese coste.

Esto importa a medida que los sistemas de agentes se vuelven más distribuidos. Una solicitud de usuario puede activar un planificador, varios trabajadores especializados y un verificador. Repetir la inicialización y el descubrimiento para cada rama añade latencia y tráfico.

El protocolo revisado también adopta el estándar completo JSON Schema 2020-12 para las definiciones de herramientas. JSON Schema es un vocabulario estándar para describir datos estructurados, incluidos campos obligatorios, tipos y reglas de validación.

Los esquemas más ricos pueden describir entradas y salidas más precisas. Esto proporciona a los clientes mejor información para validar llamadas y construir interfaces. También reduce la dependencia de descripciones de herramientas redactadas de forma imprecisa.

Las extensiones aportan otra forma de separación arquitectónica. MCP Apps puede proporcionar interfaces renderizadas por el servidor, mientras que Tasks gestiona operaciones más prolongadas. Estas funciones pueden evolucionar sin obligar a incluir todas las capacidades en el núcleo del protocolo.

Un ciclo de vida formal establece al menos 12 meses entre la deprecación de una función y su eliminación más temprana posible. Esto no elimina el trabajo de migración, pero ofrece a los implementadores una ventana de planificación más clara tras esta ruptura limpia.

La guía oficial de TypeScript muestra que la migración aún exige trabajo deliberado. La guía de migración del SDK afirma que el nuevo formato de comunicación requiere una adopción explícita, en lugar de modificar silenciosamente todas las aplicaciones existentes.

Esa cautela es apropiada. Una nueva especificación no puede crear interoperabilidad solo mediante su publicación. Los clientes, servidores, pasarelas y SDK deben implementar los mismos detalles y probarlos frente a cargas de trabajo reales.

Aun así, el mecanismo aborda una debilidad concreta. Sustituye la maquinaria de sesión específica de MCP por patrones que los equipos de nube ya utilizan para servicios HTTP convencionales.

El estado explícito plantea nuevas cuestiones de seguridad y fiabilidad

MCP sin estado elimina fricción de infraestructura, pero transfiere más responsabilidad al diseño de herramientas, la autorización y la memoria del agente.

Los identificadores explícitos hacen que el estado sea visible y portátil. Estos beneficios también amplían los lugares en que pueden aparecer identificadores sensibles. Un identificador puede acabar en historiales de chat, prompts, registros, trazas, contenidos del portapapeles o mensajes de subagentes.

Un servidor no debe tratar el conocimiento de un identificador como autorización suficiente. Debe validar tanto el identificador como la identidad autenticada en cada llamada.

Esto se parece al diseño utilizado por muchos servicios de documentos y proyectos. Un ID de recurso identifica un objeto, mientras que el contexto de autorización actual determina si quien llama puede leerlo o modificarlo.

Los servicios sin autenticación enfrentan un problema más difícil. En ese contexto, un identificador impredecible puede funcionar como un token de portador. Cualquiera que lo obtenga puede acceder al estado subyacente hasta que expire el identificador.

La especificación sin sesiones recomienda identificadores de alta entropía y duraciones limitadas para estos casos. Esa recomendación sigue siendo una guía de implementación porque MCP no define un tipo de identificador a nivel de protocolo.

Esto crea una brecha de aplicación. Los clientes no pueden reconocer automáticamente qué cadenas devueltas representan estado activo. Un browser_id parece cualquier otro valor salvo que los nombres y descripciones de las herramientas comuniquen su función.

Por tanto, un orquestador no siempre puede saber qué identificadores deben sobrevivir a la compresión de contexto. También puede tener dificultades para determinar qué valores requieren limpieza o nunca deben pasar a otro subagente.

Los modelos manejan habitualmente rutas de archivos, hashes de commits, URL e identificadores de transacciones. Aun así, pueden copiar un identificador de forma incorrecta, omitirlo o perderlo cuando se resume una conversación larga.

El estado de sesión tenía debilidades relacionadas. Los clientes utilizaban duraciones inconsistentes, y muchos no restauraban sesiones tras desconexiones. Eliminar las sesiones hace explícitos esos problemas, pero no automatiza la gestión del estado.

La limpieza plantea otro detalle sin resolver. El final de una sesión antes ofrecía una señal teórica para liberar recursos. En la práctica, los clientes a menudo terminaban sesiones con demasiada frecuencia, demasiado tarde o tras una recarga de página no relacionada.

Los flujos de trabajo explícitos necesitan sus propias políticas de expiración y destrucción. Un servicio de navegador podría ofrecer close_browser y, al mismo tiempo, aplicar un tiempo de espera por inactividad. Un servicio de tareas podría conservar los resultados completados durante un periodo definido.

La compatibilidad con versiones anteriores añade complejidad operativa durante la adopción. Los servidores existentes que dependen de IDs de sesión no pueden simplemente aceptar la nueva revisión del protocolo sin cambiar su modelo de estado.

Los clientes y SDK pueden negociar una revisión anterior cuando sea necesario. Esto permite una migración gradual, pero también crea dos rutas de comportamiento que los desarrolladores deben probar.

Algunas capacidades se vuelven menos directas bajo HTTP sin estado. Las notificaciones no solicitadas y las interacciones prolongadas impulsadas por el servidor no encajan de forma tan natural en solicitudes independientes. Las extensiones y los mecanismos de escucha deben asumir ese trabajo.

Tampoco hay garantía de que todas las integraciones de MCP se vuelvan eficientes simplemente porque desaparezcan las sesiones. Los esquemas mal diseñados pueden consumir contexto. Los catálogos grandes de herramientas pueden confundir a los modelos. Las descripciones poco claras aún pueden provocar llamadas incorrectas.

Las Skills y las herramientas de línea de comandos conservan aquí sus ventajas. Un agente de programación puede a menudo inspeccionar la salida de ayuda de un programa y escribir un script breve sin cargar un gran catálogo remoto de herramientas.

Las herramientas locales también pueden mantener datos sensibles en la máquina del usuario. Una implementación remota de MCP introduce preocupaciones de autenticación, exposición de red, registro y disponibilidad del servicio que la ejecución local evita.

MCP tampoco resuelve la inyección de prompts. Un agente con herramientas habilitadas puede combinar información privada, entradas no confiables y comunicación externa independientemente de que el transporte tenga estado.

Los operadores de servidores deben limitar permisos y salidas. Quienes construyen agentes deben controlar qué herramientas aparecen juntas. Los usuarios necesitan límites de aprobación claros para acciones importantes.

Estas restricciones cuestionan la interpretación más fuerte del giro de Anthropic y Simon Willison. El renovado interés de Willison valida el cambio arquitectónico, no cada implementación de MCP ni cada servidor propuesto.

mcp-explorer y datasette-mcp son experimentos iniciales útiles porque exponen cuestiones prácticas. ¿Pueden los clientes descubrir herramientas de forma consistente? ¿Son comprensibles los esquemas? ¿Sobreviven la autenticación y los identificadores de estado a flujos de trabajo reales?

El argumento más sólido para MCP sin estado vendrá de la evidencia de interoperabilidad. Clientes independientes deberían conectarse a servidores independientes sin parches personalizados, mientras que los operadores deberían desplegarlos utilizando infraestructura convencional.

Hasta que esa evidencia aumente, MCP 2.0 seguirá siendo una mejor base, no una victoria consumada. El protocolo ha eliminado una fuente importante de fricción. Los implementadores aún determinan si los sistemas resultantes siguen siendo seguros y comprensibles.

Qué deberían vigilar los desarrolladores después de MCP 2.0

La próxima prueba es la adopción en SDK, servidores y clientes reales, no otro aumento de recuentos de repositorios.

La primera señal es la cobertura de implementación de la revisión 2026-07-28. Los SDK oficiales necesitan soporte consistente para descubrimiento, metadatos por solicitud, capacidades explícitas, Tasks y comportamiento de autorización.

Las etiquetas de versión por sí solas no bastarán. Los desarrolladores deberían vigilar los resultados de conformidad y las pruebas entre lenguajes. Un servidor Python, un cliente TypeScript y una pasarela gestionada deberían coincidir en las mismas solicitudes y errores.

Una sólida compatibilidad entre SDK reforzaría la idea de que MCP ahora ofrece un límite estable para herramientas remotas. Desajustes persistentes la debilitarían al devolver a los desarrolladores a adaptadores específicos de cada cliente.

La segunda señal es cómo los servidores de producción migran flujos de trabajo con estado. La automatización de navegadores, las transacciones, los carritos de compra y los trabajos de investigación prolongados ofrecen pruebas exigentes para los identificadores explícitos.

Las migraciones exitosas deberían mostrar limpieza fiable, autorización por solicitud, transferencia de identificadores y compresión de contexto. También deberían documentar qué ocurre cuando un agente pierde o repite un identificador.

Si estos patrones se vuelven reutilizables, el estado explícito parecerá una abstracción mejor que las sesiones ambiguas. Si cada servidor inventa reglas de ciclo de vida incompatibles, el protocolo habrá desplazado la complejidad en lugar de reducirla.

La tercera señal es la relación entre MCP y Skills. Las plataformas de agentes deberían demostrar cuándo eligen un comando local, una llamada API guiada por una skill o un servidor MCP remoto.

Reglas de selección claras reforzarían la tesis más limitada. MCP serviría para capacidades remotas compartidas, mientras que Skills empaquetaría instrucciones y flujos de trabajo locales.

La superposición continua podría crear mantenimiento duplicado. Los propietarios de herramientas podrían necesitar una API, una CLI, un paquete de skills, un servidor MCP y una integración específica de cliente para la misma capacidad.

Los desarrolladores deberían resistirse a tratar esa duplicación como inevitable. Una skill puede hacer referencia a un servidor MCP, y un servidor MCP puede envolver una API existente. La pregunta útil es qué interfaz posee el contrato duradero.

Para las herramientas de datos, los experimentos de Willison ofrecen un lugar concreto que vigilar. Datasette ya sirve información estructurada mediante API web. datasette-mcp puede probar si un contrato centrado en agentes mejora el descubrimiento y las consultas seguras.

Los equipos que crean flujos de trabajo de conocimiento enfrentan una elección similar. Los documentos y notas locales suelen encajar en una base de conocimiento de ingeniería privada y consultable. Los sistemas empresariales compartidos pueden encajar mejor en herramientas remotas autenticadas.

La clave es evitar conceder a un agente una colección sin restricciones de herramientas simplemente porque un protocolo común facilita la conexión. La estandarización reduce el trabajo de integración, pero no sustituye el diseño de permisos.

El giro de Anthropic y Simon Willison es valioso porque sigue a un periodo de escepticismo genuino. MCP no recuperó atención mediante marca. Sus responsables eliminaron una carga estructural que los críticos podían señalar en sistemas desplegados.

Así es como debería evolucionar un protocolo. Debería incorporar la evidencia de supuestos fallidos, acotar sus responsabilidades y facilitar el razonamiento sobre operaciones comunes.

Durante los próximos tres meses, inspecciona los clientes y servidores que realmente utilizas. Comprueba si admiten la revisión final, cómo representan el estado de la aplicación y si su autorización acompaña a cada identificador.

Luego compara el resultado con la alternativa más sencilla. Si un comando local sigue siendo más claro, consérvalo. Si muchos agentes necesitan una capacidad remota gobernada, prueba MCP sin estado y registra dónde sigue fallando la interoperabilidad.