Qué pueden hacer los desarrolladores de GitHub antes de que la especificación de MCP quede final el 28 de julio

La candidata a lanzamiento de MCP salió el 21 de mayo y la especificación queda final el 28 de julio. La mejor preparación no es esperar un post de lanzamiento. Es dejar tu repo listo para agentes desde ya.

La siguiente versión de la especificación de MCP queda final el 28 de julio. La candidata a lanzamiento no está por llegar; ya está aquí. Lo más útil que puedes hacer en estas dos semanas no es esperar un post de lanzamiento.

Es preparar tu repo.

Mucho contenido sobre MCP empieza por el protocolo: qué es, cómo hablan los clientes y los servidores, y por qué importa el tool calling. Es contexto útil. Pero si estás construyendo con agentes dentro de flujos de trabajo de GitHub, la pregunta práctica es más pequeña:

¿Qué haría que este repo fuera más fácil, más seguro y más predecible para que un agente trabaje en él?

Yo empezaría por ahí.

Qué es lo que realmente sale

La versión 7-28 de MCP es la revisión más grande del protocolo desde que nació, y trae cambios incompatibles.

El handshake de initialize ya no está. Las sesiones a nivel de protocolo ya no están. Cualquier solicitud puede llegar a cualquier instancia del servidor detrás de un balanceador de carga común. Las extensiones ahora son de primera clase, y las dos primeras extensiones oficiales cubren MCP Apps para UI renderizada por el servidor y Tasks para trabajo de larga duración. La autorización se acerca más a cómo se despliegan OAuth y OpenID Connect en el mundo real. Roots, sampling y logging quedan deprecados. También hay una política formal de ciclo de vida, lo que significa que las futuras versiones no deberían romper tu código sin al menos doce meses de aviso de deprecación.

Si ya publicas un servidor MCP, ese párrafo es tu lista de pendientes. Lee el changelog en borrador, prueba tu servidor contra las betas de los SDK, y planea la migración ahora. Si construiste sobre la API experimental de Tasks de 2025-11-25, esa migración no es opcional.

El cambio que vale la pena mirar

MCP se ha convertido en una de las señales más claras de que el desarrollo con agentes está pasando de demos aisladas a infraestructura de desarrollo repetible.

Lo interesante no es solo que un agente pueda llamar una herramienta. El protocolo está formalizando cómo se describen las herramientas, cómo pasa el contexto, cómo funcionan los permisos y cómo se verifica el comportamiento. Una propuesta de especificación ya no puede llegar a estado Final sin un escenario correspondiente en la suite de conformidad. Así se ve una infraestructura cuando madura.

Esto importa para desarrolladores de GitHub porque casi todo trabajo con agentes termina tocando la misma superficie: repos, issues, pull requests, CI, documentación, límites de autenticación y expectativas de quienes mantienen el proyecto.

Si el 28 de julio es el momento en que más desarrolladores empiezan a tomar MCP en serio, la mejor preparación es hacer que tu proyecto sea más legible para agentes desde ahora.

Qué probar antes del 28 de julio

Empieza por las instrucciones de tu repo.

Si tu proyecto todavía no tiene un AGENTS.md, escribe uno. Es Markdown plano, más de 60.000 proyectos de código abierto ya lo usan y más de 30 agentes de código lo leen.

Hazlo práctico. Diles a los agentes cómo construir, probar, pasar lint y navegar el repo. Incluye las convenciones que una persona que mantiene el proyecto normalmente explicaría en un comentario de revisión: dónde vive el código fuente, qué comandos se pueden correr sin riesgo, qué no tocar y cómo validar los cambios. GitHub revisó miles de archivos AGENTS.md y encontró que los mejores dan comandos exactos, listos para copiar y pegar, con flags. No “corre los tests”.

Luego elige un flujo de trabajo donde una herramienta de verdad ayude. No diez herramientas. Una.

Los buenos primeros candidatos son repetibles y de bajo riesgo: buscar en la documentación, revisar metadata de paquetes, validar configuración, correr un comando de pruebas conocido o resumir un issue contra las guías del repo. No estás tratando de volver autónomo al agente. Estás tratando de hacer una interacción lo bastante explícita para que otra persona la entienda y la pueda reproducir.

De ahí, define el límite de confianza.

¿Qué puede leer la herramienta? ¿Qué puede escribir? ¿Necesita credenciales? ¿Qué pasa cuando falla? Si la respuesta es “el agente lo resolverá”, el contrato todavía no está claro. La nueva especificación te ayuda a mitad de camino. El endurecimiento de autorización de MCP 7-28 asume que sabes qué puede tocar cada herramienta. Los equipos que lo hayan dejado por escrito lo adoptarán más rápido que quienes estén reconstruyendo sus propios permisos sobre la marcha.

Una checklist sencilla para dejar el repo listo

Antes de que la especificación quede final, pregúntate:

¿Puede una persona nueva entender cómo debería trabajar un agente en este repo?
¿Los comandos de build, tests y lint están documentados con claridad y con flags exactos?
¿Hay un flujo de trabajo realista que podría convertirse en una herramienta MCP?
¿Las entradas y salidas están explícitas?
¿Los permisos y los modos de fallo están documentados?
¿Esto se podría probar en CI sin basarse en corazonadas?

La última importa. Los flujos de trabajo con agentes no estarán listos para producción porque suenen impresionantes. Serán útiles cuando los equipos puedan inspeccionarlos, acotarlos y probarlos.

Si prefieres hacerle seguimiento en vez de leerla, aquí está la misma checklist en versión interactiva. Guarda tu progreso en el navegador, enlaza cada elemento de servidor con la documentación relevante de la especificación y lo copia a Markdown para que puedas abrirlo como un issue en tu repo.

Descarga la checklist imprimible de preparación del repo (PDF)

Haz el trabajo aburrido ahora

La siguiente fase del desarrollo con agentes no va solamente de modelos más inteligentes. Va de mejores interfaces entre los modelos y los sistemas que los desarrolladores ya usan.

Para los proyectos de GitHub, eso significa que el trabajo aburrido de repente importa: instrucciones del repo, esquemas de herramientas, límites de permisos, ejemplos y tests.

Eso es buena noticia. No tienes que esperar al 28 de julio para empezar. Puedes hacer que tu proyecto sea más fácil de usar para agentes y personas desde hoy.

Cuando la especificación quede final, los equipos que más le saquen provecho serán los que ya saben qué quieren que hagan sus agentes, dónde están los límites y cómo sabrán si funcionó.