AI Agent Skills vs MCP vs Plugins : que doivent utiliser les développeurs en 2026 ? De la découverte au JSON Schema

Mauvaise question : ce ne sont pas des rivaux sur une couche

L’échec de revue habituel, c’est trois cartes sur la table et un vote. Un skill n’expose pas tools/list et ne prend pas tools/call. C’est un répertoire plus SKILL.md : au démarrage seuls name et description entrent dans le contexte (environ cent tokens) ; le corps et scripts/, references/ se chargent à la demande. Pas de JSON-RPC, pas de poignée de main, pas de « schéma d’entrée de skill » sur le fil. MCP est l’inverse : processus ou endpoint HTTP, arguments qui doivent valider en JSON. Un plugin ne fait ni l’un ni l’autre. Il fixe un répertoire et deux manifestes fermés. Voir un plugin comme un « MCP plus fort », c’est prendre un carton pour un moteur.

La découverte n’est pas un seul chemin. Un skill se trouve par une chaîne de description : écrire « quoi + quand » ou le modèle ne le choisit pas. MCP se trouve par tools/list — noms plus inputSchema. Un plugin se trouve par le plugin.json racine, puis les emplacements fixes skills/ et mcp.json. Les trois peuvent s’empiler : le client voit la boîte, puis les métadonnées de skill, puis une liste d’outils MCP. Empiler n’est pas substituer. S’il manque une main et que vous allongez un skill, vous pariez que le modèle simulera une API avec un shell. C’est de l’hallucination, pas de l’intégration.

La délégation latérale n’est pas sur ces trois cartes. Comment un autre agent est trouvé et reçoit une Task, c’est une Agent Card A2A ; voir A2A vs MCP. Aujourd’hui vous décidez seulement : ce dépôt a-t-il besoin d’un brief, d’une main, et ces deux doivent-ils se verrouiller dans un répertoire portable. Couches d’abord, choix ensuite.

Quatre questions pour marcher l’arbre de décision

Pliez le QCM en quatre questions. Répondez dans l’ordre, sans sauter. Premier : le modèle doit-il toucher un système vivant hors du dépôt — base, recherche de docs officielles, API de facturation, gcloud ? Oui : au moins MCP (ou un outil natif déjà là, comme gh local). Non : ne levez pas un serveur vide pour avoir l’air sérieux. Deuxième : devez-vous figer un flux du type « d’abord le projet, puis la facturation, jamais de clés dans git », et le garder d’une session à l’autre ? Oui : écrivez un skill. Un prompt système collé disparaît quand la fenêtre se serre.

Troisième : les réponses à un et deux doivent-elles voyager ensemble ? Un MCP factures sans le skill de résumé hebdo sera mal utilisé ; le skill sans MCP ne démo que sur de fausses données. Alors seulement un plugin. Quatrième : envoyez-vous ça à plus d’un client — Cursor, Claude Code, Antigravity, Codex ? Un IDE qui a déjà l’install native MCP / Skills est plus court en config native. Google l’a cloué sur le Developers Blog : un plugin gagne sa place quand les pièces partagent un but et doivent voyager ensemble.

Ci-dessous un enregistrement de décision que vous pouvez commiter. Ce n’est pas un champ de spec. C’est une fixture JSON de revue : les quatre réponses, le choix, les noms de composants à empaqueter. Faites-le parser, puis affirmez en CI que choice ne se bat pas avec les quatre drapeaux — mustTravelTogether false et choice plugin, c’est trop tôt.

{
  "task": "weekly-invoice-summary",
  "needRuntimeTools": true,
  "needReusableBrief": true,
  "mustTravelTogether": true,
  "clients": ["cursor", "claude-code", "antigravity"],
  "choice": "plugin",
  "components": [
    "skill:write-weekly-summary",
    "mcp:invoice-tools"
  ]
}

Skill seul : la découverte est la description, il n’y a pas de tools/call

Un skill gagne sur trois points : pas de poignée de main, chargement à la demande, les humains peuvent differ. Au démarrage le client n’injecte que les métadonnées ; le modèle lit le corps quand la description matche. Donc la description doit dire quoi et quand, à la troisième personne, avec des mots-clés, et elle a des plafonds (name 64, description 1024). Un nom de code interne ou un slogan à la première personne, surface de découverte nulle. Agent Skills possède le format ; Plugins dit seulement qu’il vit sous skills/<name>/SKILL.md.

Un skill peut emporter scripts/. Ce ne sont pas de nouveaux outils MCP. Ça veut dire « exécute ceci avec le shell que tu as déjà ». Ça va aux CLI locales : gh, gcloud, votre lint.sh. Le script garde le calcul déterministe hors du prompt et renvoie un résumé. Toujours pas de transport : pas de découverte OAuth, pas d’inputSchema ; argv est l’affaire du script. S’il faut des arguments JSON stables ou une auth distante, ne faites pas semblant qu’un script soit MCP.

Skill seul convient aux formats de sortie (corps de PR, rapport d’incident), aux flux CLI locaux et aux garde-fous de domaine (« lis d’abord cette checklist »). Anti-modèle : un skill « interroger la prod » qui demande au modèle d’inventer du SQL et de le passer dans un shell générique. Un brief qui joue la main. Vous ne pouvez pas non plus valider la forme des arguments à la découverte — il n’y a pas de schéma.

MCP seul : la découverte est tools/list, le contrat est inputSchema

MCP gagne sur trois choses qu’un skill ne donne pas : une connexion vivante, une entrée structurée, une frontière d’échec. Le client se connecte, tools/list rend noms et inputSchema, le modèle remplit les arguments, le runtime appelle tools/call. Le passage des arguments, c’est le JSON Schema, pas « le modèle avait l’air sûr ». Auth, quotas, versions de transport restent sur la spec MCP ; la révision sans état 2026-07-28 peut s’asseoir derrière un équilibreur HTTP normal. Un skill ne fait aucune de ces couches.

Un client, un serveur : préférez la config MCP native de ce client, pas un plugin d’abord. mcp.json est la forme portable Agent Plugins ; ses champs n’ont pas à coller à Cursor ou Gemini CLI. Le client mappe. Un IDE rend la couche de mapping superflue. Quand un second client apparaît, pliez la même connexion dans mcp.json racine et ajoutez plugin.json — même sans skills/. Un répertoire skills absent n’est pas une erreur ; la spec dit de sauter un emplacement manquant.

La chaîne de découverte est courte : connecter → tools/list → remplir depuis inputSchema. Ne jetez pas tout un OpenAPI à un client MCP comme liste d’outils, et ne copiez pas les champs du manifeste plugin dans inputSchema. Le contrat de paquet répond « la boîte est-elle là ». Le contrat d’outil répond « les arguments de ce saut sont-ils légaux ». Les deux sont du JSON Schema ; ils sont à un hop d’écart. Ci-dessous un fragment MCP portable à écrire avant d’empaqueter — il tombe tel quel à la racine du plugin plus tard.

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "invoice-tools": {
      "type": "stdio",
      "command": "./bin/invoice-mcp",
      "args": ["--data", "${PLUGIN_DATA}/invoices"],
      "cwd": "${PLUGIN_ROOT}"
    }
  }
}

Quand empaqueter : le Plugin paie si plusieurs composants et plusieurs clients

Un plugin vaut le coup quand les questions trois et quatre s’allument ensemble. Paire typique : un MCP qui interroge des chiffres plus un skill qui écrit un résumé hebdo humain ; ou la paire Google — skills garde-fous gcloud plus MCP Developer Knowledge. Chacun est mal utilisé sans l’autre : la main seule invente le rapport ; le brief seul n’a pas de recherche de docs ancrée. Une fois empaqueté, Antigravity, Claude Code et Codex partagent une arborescence. plugin.json reste fermé, mcp.json séparé, les secrets dans des variables d’environnement, pas dans headers.

Empaqueter trop tôt coûte un manifeste à tenir et une hallucination de revue : « on a un plugin maintenant ». La boîte ne transforme pas un skill en outil et ne donne pas de brief au MCP. Les composants indépendants échouent indépendamment : un serveur de mcp.json peut refuser de démarrer pendant que les skills chargent ; un frontmatter SKILL.md cassé n’emporte pas le reste. C’est la spec. Si votre CI refuse tout le paquet pour un champ de tête inconnu, vous êtes plus stricts que le client — sachez-le.

Retracez la ligne A2A. Un plugin répond comment cet agent gagne un jeu de skills et d’outils. Comment l’agent factures d’une autre équipe est découvert, c’est une Agent Card, pas le fourrer dans votre mcp.json comme un tool. Les clarifications multi-tours et les callbacks asynchrones font éclater une forme d’appel de fonction. Une phrase pour l’ordre : la main d’abord, le brief ensuite, la boîte en dernier. Un plugin sans main, c’est commander des cartons avant de savoir ce que vous vendez.

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin",
  "version": "1.0.0",
  "description": "Invoice MCP plus the weekly-summary skill, shipped together"
}

Trois schémas, trois découvertes ; les vérifier dans JSONVue

Étalez les contrats par hop. Premier : plugin.schema.json — la boîte peut-elle être trouvée ; figer $schema sur https://agent-plugins.org/schemas/1.0.0/plugin.schema.json. Deuxième : mcp.schema.json — comment se connecter ; type doit être explicite. Troisième : inputSchema de chaque outil — les arguments passent-ils. Le frontmatter de skill est du YAML, pas l’un de ces trois ; ne « JSON Schema »-ez pas tout un SKILL.md. La découverte vérifie les deux premiers ; l’invocation le troisième.

Gardez au moins cinq fixtures : l’enregistrement de décision ci-dessus, un plugin.json légal, un manifeste avec un champ de tête en trop, un mcp.json portable, un vrai objet arguments tools/call. L’enregistrement attrape un combat entre les quatre questions et choice. Les manifestes attrapent le contrat de paquet. Les arguments attrapent le contrat d’outil. Developer Knowledge utilise une clé API au runtime client ; le mcp.json que vous validez dans git ne doit pas contenir de secrets.

Dans le navigateur :Formater du JSONpour voir si l’enregistrement et les deux manifestes parsent ;Valider JSON Schemapour $schema, name, mcpServers et inputSchema ;JSON Diffpour comparer un mcp.json portable à un export natif. Les données restent sur cette machine. Suite :MCP et JSON Schema, l’aperçu Plugins, et comment A2A et MCP se partagent le travail.

Liés : Google Agent Plugins 2026, MCP et JSON Schema, Qu’est-ce que MCP, A2A vs MCP.

FAQ

Résumé et suite

Choisir entre Skills, MCP et Plugins en 2026 tient en une phrase : avez-vous besoin d’une main, d’un brief, ces deux doivent-ils voyager ensemble, plus d’un client les installera-t-il ? Pas un vote à trois. Des couches qui s’empilent.

Livrez dans cet ordre : les quatre réponses en JSON de décision ; s’il faut une main, inputSchema d’abord ; s’il faut un brief, description d’abord ; si les deux s’allument et que vous traversez des clients, ajoutez plugin.json. Vérifiez les trois contrats dans JSONVue. La forme de la boîte est l’aperçu Plugins ; le protocole filaire, les articles MCP ; le travail inter-agents, l’article A2A.