Conclusão primeiro: quando um Skill sobe no MCP, o procedimento pode continuar em Markdown. O contrato de descoberta continua sendo JSON. Em 16 de setembro de 2026, Tommaso Stocchi do Microsoft Agent Framework publicou um lado a lado: um consultor de estação de esqui saiu de «cada especialista roda o próprio modelo» para «o pai carrega um Skill sob demanda e depois chama tools MCP direto». Os serviços continuam distribuídos. O raciocínio vai para o contexto do pai. Este site já tem, em 11 de setembro, o texto sobre MCP / Skills / Tools / Subagents cobrindo as quatro camadas. Este texto só acrescenta o que aconteceu depois dessa data: como é o documento de descoberta, onde o SEP-2640 de fato está, e por que você ainda checa um arquivo JSON primeiro.
Escrito em 22 de setembro de 2026. O SEP-2640 (a Skills Extension) foi marcado Accepted em 3 de setembro. Não é Final. A demo da Microsoft trava num Draft histórico de skill://index.json. O Draft mais novo usa skills/list e skills/get. Dois formatos de descoberta estão no campo. Compatibilidade é uma pergunta melhor para começar do que «os Skills substituíram os Agents».
O que de fato saiu em 16 de setembro
O post de Stocchi se chama From Specialist Agents to Distributed Skills over MCP. O consultor da estação de esqui chamava quatro especialistas via A2A: clima, segurança, aula de esqui, fila do teleférico. Cada especialista era dono das instruções, das tools e de um loop de modelo. O segundo caminho transforma os mesmos serviços de domínio em providers MCP: cada um publica uma description, um SKILL.md e tools MCP tipadas. O consultor usa o SkillsProvider e o MCPSkillsSource do MAF para descoberta e carregamento. O SkillToolsMiddleware anexa as tools daquele provider ao próximo turno do modelo depois que load_skill dá certo.
Pesquisa na web continua sendo uma tool comum de agent. O híbrido é de propósito: mantenha autonomia onde você precisa; transforme uma competência delimitada num Skill. Os quatro endpoints MCP moram em /skillsmcp. A superfície de recursos em geral é só:
skill://index.json
skill://<skill-name>/SKILL.mdskill:// nomeia um recurso numa conexão MCP já configurada. Não é um hostname, e a prosa do Skill não deve abrir um salto de rede novo. Autenticação, transporte e autorização ficam na infraestrutura e no código, não no Markdown.
Isto não é o MCP substituindo o A2A
O original desenha uma linha limpa. A2A entrega uma tarefa a outro raciocinador. Um Distributed Skill entrega uma competência e as operações dela ao raciocinador atual. Uma tabela basta:
| O que importa | Agent como tool (A2A) | Distributed Skill |
|---|---|---|
| O que o pai descobre | Um agent especialista que ele pode chamar | Uma competência que ele pode carregar |
| Onde as instruções do especialista rodam | O contexto de modelo do especialista | O contexto de modelo do pai |
| Quem escolhe as operações de domínio | O modelo do especialista | O modelo do pai |
| O que roda remoto | Um loop de especialista e as tools dele | Tools MCP e os serviços atrás delas |
| O que continua distribuído | Agents, serviços, dados | Skill providers, serviços, dados |
O name e a description do Agent Card viram uma entrada de descoberta. O system prompt vira SKILL.md. Parâmetros de tool viram schemas de input / output do MCP. Serviços de negócio ficam atrás dos handlers das tools. Endpoint, auth e transporte no Card não entram na description do Skill. Isso bate com o texto de 11 de setembro: Skills são o procedimento, MCP é o soquete, Tools são o contrato. O que mudou é como o procedimento é descoberto — não um colapso das três camadas numa só.
O contrato de descoberta: skill://index.json
Um orquestrador não precisa de todo procedimento em cada request. Precisa de um diretório bom o bastante para rotear. O index do provider de clima na demo é:
{
"$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 é o index de descoberta de Agent Skills com semântica MCP: url é um URI de recurso, não um host https. $schema aponta para discovery 0.2.0 em schemas.agentskills.io. A description responde quando usar a competência. O SKILL.md responde como — nomeando operações como weather_forecast, intervalos, unidades e a proibição de inventar observações. Tipos e limites dessas operações ainda vêm do JSON Schema no tools/list do MCP.
Na inicialização o pai puxa o catálogo e o tools/list via MCP. O modelo primeiro vê resumos de Skill e helpers de carga, não cada schema de operação. Depois de load_skill("weather"), o middleware anexa aquele grupo. Uma tool aparecer no contexto não é uma execução.
SEP-2640: Accepted, não Final
O SEP-2640 é o binding de Skills no Extensions Track: servir Agent Skills por MCP Resources. O id da extensão é io.modelcontextprotocol/skills. Layout de diretório, YAML frontmatter e divulgação progressiva ficam na spec de Agent Skills. O SEP só amarra o transporte.
Na checagem de 10 de setembro no post de Stocchi: a revisão de 3 de setembro marcou Accepted e moveu a descoberta para skills/list e skills/get (paginados; as entradas carregam uri, frontmatter parseado e um manifesto de recursos com digests sha256:). O PR correspondente ainda estava aberto. A demo trava num Draft mais antigo: lê skill://index.json e não implementa os métodos novos. O repositório de incubação ainda é Experimental.
Não escreva «Final em 13 de setembro» de segunda mão numa checklist de produção. O que é sólido em 22 de setembro de 2026: Accepted, não Final, dois formatos de descoberta em uso. Tratar o index Draft como requisito central do MCP contradiz a nota de rodapé do próprio post.
O contrato da ferramenta continua sendo JSON Schema
A previsão da demo recebe hours com Range(1, 24) e UseStructuredContent. O SDK publica a definição da tool. O handler valida o intervalo e depois chama o serviço de domínio. O SKILL.md guia qual tool escolher. Ele não substitui o schema de parâmetros nem as checagens no server.
Operações autoritativas vêm de tools/list. Execução é tools/call. Instruções são resources/read. Os três saltos são JSON-RPC. Um Skill pode dizer «pagine»; não persiste o seu cursor. Pode mencionar um passo de aprovação; não aplica autorização. É a mesma camada de por que o Tool Calling depende de JSON Schema: a prosa escolhe a estrada, o contrato recusa arguments ilegais.
Três pares de medição: mais rápido, não mais barato em tokens
O mesmo prompt («considerando o clima e o tempo de espera, por onde eu começo?»), o mesmo app Aspire, gpt41, três conversas novas. O caminho A2A usou 6 / 6 / 7 chamadas de modelo (especialistas podem sobrepor). O caminho Skills usou 3 cada vez: load_skill, depois operações MCP diretas, depois a resposta final. O wall-clock médio no cliente foi cerca de 6,35 s contra 15,48 s.
Os tokens não caíram. Nas três rodadas o lado Skills observou cerca de 13.533 contra cerca de 11.134 no A2A — uns 22% a mais. Menos saltos de modelo não é um contexto acumulado menor: instruções, schemas do grupo e resultados se empilham nas três chamadas. Os contadores de cache do A2A estavam incompletos. Isto não é uma conta, e não é um estudo controlado. O original diz isso: três pares, não prova de correção ou de completude iguais.
A observação estrutural cabe numa frase: o que você corta é o loop aninhado de especialista, não as idas e voltas de JSON. Indexes de descoberta, schemas de tool, resultados estruturados ainda saltam. Só passam a viver como uns poucos contratos no contexto do pai, em vez de um discurso de cada especialista.
Dois formatos de descoberta, hosts que não se encontram
A rachadura já era visível em agosto–setembro de 2026. O UseMcpSkills em Microsoft.Agents.AI.Mcp ainda lê skill://index.json. Um server que só implementa skills/list leva «nenhum recurso de index». Um server que só envia o index, sem declaração da extensão nem digests, fica invisível para um host mais novo. Alguns hosts já marcam servers baseados em index como legacy.
Não aposte num vencedor. Num catálogo pequeno, sirva os dois: um index Draft para clientes antigos, skills/list / skills/get para hosts que declaram a extensão. Um listing ausente ou vazio não deve ser tratado como «este server não tem skills» — o Draft permite enumeração parcial para catálogos grandes ou gerados.
Três documentos JSON que você ainda checa no local
- O documento de descoberta. Entradas de
skill://index.jsonouskills/list:name,type,description,url/uri. Cheque contra$schema. Chaves a mais, descriptions vazias ou um host https emurlsão bugs de roteamento, não ajustes de texto. - Schemas de ferramenta. Pegue o
inputSchemadotools/list. Preencha required, ponhaadditionalProperties: false, aperte enums e intervalos. Nomes que a prosa do Skill cita têm de bater com a lista. - Resultados estruturados. A demo liga Structured Content. O output de volta ao pai ainda deve ser JSON legal, depois checado contra um schema. Não devolva uma linha inteira de banco nem um stack. Veja por que agentes precisam de JSON depois da Agents API.
Inspecione o documento de descoberta com ferramentas JSON locais
Antes de ligar o MAF ou qualquer host, abra três textos no navegador: o index de descoberta, um schema do tools/list e um objeto arguments de amostra de tools/call.
- Validador JSON — a gramática é legal; se você tem schema, cheque campos, required e chaves a mais juntos.
- Formatador JSON — expanda um index numa linha e veja se o
urlé mesmoskill://. - JSON Diff — compare uma entrada de index Draft com uma entrada de
skills/listpara os dois catálogos não divergirem.
Nada sai do navegador. Estabilize o contrato de descoberta, depois deixe o pai carregar o SKILL.md. O procedimento pode mudar o texto. Nomes de campo e URIs não deveriam se mover toda semana.
FAQ
O SEP-2640 já é Final?
Não. A revisão de 3 de setembro é Accepted. A checagem de 10 de setembro de Stocchi ainda tinha um PR aberto. A demo usa um Draft histórico de skill://index.json. Não corte clientes antigos numa história de «já é Final».
Distributed Skills vão substituir o A2A?
Não como regra geral. Mantenha um Agent quando você precisa de ciclo de vida independente, contexto privado ou um modelo especializado. Migre para um Skill quando só precisa de um procedimento mais operações. Deixar a pesquisa na web como tool de agent é essa distinção.
skill:// é uma URL que o host deve resolver?
Não. Nomeia um recurso numa conexão MCP já configurada. A prosa do Skill não deve usá-lo para abrir outro host.
Se eu tenho SKILL.md, ainda preciso de JSON Schema?
Sim. Markdown guia a escolha da tool e como ler resultados. Tipos, intervalos e campos required ainda vêm do schema do tools/list e de uma checagem que você mesmo roda.
skill://index.json sozinho basta?
Para alguns clientes Microsoft atuais, sim. Para hosts no Draft mais novo, não. Sirva os dois num catálogo pequeno. Um formato sozinho fica invisível para a outra metade do campo.
O caminho Skills é mais barato?
Na demo, o wall-clock foi mais rápido e os tokens observados uns 22% mais altos. Não é um estudo controlado. Compare roteamento e resultados estruturados primeiro, depois a conta.
Resumo
A demo de 16 de setembro não anunciou que agents ficaram obsoletos. Anunciou que uma competência que não precisa de raciocínio aninhado pode enviar um procedimento e operações, com uma superfície de descoberta em JSON. As fronteiras de serviço ficam. O que você corta é o loop de modelo do especialista. O que você ainda segura é o index de descoberta, o schema da tool e o resultado estruturado.
O SEP-2640 ainda é Accepted. O index Draft e o skills/list vão viver lado a lado por um tempo. Passe os três documentos JSON num validador local antes de entregá-los a um host. A camada de 11 de setembro ainda vale. O que não vale mais é «um Skill é só uma pasta no disco». Modelos e harnesses vão pegar versões novas. name, url e inputSchema não deveriam afrouxar junto.