MCP 2.0: el cambio a stateless que vuelve a poner al protocolo en juego

Si te movés en el mundo de los agentes de IA, en algún momento de los últimos meses probablemente escuchaste que MCP había muerto. Skills, terminales con curl, general agents como Claude Code o Codex: todas estas alternativas parecían dejar al Model Context Protocol como una curiosidad del 2025. Y la verdad es que el razonamiento tenía sentido: darle a un agente un shell con acceso a internet es terriblemente flexible, y encima ya viene integrado.

Pero hay un problema. Esa misma flexibilidad hace que sea casi imposible auditar qué puede hacer tu agente y qué puede salir mal. Ahí es donde entra MCP 2.0, la revisión publicada el 28 de julio de 2026 que, según Simon Willison (que volvió a prestarle atención esta semana tras meses de entusiasmo moderado), representa el cambio más grande del protocolo desde su lanzamiento.

La palabra clave es stateless.

Si todavía no tenés claro qué es MCP, te recomiendo arrancar por MCP-el-puente-entre-la-ia-y-tus-datos antes de seguir. Acá asumo que ya sabés lo básico y vamos directo a lo nuevo.

Por qué parecía que MCP se había estancado

Cuando Anthropic liberó el protocolo a fines de 2024, la idea era potente: un estándar abierto para que cualquier developer expusiera herramientas a un LLM, igual que USB-C estandarizó los cables. La comunidad se movió rápido, aparecieron decenas de servidores MCP y durante buena parte del 2025 fue la forma default de darle “manos” a un agente.

Después, tres cosas pasaron al mismo tiempo:

1. Los general agents maduraron. Modelos como Claude Sonnet 4.5 y GPT-5.6 aprendieron a manejar un shell con criterio: leer errores, encadenar comandos, decidir cuándo parar.
2. Aparecieron los Skills. Otra idea de Anthropic, más liviana: en lugar de hablar un protocolo de sesión, el agente simplemente lee un archivo SKILL.md y ya sabe qué hacer.
3. El viejo MCP se sintió pesado. Servidores y clientes tenían que mantener un Mcp-Session-Id, hacer dos rondas HTTP por cada llamada, y coordinar estado entre procesos. Bastante fricción para algo que, en la práctica, termina exponiendo tres o cuatro tools.

El resultado fue un 2026 tibio para MCP. No murió, pero tampoco avanzaba.

Qué cambia con la especificación 2026-07-28

El cambio central de MCP 2.0 es radical y simple: eliminar el estado de sesión. La nueva spec propone que cada request HTTP sea autocontenido, igual que un REST bien hecho. Mirá la diferencia.

El “legacy MCP” (stateful)

Para invocar una herramienta, el cliente tenía que hacer dos pedidos HTTP:

1. Inicializar la sesión. Pedir un Mcp-Session-Id y guardarlo.
2. Llamar a la tool. Pasar ese ID en cada request.

Esto parece poco, pero implica que el servidor tiene que recordar qué sesión está activa, qué capacidades negoció, qué estado intermedio dejó en la tool. En producción, eso es mantener memoria distribuida: load balancers que manden el mismo request al mismo backend, gestión de expiraciones, limpieza de sesiones colgadas.

El nuevo MCP (stateless)

Ahora un solo request HTTP lleva todo lo necesario: nombre de la tool, argumentos, y listo. El servidor no guarda nada entre llamadas. Si lo pensás, esto es exactamente lo que necesitan la mayoría de las herramientas “leer base de datos”, “consultar Jira”, “buscar en Notion”. No necesitan mantener conversación con el cliente.

En código, la diferencia se ve así (pseudocódigo del propio spec):

# Legacy MCP — dos requests
POST /mcp/initialize
  → { "sessionId": "abc-123" }
POST /mcp/tools/call
  Headers: { "Mcp-Session-Id": "abc-123" }
  Body: { "tool": "execute_sql", "args": {...} }

# Stateless MCP 2.0 — un solo request
POST /mcp
  Body: { "tool": "execute_sql", "args": {...} }

Más simple para el cliente, más simple para el servidor, y mucho más fácil de escalar o de poner detrás de un CDN sin pensar dos veces.

Por qué esto importa para los developers

Más allá de la limpieza técnica, el cambio resucita a MCP por razones muy concretas:

• Auditoría. Cuando un agente solo puede ejecutar tools específicas (no comandos arbitrarios de shell), podés razonar sobre qué puede salir mal. Eso es lo que se está perdiendo con los general agents abiertos.
• Modelos más chicos pueden participar. No necesitás un frontier model que pilote un shell. Con MCP 2.0, un modelo de 8B corriendose local con [Ollama](como vimos en como-usar-ollama-para-correr-llms-localmente) puede levantar un agente perfectamente capaz, porque las tools son simples y estructuradas.
• Menos infraestructura. Sin sesiones que persistir, podés hostear servidores MCP en Vercel, Cloudflare Workers o cualquier serverless. Son funciones idempotentes, casi.

La flexibilidad extrema de un shell + curl es lo que hace a los general agents difíciles de asegurar. MCP 2.0 vuelve a poner el dial cerca de “auditable” sin perder demasiada potencia.

Probalo en cinco minutos con mcp-explorer

Lo más lindo del nuevo spec es que ya hay tooling concreto para jugar. Simon Willison se construyó mcp-explorer (un CLI Python liviano) esta misma semana, y corre con [uv](la herramienta que cubrimos en uv-0-12-el-gestor-de-python-que-ya-supero-a-pip) sin instalar nada:

uvx mcp-explorer list https://agentic-mermaid.dev/mcp

Te lista las tools que expone ese servidor (en el ejemplo, herramientas para generar diagramas Mermaid con IA). Después podés inspeccionar el esquema de una tool puntual:

uvx mcp-explorer inspect https://agentic-mermaid.dev/mcp render_mermaid

Y finalmente invocarla con argumentos:

uvx mcp-explorer call https://agentic-mermaid.dev/mcp render_mermaid \
  --input '{"description": "arquitectura de un agente MCP"}'

Lo genial es que no necesitás clonar nada ni configurar un entorno virtual. El CLI es stateless y uvx se encarga de todo. Es la mejor forma de entender qué hay del otro lado del cable antes de comprometerte con una integración.

Un caso real: datasette-mcp

El otro proyecto que apareció con la nueva spec es datasette-mcp, un plugin para Datasette que agrega un endpoint /-/mcp a cualquier instancia. Exponer tu base de datos SQLite a un agente pasa de ser un fin de semana de código a esto:

pip install datasette-mcp
datasette serve mi-base.db --load-extension=datasette-mcp

Y listo: tu instancia ahora ofrece tres tools (list_databases, get_database_schema, execute_sql) que cualquier cliente MCP 2.0 puede consumir. Probalo contra ChatGPT o Claude y vas a ver al agente encadenando queries reales sobre tus datos, sin que le hayas dado acceso al filesystem ni un ápice.

Ahí está la promesa del cambio: menos superficie de ataque, menos ceremonia, más interoperabilidad.

¿Con qué te quedás: MCP 2.0, Skills o shell abierto?

Después de leer todo esto, la pregunta razonable es: ¿cuándo uso cada cosa? Mi regla mental hoy:

• MCP 2.0 cuando querés que un agente use una tool bien definida y específica. Lectura de DB, búsquedas, operaciones sobre una API cerrada. Caso default.
• Skills cuando el agente necesita un playbook procedural con varios pasos documentados. Estilo “cómo hacer deploy de mi app”, con guía humana en el medio.
• Shell + curl cuando el problema es genuinamente abierto y muy exploratorio. Análisis de logs raros, debugging de un sistema desconocido, código legacy sin documentación. Reservalo para los casos donde el riesgo está justificado, y andá con cuidado.

Los tres se pueden combinar, no son mutuamente excluyentes. Pero el hecho de que MCP vuelva a tener una propuesta técnica sólida — más simple, más auditable, más fácil de hostear — me parece la mejor noticia de julio en el mundo de los agentes.

---

Fuentes y enlaces útiles:

• Stateless MCP has recaptured my interest — análisis técnico completo de Simon Willison
• mcp-explorer — CLI Python para inspeccionar servidores MCP
• Especificación oficial 2026-07-28 del Model Context Protocol