Conclusión primero: una vez un Skill corre sobre MCP, el procedimiento puede seguir siendo Markdown. El contrato de descubrimiento sigue siendo JSON. El 16 de septiembre de 2026, Tommaso Stocchi de Microsoft Agent Framework publicó una comparativa: un asesor de estación de esquí pasó de «cada especialista ejecuta su propio modelo» a «el padre carga un Skill bajo demanda y luego llama a las herramientas MCP en directo». Los servicios siguen distribuidos. El razonamiento pasa al contexto del padre. El artículo del 11 de septiembre de este sitio sobre MCP / Skills / Tools / Subagents cubrió las cuatro capas. Este artículo solo añade lo que ocurrió después de esa fecha: cómo se ve el documento de descubrimiento, dónde está de verdad SEP-2640, y por qué sigues comprobando primero un archivo JSON.
Escrito a fecha de 22 de septiembre de 2026. SEP-2640 (la Skills Extension) se marcó Accepted el 3 de septiembre. No es Final. La demo de Microsoft clava un Draft histórico de skill://index.json. El draft más nuevo usa skills/list y skills/get. Hay dos formas de descubrimiento en el campo. La compatibilidad es una mejor primera pregunta que «¿los Skills sustituyeron a los Agents?».
Qué se publicó de verdad el 16 de septiembre
El post de Stocchi se titula From Specialist Agents to Distributed Skills over MCP. El asesor de estación de esquí solía llamar a cuatro especialistas por A2A: weather, safety, ski coaching, lift traffic. Cada especialista era dueño de instrucciones, herramientas y un bucle de modelo. El segundo camino convierte los mismos servicios de dominio en MCP providers: cada uno publica una descripción, un SKILL.md y herramientas MCP tipadas. El asesor usa el SkillsProvider y el MCPSkillsSource de MAF para descubrimiento y carga. SkillToolsMiddleware cuelga las herramientas de ese provider en el siguiente turno del modelo después de que load_skill tenga éxito.
La investigación web sigue siendo una herramienta de Agent ordinaria. El híbrido es deliberado: deja la autonomía donde la necesitas; convierte una competencia acotada en un Skill. Los cuatro endpoints MCP viven en /skillsmcp. La superficie de resources suele ser solo:
skill://index.json
skill://<skill-name>/SKILL.mdskill:// nombra un resource en una conexión MCP ya configurada. No es un hostname, y la prosa del Skill no debe abrir un salto de red nuevo. Autenticación, transporte y autorización se quedan en infraestructura y código, no en Markdown.
Esto no es MCP sustituyendo a A2A
El original traza una línea limpia. A2A entrega una tarea a otro razonador. Un Distributed Skill entrega una competencia y sus operaciones al razonador actual. Una tabla basta:
| Qué importa | Agent como herramienta (A2A) | Distributed Skill |
|---|---|---|
| Qué descubre el padre | Un Agent especialista al que puede llamar | Una competencia que puede cargar |
| Dónde corren las instrucciones del especialista | El contexto de modelo del especialista | El contexto de modelo del padre |
| Quién elige las operaciones de dominio | El modelo especialista | El modelo padre |
| Qué corre en remoto | Un bucle especialista y sus herramientas | Herramientas MCP y los servicios de detrás |
| Qué sigue distribuido | Agents, servicios, datos | Skill providers, servicios, datos |
El nombre y la descripción del Agent Card se convierten en una entrada de descubrimiento. El system prompt se convierte en SKILL.md. Los parámetros de herramientas se convierten en schemas de input / output de MCP. Los servicios de negocio se quedan detrás de los handlers de herramientas. Endpoint, auth y transporte de la Card no pertenecen a la descripción del Skill. Eso coincide con el artículo del 11 de septiembre: Skills son el procedimiento, MCP es el enchufe, Tools son el contrato. Lo que cambió es cómo se descubre el procedimiento — no un colapso de las tres capas en una.
El contrato de descubrimiento: skill://index.json
Un orquestador no necesita cada procedimiento en cada petición. Necesita un directorio lo bastante bueno para enrutar. El índice del weather provider en la demo es:
{
"$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
"skills": [
{
"name": "weather",
"type": "skill-md",
"description": "Weather intelligence agent providing real-time conditions, forecasts, and storm alerts for the ski resort",
"url": "skill://weather/SKILL.md"
}
]
}Este es el índice de descubrimiento de Agent Skills con semántica MCP: url es un URI de resource, no un host https. $schema apunta a discovery 0.2.0 en schemas.agentskills.io. La descripción responde cuándo usar la competencia. SKILL.md responde cómo — nombra operaciones como weather_forecast, rangos, unidades y una prohibición de inventar observaciones. Los tipos y límites de esas operaciones siguen viniendo del JSON Schema en MCP tools/list.
Al arrancar, el padre tira del catálogo y de tools/list por MCP. El modelo primero ve resúmenes de Skill y ayudantes de carga, no cada schema de operación. Después de load_skill("weather"), el middleware cuelga ese grupo. Que una herramienta aparezca en el contexto no es una ejecución.
SEP-2640: Accepted, no Final
SEP-2640 es el binding de Skills en el Extensions Track: servir Agent Skills a través de MCP Resources. El id de la extensión es io.modelcontextprotocol/skills. El layout de directorio, el YAML frontmatter y la divulgación progresiva se quedan con la spec de Agent Skills. El SEP solo fija el transporte.
Según la comprobación del 10 de septiembre en el post de Stocchi: la revisión del 3 de septiembre marcó Accepted y movió el descubrimiento a skills/list y skills/get (paginado; las entradas llevan uri, frontmatter parseado y un manifiesto de resources con digests sha256:). El PR correspondiente seguía abierto. La demo clava un Draft anterior: lee skill://index.json y no implementa los métodos nuevos. El repo de incubación sigue Experimental.
No escribas un «Final el 13 de septiembre» de segunda mano en una checklist de producción. Lo sólido el 22 de septiembre de 2026: Accepted, no Final, dos formas de descubrimiento en uso. Tratar el índice Draft como un requisito MCP de núcleo contradice la nota al pie del propio post.
El contrato de herramientas sigue siendo JSON Schema
El forecast de la demo toma hours con Range(1, 24) y UseStructuredContent. El SDK publica la definición de la herramienta. El handler valida el rango y luego llama al servicio de dominio. SKILL.md guía qué herramienta elegir. No sustituye el schema de parámetros ni las comprobaciones en el server.
Las operaciones autoritativas vienen de tools/list. La ejecución es tools/call. Las instrucciones son resources/read. Los tres saltos son JSON-RPC. Un Skill puede decir «pagina»; no puede persistir tu cursor. Puede mencionar un paso de aprobación; no puede imponer autorización. Es la misma capa que por qué Tool Calling depende de JSON Schema: la prosa elige un camino, el contrato rechaza arguments ilegales.
Tres pares de ejecuciones: más rápido, no más barato en tokens
El mismo prompt («teniendo en cuenta el tiempo y la espera, ¿por dónde debería empezar?»), la misma app Aspire, gpt41, tres conversaciones nuevas. El camino A2A usó 6 / 6 / 7 llamadas al modelo (los especialistas pueden solaparse). El camino Skills usó 3 cada vez: load_skill, luego operaciones MCP directas, luego la respuesta final. La media de wall-clock del cliente fue unos 6,35 s frente a 15,48 s.
Los tokens no bajaron. En tres ejecuciones el lado Skills observó unos 13.533 frente a unos 11.134 de A2A — más o menos un 22% más. Menos saltos de modelo no son un contexto acumulado más pequeño: instrucciones, schemas de grupo y resultados se apilan en las tres llamadas. Los contadores de caché de A2A estaban incompletos. Esto no es una factura, y no es un estudio controlado. El original lo dice: tres pares, no prueba de igual corrección o completitud.
La observación estructural es una frase: lo que sueltas es el bucle especialista anidado, no las idas y vueltas JSON. Los índices de descubrimiento, los schemas de herramientas y los resultados estructurados siguen saltando. Solo viven como unos pocos contratos en el contexto del padre en lugar de un discurso de cada especialista.
Dos formas de descubrimiento, hosts que no se ven
La grieta ya se veía en agosto–septiembre de 2026. UseMcpSkills en Microsoft.Agents.AI.Mcp sigue leyendo skill://index.json. Un server que solo implementa skills/list recibe «no index resource». Un server que solo envía el índice, sin la declaración de extensión ni digests, es invisible para un host más nuevo. Algunos hosts ya marcan los servers basados en índice como legacy.
No apuestes a un ganador. Para un catálogo pequeño, sirve ambos: un índice Draft para clientes antiguos, skills/list / skills/get para hosts que declaran la extensión. Un listado ausente o vacío no debe tratarse como «este server no tiene skills» — el draft permite enumeración parcial para catálogos grandes o generados.
Tres documentos JSON que sigues comprobando en local
- El documento de descubrimiento. Entradas de
skill://index.jsonoskills/list:name,type,description,url/uri. Compruébalas contra$schema. Claves de más, descripciones vacías o un host https enurlson bugs de enrutado, no retoques de copy. - Schemas de herramientas. Toma
inputSchemadetools/list. Rellena required, ponadditionalProperties: false, estrecha enums y rangos. Los nombres que menciona la prosa del Skill tienen que coincidir con la lista. - Resultados estructurados. La demo activa Structured Content. El output de vuelta al padre debería seguir siendo JSON legal, y luego comprobarse contra un schema. No devuelvas una fila entera de la base de datos ni un stack. Ver por qué los agentes necesitan más JSON después de la Agents API.
Inspecciona el documento de descubrimiento con herramientas JSON locales
Antes de cablear MAF o cualquier host, extiende tres textos en el navegador: el índice de descubrimiento, un schema de tools/list y un objeto arguments de muestra de tools/call.
- Validador JSON — ¿es legal la gramática? Si tienes un schema, comprueba campos, required y claves de más juntos.
- Formateador JSON — expande un índice de una línea y mira si
urles de verdadskill://. - JSON Diff — compara una entrada de índice Draft con una entrada de
skills/listpara que los dos catálogos no diverjan.
Nada sale del navegador. Estabiliza el contrato de descubrimiento y luego deja que el padre cargue SKILL.md. El procedimiento puede cambiar el wording. Los nombres de campo y los URI no deberían moverse cada semana.
FAQ
¿SEP-2640 es ya Final?
No. La revisión del 3 de septiembre es Accepted. La comprobación del 10 de septiembre de Stocchi aún tenía un PR abierto. La demo usa un Draft histórico de skill://index.json. No tires clientes antiguos por un relato de «ya es Final».
¿Sustituirán los Distributed Skills a A2A?
No como regla general. Quédate con un Agent cuando necesites un ciclo de vida independiente, contexto privado o un modelo especializado. Migra a un Skill cuando solo necesites un procedimiento más operaciones. Dejar la investigación web como herramienta de Agent es esa distinción.
¿Es skill:// una URL que el host debería resolver?
No. Nombra un resource en una conexión MCP ya configurada. La prosa del Skill no debe usarlo para abrir otro host.
Si tengo SKILL.md, ¿sigo necesitando JSON Schema?
Sí. Markdown guía la elección de herramienta y cómo leer los resultados. Tipos, rangos y campos required siguen viniendo del schema de tools/list y de una comprobación que ejecutas tú.
¿Basta skill://index.json por sí solo?
Para algunos clientes Microsoft actuales, sí. Para hosts del draft más nuevo, no. Sirve ambos en un catálogo pequeño. Una sola forma es invisible para la otra mitad del campo.
¿Es más barato el camino Skills?
En la demo, el wall-clock fue más rápido y los tokens observados unos 22% más altos. No es un estudio controlado. Compara primero el enrutado y los resultados estructurados, luego la factura.
Resumen
La demo del 16 de septiembre no anunció que los agents estén obsoletos. Anunció que una competencia que no necesita razonamiento anidado puede enviar un procedimiento y operaciones, con una superficie de descubrimiento JSON. Los límites de servicio se quedan. Lo que sueltas es el bucle de modelo especialista. Lo que sigues teniendo es el índice de descubrimiento, el schema de herramientas y el resultado estructurado.
SEP-2640 sigue Accepted. El índice Draft y skills/list vivirán juntos un tiempo. Aplana los tres documentos JSON en un validador local antes de entregarlos a un host. El apilado del 11 de septiembre se sostiene. Lo que ya no se sostiene es «un Skill es solo una carpeta en disco». Los modelos y harnesses tomarán versiones nuevas. name, url e inputSchema no deberían aflojarse con ellos.