D’emblée : une fois qu’un Skill monte sur MCP, la procédure peut rester du Markdown. Le contrat de découverte reste du JSON. Le 16 septembre 2026, Tommaso Stocchi de Microsoft Agent Framework a publié une comparaison côte à côte : un conseiller de station de ski est passé de « chaque spécialiste fait tourner son propre modèle » à « le parent charge un Skill à la demande, puis appelle les outils MCP directement ». Les services restent distribués. Le raisonnement entre dans le contexte parent. L’article du 11 septembre de ce site sur MCP / Skills / Tools / Subagents couvrait les quatre couches. Cet article n’ajoute que ce qui s’est passé après cette date : à quoi ressemble le document de découverte, où en est vraiment SEP-2640, et pourquoi vous vérifiez encore un fichier JSON d’abord.
Rédigé au 22 septembre 2026. SEP-2640 (l’extension Skills) a été marqué Accepted le 3 septembre. Ce n’est pas Final. La démo Microsoft épingle un Draft historique de skill://index.json. Le Draft plus récent utilise skills/list et skills/get. Deux formes de découverte sont en circulation. La compatibilité est une meilleure première question que « les Skills ont-ils remplacé les Agents ».
Ce qui a vraiment été publié le 16 septembre
Le post de Stocchi s’intitule From Specialist Agents to Distributed Skills over MCP. Le conseiller de station de ski appelait quatre spécialistes via A2A : météo, sécurité, coaching ski, trafic des remontées. Chaque spécialiste possédait instructions, outils et une boucle modèle. La seconde voie transforme les mêmes services métier en MCP providers : chacun publie une description, un SKILL.md, et des outils MCP typés. Le conseiller utilise SkillsProvider et MCPSkillsSource de MAF pour la découverte et le chargement. SkillToolsMiddleware attache les outils de ce provider au tour modèle suivant après que load_skill a réussi.
La recherche web reste un outil agent ordinaire. L’hybride est volontaire : gardez l’autonomie là où il en faut ; transformez une compétence bornée en Skill. Les quatre endpoints MCP vivent à /skillsmcp. La surface de ressources est en général seulement :
skill://index.json
skill://<skill-name>/SKILL.mdskill:// nomme une ressource sur une connexion MCP déjà configurée. Ce n’est pas un nom d’hôte, et la prose d’un Skill ne doit pas ouvrir un nouveau saut réseau. Authentification, transport et autorisation restent dans l’infrastructure et le code, pas dans le Markdown.
Ce n’est pas MCP qui remplace A2A
L’original trace une ligne nette. A2A remet une tâche à un autre raisonneur. Un Distributed Skill remet une compétence et ses opérations au raisonneur courant. Une table suffit :
| Préoccupation | Agent comme outil (A2A) | Distributed Skill |
|---|---|---|
| Ce que le parent découvre | Un agent spécialiste qu’il peut appeler | Une compétence qu’il peut charger |
| Où tournent les instructions du spécialiste | Le contexte modèle du spécialiste | Le contexte modèle du parent |
| Qui choisit les opérations métier | Le modèle spécialiste | Le modèle parent |
| Ce qui tourne à distance | Une boucle spécialiste et ses outils | Les outils MCP et leurs services derrière |
| Ce qui reste distribué | Agents, services, données | Skill providers, services, données |
Le nom et la description de l’Agent Card deviennent une entrée de découverte. Le system prompt devient SKILL.md. Les paramètres d’outil deviennent des schemas MCP input / output. Les services métier restent derrière les handlers d’outils. Endpoint, auth et transport sur la Card n’appartiennent pas à la description du Skill. Cela colle à l’article du 11 septembre : les Skills sont la procédure, MCP est la prise, les Tools sont le contrat. Ce qui a changé, c’est comment la procédure est découverte — pas un effondrement des trois couches en une.
Le contrat de découverte : skill://index.json
Un orchestrateur n’a pas besoin de chaque procédure à chaque requête. Il a besoin d’un répertoire assez bon pour router. L’index du provider météo dans la démo est :
{
"$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"
}
]
}C’est l’index de découverte Agent Skills avec la sémantique MCP : url est une URI de ressource, pas un hôte https. $schema pointe vers discovery 0.2.0 sur schemas.agentskills.io. La description répond à quand utiliser la compétence. SKILL.md répond au comment — en nommant des opérations comme weather_forecast, les plages, les unités, et l’interdiction d’inventer des observations. Types et bornes de ces opérations viennent encore du JSON Schema dans MCP tools/list.
Au démarrage, le parent tire le catalogue et tools/list via MCP. Le modèle voit d’abord les résumés de Skill et les helpers de chargement, pas chaque schema d’opération. Après load_skill("weather"), le middleware attache ce groupe. Un outil qui apparaît dans le contexte n’est pas une exécution.
SEP-2640 : Accepted, not Final
SEP-2640 est le binding Skills sur l’Extensions Track : servir les Agent Skills via MCP Resources. L’id d’extension est io.modelcontextprotocol/skills. La disposition des répertoires, le YAML frontmatter et le progressive disclosure restent à la spec Agent Skills. Le SEP ne lie que le transport.
Au contrôle du 10 septembre dans le post de Stocchi : la révision du 3 septembre a marqué Accepted et a déplacé la découverte vers skills/list et skills/get (paginés ; les entrées portent uri, le frontmatter parsé, et un manifeste de ressources avec des digests sha256:). Le PR correspondant était encore ouvert. La démo épingle un Draft plus ancien : elle lit skill://index.json et n’implémente pas les nouvelles méthodes. Le dépôt d’incubation est encore Experimental.
N’écrivez pas un « Final le 13 septembre » de seconde main dans une checklist de production. Ce qui est solide au 22 septembre 2026 : Accepted, pas Final, deux formes de découverte en usage. Traiter l’index Draft comme une exigence MCP cœur contredit la note de bas de page du post lui-même.
Le contrat d’outil reste du JSON Schema
La prévision de la démo prend hours avec Range(1, 24) et UseStructuredContent. Le SDK publie la définition d’outil. Le handler valide la plage, puis appelle le service métier. SKILL.md guide quel outil choisir. Il ne remplace pas le schema de paramètres ni les contrôles côté serveur.
Les opérations faisant autorité viennent de tools/list. L’exécution est tools/call. Les instructions sont resources/read. Les trois sauts sont du JSON-RPC. Un Skill peut dire « paginer » ; il ne peut pas persister votre cursor. Il peut mentionner une étape d’approbation ; il ne peut pas imposer l’autorisation. C’est la même couche que pourquoi le Tool Calling dépend de JSON Schema : la prose choisit une route, le contrat rejette les arguments illégaux.
Trois paires de runs : plus rapide, pas moins cher en tokens
Le même prompt (« en tenant compte de la météo et du temps d’attente, par où commencer ? »), la même appli Aspire, gpt41, trois conversations fraîches. Le chemin A2A a utilisé 6 / 6 / 7 appels modèle (les spécialistes peuvent se chevaucher). Le chemin Skills a utilisé 3 à chaque fois : load_skill, puis des opérations MCP directes, puis la réponse finale. Le temps mur client moyen était d’environ 6.35 s contre 15.48 s.
Les tokens n’ont pas baissé. Sur trois runs, le côté Skills a observé environ 13,533 contre environ 11,134 pour A2A — à peu près 22 % de plus. Moins de sauts modèle n’est pas un contexte cumulé plus petit : instructions, schemas de groupe et résultats s’empilent sur les trois appels. Les compteurs de cache A2A étaient incomplets. Ce n’est pas une facture, ni une étude contrôlée. L’original le dit : trois paires, pas une preuve d’égale justesse ou complétude.
L’observation structurelle tient en une phrase : ce que vous enlevez, c’est la boucle spécialiste imbriquée, pas les allers-retours JSON. Les index de découverte, les schemas d’outils, les résultats structurés sautent encore. Ils vivent juste comme quelques contrats dans le contexte parent au lieu d’un discours de chaque spécialiste.
Deux formes de découverte, des Hosts qui se ratent
La fracture était déjà visible en août–septembre 2026. UseMcpSkills dans Microsoft.Agents.AI.Mcp lit encore skill://index.json. Un server qui n’implémente que skills/list reçoit « no index resource ». Un server qui ne livre que l’index, sans la déclaration d’extension ni les digests, est invisible pour un Host plus récent. Certains Hosts marquent déjà les servers à index comme legacy.
Ne pariez pas sur un vainqueur. Pour un petit catalogue, servez les deux : un index Draft pour les clients plus anciens, skills/list / skills/get pour les Hosts qui déclarent l’extension. Une liste absente ou vide ne doit pas être traitée comme « ce server n’a pas de Skill » — le Draft autorise l’énumération partielle pour les grands catalogues ou les catalogues générés.
Trois documents JSON à encore vérifier en local
- Le document de découverte. Les entrées de
skill://index.jsonouskills/list:name,type,description,url/uri. Contrôlez-les contre$schema. Des clés en trop, des descriptions vides, ou un hôte https dansurlsont des bugs de routage, pas des retouches de texte. - Les schemas d’outils. Prenez
inputSchemadanstools/list. Remplissez required, posezadditionalProperties: false, serrez enums et plages. Les noms que la prose du Skill mentionne doivent correspondre à la liste. - Les résultats structurés. La démo active Structured Content. L’output renvoyé au parent doit encore être du JSON légal, puis vérifié contre un schema. Ne renvoyez pas toute une ligne de base ni une stack. Voir pourquoi les agents ont encore plus besoin de JSON après l’Agents API.
Inspecter le document de découverte avec les outils JSON locaux
Avant de câbler MAF ou n’importe quel Host, étalez trois textes dans le navigateur : l’index de découverte, un schema de tools/list, et un objet arguments d’échantillon tools/call.
- Validateur JSON — la grammaire est-elle légale ; si vous avez un schema, vérifiez ensemble champs, required et clés en trop.
- Formateur JSON — déroulez un index sur une ligne et voyez si
urlest vraimentskill://. - JSON Diff — comparez une entrée d’index Draft avec une entrée
skills/listpour que les deux catalogues ne divergent pas.
Rien ne quitte le navigateur. Stabilisez le contrat de découverte, puis laissez le parent charger SKILL.md. La procédure peut changer de formulation. Les noms de champs et les URI ne devraient pas bouger chaque semaine.
FAQ
SEP-2640 est-il Final maintenant ?
Non. La révision du 3 septembre est Accepted. Le contrôle du 10 septembre de Stocchi avait encore un PR ouvert. La démo utilise un Draft historique de skill://index.json. Ne jetez pas les anciens clients sur une histoire « déjà Final ».
Les Distributed Skills vont-ils remplacer A2A ?
Pas comme règle unique. Gardez un Agent quand vous avez besoin d’un cycle de vie indépendant, d’un contexte privé, ou d’un modèle spécialisé. Migrez vers un Skill quand vous n’avez besoin que d’une procédure plus des opérations. Laisser la recherche web comme outil agent, c’est cette distinction.
skill:// est-il une URL que le Host doit résoudre ?
Non. Il nomme une ressource sur une connexion MCP déjà configurée. La prose d’un Skill ne doit pas s’en servir pour ouvrir un autre hôte.
Si j’ai SKILL.md, ai-je encore besoin de JSON Schema ?
Oui. Le Markdown guide le choix d’outil et comment lire les résultats. Types, plages et champs required viennent encore du schema tools/list et d’un contrôle que vous lancez vous-même.
skill://index.json suffit-il à lui seul ?
Pour certains clients Microsoft actuels, oui. Pour les Hosts sur le Draft plus récent, non. Servez les deux sur un petit catalogue. Une seule forme est invisible pour l’autre moitié du terrain.
Le chemin Skills est-il moins cher ?
Dans la démo, le temps mur était plus rapide et les tokens observés environ 22 % plus hauts. Ce n’est pas une étude contrôlée. Comparez d’abord le routage et les résultats structurés, puis la facture.
Résumé
La démo du 16 septembre n’a pas annoncé que les agents sont obsolètes. Elle a annoncé qu’une compétence qui n’a pas besoin de raisonnement imbriqué peut livrer une procédure et des opérations, avec une surface de découverte JSON. Les frontières de service restent. Ce que vous enlevez, c’est la boucle modèle spécialiste. Ce que vous tenez encore, c’est l’index de découverte, le schema d’outil, et le résultat structuré.
SEP-2640 est encore Accepted. L’index Draft et skills/list vivront côte à côte un moment. Aplatissez les trois documents JSON dans un validateur local avant de les passer à un Host. La stratification du 11 septembre tient encore. Ce qui ne tient plus, c’est « un Skill n’est qu’un dossier sur disque ». Les modèles et les harness prendront de nouvelles versions. name, url et inputSchema ne devraient pas se relâcher avec eux.