Agent Plugins 1.0 expliqué : la norme portable pour les compétences et serveurs MCP entre agents IA

Nom : Salutation
Description : Saluer l'utilisateur et proposer de l'aide.

Saluer brièvement l'utilisateur et demander comment l'aider.

### Étape 4 : N'ajouter MCP que si nécessaire

Si le plugin nécessite des outils, ajoutez :

```Plaintext
mcp.json

Un plugin ne doit pas nécessairement configurer un MCP vide pour être valide.

L'absence de composants optionnels n'est pas considérée comme une erreur.

Étape 5 : Tester dans les clients compatibles

Testez le noyau portable dans chaque client que vous prévoyez de prendre en charge.

Ne supposez pas que « compatible avec les plugins d'agent » signifie que chaque composant et chaque mode de transport sont implémentés.

Les clients peuvent adopter les composants progressivement.

Exemple de plugin avec serveur MCP local

Un package plus utile pourrait ressembler à ceci :

reporting-plugin/
├── plugin.json
├── skills/
│   └── weekly-report/
│       └── SKILL.md
├── mcp.json
└── bin/
    └── reporting-server

Manifeste :

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reporting-plugin",
  "version": "1.0.0",
  "description": "Flux de travail et outils de rapport portables."
}

Configuration MCP :

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "reporting": {
      "type": "stdio",
      "command": "./bin/reporting-server",
      "cwd": "${PLUGIN_ROOT}"
    }
  }
}

Un client conforme peut découvrir :

• L'identité du plugin
• La compétence de rapport hebdomadaire
• Le serveur MCP de rapport

Sans que l'auteur ait besoin de placer ces composants portables dans des structures totalement différentes pour chaque client.

L'isolation des erreurs rend les plugins plus résilients

L'une des parties réfléchies de la spécification est que de nombreuses pannes de composants sont locales et non catastrophiques.

Par exemple :

• Une compétence invalide peut être ignorée tandis que les autres continuent de se charger.
• Une entrée de serveur MCP invalide ne désactive pas nécessairement tous les serveurs.
• Une connexion MCP échouée ne doit pas empêcher le chargement des compétences indépendantes.
• Les clients peuvent ignorer les types de composants non pris en charge.

Cela est crucial dans un véritable écosystème multi-clients.

Un plugin peut fournir :

Compétence A
Compétence B
Serveur MCP A
Serveur MCP B
Extension de client

Si un client ne prend pas en charge un mode de transport particulier, le reste utile et portable devrait continuer à fonctionner dans la mesure du possible.

Sinon, l'interopérabilité devient fragile : une fonctionnalité optionnelle non prise en charge désactiverait l'ensemble du plugin.

Les clients conformes peuvent adopter la norme progressivement

Les clients ne doivent pas nécessairement implémenter toutes les fonctionnalités de la v1.

Un client qui ne prend en charge que les compétences peut toujours être conforme s'il charge correctement le manifeste et met en œuvre les comportements de compétences associés.

Un client prenant en charge MCP doit respecter les règles de transport applicables.

Ce modèle incrémental réduit les obstacles à l'adoption.

Les petits clients peuvent commencer avec :

plugin.json
+
skills/

Et ajouter MCP plus tard.

Les grands clients peuvent implémenter le noyau portable complet ainsi que leurs propres espaces de noms d'extensions.

Le projet est gouverné par la communauté, et non contrôlé par un seul fournisseur

Le titre d'AIBase décrit l'introduction des plugins d'agent par OpenAI.

OpenAI est clairement un acteur important.

Le document officiel de gouvernance élargit le modèle de propriété.

Les plugins d'agent se présentent comme

un projet gouverné par la communauté et neutre vis-à-vis des fournisseurs.

Son comité technique de pilotage est composé de mainteneurs principaux indépendants, sans sièges réservés aux entreprises.

La charte stipule :

• Aucun fournisseur unique ne doit contrôler la majorité des sièges de mainteneur principal.
• Les propositions techniques et les discussions sont publiques.
• La participation au projet est ouverte selon des règles claires.
• Les documents de spécification et les supports sont sous licence CC BY 4.0 par défaut.
• Les modèles, codes et supports logiciels sont sous licence Apache 2.0 par défaut.

Les mainteneurs principaux initiaux actuellement listés sur la page d'accueil du projet proviennent de :

• Amazon
• Cursor
• Microsoft
• OpenAI
• Vercel

Cette structure multi-fournisseurs est importante car les normes d'interopérabilité gagnent en crédibilité lorsque les clients concurrents disposent d'une voie de participation.

La norme dispose déjà de plusieurs clients compatibles

La page de compatibilité officielle répertorie actuellement :

• VS Code
• Cursor
• GitHub Copilot
• ChatGPT avec Codex
• Kiro

C'est un point de départ plus solide qu'une norme uniquement soutenue par son créateur.

La matrice de prise en charge n'est pas encore entièrement identique.

Par exemple, plusieurs clients répertoriés sur la page actuelle prennent en charge le SSE traditionnel, tandis que ChatGPT avec Codex répertorie actuellement stdio et Streamable HTTP.

Le résultat important est que ce format de package a déjà franchi les frontières entre fournisseurs.

Les auteurs de plugins peuvent désormais cibler un noyau commun sans supposer que chaque environnement d'agent constitue un écosystème totalement distinct.

Pourquoi cela devient plus important à mesure que les agents deviennent des systèmes à long terme

Lorsque les agents effectuent un travail réel, le problème de la fragmentation des plugins devient plus marqué.

Un simple chatbot peut fonctionner avec une petite liste d'outils fixes.

Un agent sérieux peut nécessiter :

• Des processus spécifiques à l'entreprise
• Un accès aux bases de données
• L'automatisation du navigateur
• Des outils de déploiement
• Des contrôles de sécurité
• Des flux de travail documentaires
• Des instructions de domaine réutilisables
• Des scripts dédiés
• Plusieurs services MCP

À mesure que ces composants se multiplient, la portabilité devient une infrastructure.

Sans mécanisme d'empaquetage partagé, chaque entreprise risque de devoir maintenir une telle matrice :

Capacités × Clients d'agents × Versions × Plateformes

Un format de package portable réduit une dimension de cette matrice.

Il n'élimine pas le travail spécifique au client.

Mais il peut réduire le travail de duplication nécessaire pour maintenir un noyau réutilisable cohérent.

Plugins d'agent, MCP et compétences d'agent résolvent des problèmes différents

Ces trois concepts sont liés, mais ne doivent pas être confondus.

Norme	Rôle principal
Compétences d'agent	Définir des actifs réutilisables d'instructions/flux de travail pour les agents
MCP	Définir la communication entre les clients IA et les serveurs d'outils/données externes
Plugins d'agent	Définir comment empaqueter les compétences et les configurations MCP de manière portable

Un modèle mental utile est :

Compétences
= ce que l'agent devrait savoir ou comment il devrait fonctionner

MCP
= comment l'agent se connecte à des capacités externes

Plugins d'agent
= comment ces parties réutilisables sont empaquetées pour s'adapter aux clients compatibles

Ainsi, les plugins d'agent constituent une couche au-dessus des normes de composants existantes, et non leur remplacement.

Ce que les plugins d'agent ne résolvent pas

La portée de la norme est délibérément étroite.

Elle ne résout pas tous les problèmes de compatibilité entre agents.

Elle ne normalise pas

les modèles

Un même plugin peut se comporter différemment selon le modèle qui le charge.

Elle n'unifie pas les interfaces de permissions

Un client peut demander une confirmation avant d'exécuter une action, tandis qu'un autre utilise une politique au niveau de l'espace de travail.

Elle n'unifie pas l'authentification

La gestion d'OAuth et des identifiants reste du ressort du client.

Elle ne garantit pas la prise en charge de tous les modes de transport MCP

Les clients peuvent implémenter différents sous-ensembles.

Elle n'unifie pas les hooks ou commandes dans la v1

Ceux-ci restent définis par le client.

Elle ne crée pas de marché applicatif unifié

La distribution reste hors du périmètre de la spécification de base.

Elle ne met pas les processus MCP en sandbox

L'inclusion d'un chemin dans le package ne signifie pas une isolation au moment de l'exécution.

Elle ne garantit pas un comportement totalement identique

La portabilité signifie que les clients peuvent découvrir et charger des composants selon un contrat partagé. Cela ne signifie pas que chaque environnement d'exécution d'agent raisonnera ou invoquera ce composant exactement de la même manière.

Considérations de sécurité pour les auteurs de plugins

Les plugins portables peuvent étendre la portée de la distribution.

Cela augmente également l'importance de configurations de sécurité par défaut.

N’intégrez pas d’informations confidentielles

Évitez de stocker des identifiants aux emplacements suivants :

plugin.json
en-tête de mcp.json
valeurs des variables d’environnement dans mcp.json
fichiers empaquetés

Utilisez plutôt une authentification gérée par le client.

Limitez le chemin du package

Ne vous fiez pas à une sortie du répertoire racine du plugin pour accéder à des fichiers arbitraires de l’hôte.

Considérez les serveurs MCP locaux comme du code exécutable

Les serveurs stdio peuvent lancer des processus.

Les utilisateurs et les administrateurs d’entreprise doivent savoir ce qu’ils installent.

Réduisez les autorisations au strict nécessaire

Un plugin qui ne nécessite que des droits en lecture ne doit pas demander d’opérations en écriture.

Documentez les services externes

Les serveurs MCP distants doivent avoir des politiques claires en matière de propriété, de confidentialité et d’utilisation des données.

Gérez les versions avec prudence

Même si la structure des répertoires reste valide, des changements de comportement du serveur peuvent constituer des modifications cassantes.

Que doivent faire les développeurs maintenant

Étape 1 : Distinguez les parties portables des parties spécifiques au client

Déterminez quelles parties de votre plugin actuel sont réellement réutilisables :

Compétences
Serveurs MCP
Métadonnées partagées

Migrez les comportements spécifiques au client vers les espaces de noms d’extension correspondants.

Étape 2 : Ajoutez un schéma versionné

Déclarez explicitement Agent Plugins 1.0.0 dans plugin.json.

Étape 3 : Normalisez l’emplacement des compétences

Placez les compétences Agent portables dans :

skills/<nom_de_la_competence>/SKILL.md

Étape 4 : Normalisez la configuration MCP

Utilisez un fichier racine :

mcp.json

plutôt que de dépendre uniquement des fichiers de configuration natifs du client.

Étape 5 : Supprimez les informations confidentielles portables

Migrez les identifiants vers le système d’authentification de chaque client.

Étape 6 : Testez le package sur plusieurs clients

L’interopérabilité doit être vérifiée par des démonstrations réelles, et non tenue pour acquise.

Étape 7 : Suivez les mises à jour de la spécification

Étant donné que la spécification est encore marquée comme brouillon de travail, surveillez les modifications dans le dépôt du projet, les discussions, les schémas et les pages de compatibilité.

Éléments confirmés et points à clarifier

Déclaration	Statut
La spécification Agent Plugins 1.0.0 est publiée	Confirmé
Cette spécification définit un format portable pour les compétences et les serveurs MCP	Confirmé
Le fichier racine plugin.json est obligatoire	Confirmé
skills/ est l’emplacement fixe des compétences	Confirmé
Le fichier racine mcp.json est l’emplacement de configuration MCP	Confirmé
stdio et Streamable HTTP sont les types de transport MCP standard	Confirmé
Le SSE hérité est reconnu mais optionnel pour les clients	Confirmé
Les extensions spécifiques au client utilisent des espaces de noms de domaine inversé	Confirmé
La distribution, l’installation, les autorisations et l’expérience utilisateur sont normalisées	Non ; volontairement hors du périmètre
Les hooks sont des composants portables d’Agent Plugins v1	Non ; ils peuvent être des extensions client
OpenAI possède ou contrôle exclusivement Agent Plugins	Non
Le projet est neutre vis-à-vis des fournisseurs et gouverné par la communauté	Confirmé par la gouvernance officielle
La version 1.0.0 est un standard final complètement figé	Non ; la page de spécification est actuellement marquée comme brouillon de travail
Chaque client compatible prend en charge tous les composants et transports MCP	Non
ChatGPT, Codex, VS Code, Cursor, GitHub Copilot et Kiro sont répertoriés comme compatibles	Confirmé sur la page de compatibilité actuelle

Questions fréquentes

Qu’est-ce qu’Agent Plugins 1.0 ?

Agent Plugins 1.0 est un format de package ouvert et neutre vis-à-vis des fournisseurs pour des extensions d’agents IA réutilisables. Il normalise la manière dont les compétences Agent et les configurations de serveurs MCP sont placées dans un répertoire de plugin portable.

Agent Plugins est-il un standard exclusif à OpenAI ?

Non. OpenAI participe au projet et prend en charge ce format dans ChatGPT et Codex, mais le projet officiel est gouverné par la communauté et neutre vis-à-vis des fournisseurs. L’équipe initiale des mainteneurs principaux comprend des personnes associées à Amazon, Cursor, Microsoft, OpenAI et Vercel.

Quels fichiers sont requis pour un Agent Plugin ?

Chaque plugin nécessite un fichier racine plugin.json. Les compétences peuvent être stockées dans skills/, les serveurs MCP peuvent être décrits dans un mcp.json racine ; les fonctionnalités spécifiques au client peuvent utiliser des extensions avec espaces de noms.

Agent Plugins remplace-t-il MCP ?

Non. MCP définit toujours le protocole utilisé entre les clients et les serveurs MCP. Agent Plugins définit une manière portable d’empaqueter les configurations de serveurs MCP et d’autres composants d’agents réutilisables.

Les hooks font-ils partie d’Agent Plugins 1.0 ?

Non, pas en tant que composants portables de base. La version 1 normalise les compétences et les serveurs MCP ; les hooks peuvent être implémentés via des espaces de noms d’extension spécifiques au client, là où ils sont pris en charge.

Quels clients prennent en charge Agent Plugins ?

La page officielle de compatibilité répertorie actuellement VS Code, Cursor, GitHub Copilot, ChatGPT et Codex, ainsi que Kiro. Ils prennent en charge différents transports MCP, il convient donc de consulter la matrice en temps réel.

Un Agent Plugin se comporte-t-il de la même manière sur chaque client ?

Non. Le standard couvre la découverte des packages et les composants portables, mais pas les modèles, les interfaces de permissions, les flux d’authentification, les places de marché ou les comportements d’exécution spécifiques au client. Un plugin peut être portable, sans pour autant produire le même comportement d’exécution.

Agent Plugins 1.0 est-il considéré comme une version finale ?

1.0.0 est la version actuellement publiée et fournit les schémas standard. La page de spécification marque le statut du projet comme « brouillon de travail », les développeurs doivent donc suivre les processus publics de gouvernance et de versionnement.

Outils associés

• Agent Plugins : site officiel de documentation du format de package portable Agent Plugins.
• Agent Skills : spécification ouverte pour les composants de compétences réutilisables dans les plugins d’agents.
• Model Context Protocol : protocole utilisé par les clients et serveurs MCP empaquetés via mcp.json.
• Plugins ChatGPT : système de plugins actuel d’OpenAI pour les environnements de travail ChatGPT et Codex.
• Plugins d’agent VS Code : documentation Microsoft sur le chargement de plugins d’agent dans VS Code.
• Plugins GitHub Copilot : documentation GitHub sur les packages de plugins et la prise en charge de la spécification ouverte des plugins.

Liens associés

• Spécification Agent Plugins 1.0.0 : contraintes normatives complètes du format portable actuel.
• Créer un Agent Plugin : tutoriel officiel minimal et guide de structure de package.
• [Clients compatibles](https://agent-plugins.org/

org/compatible-clients) : la matrice de support actuelle pour VS Code, Cursor, GitHub Copilot, ChatGPT et Codex, ainsi que Kiro.

• Dépôt de spécification des plugins d'agents : schémas publics, gouvernance, problèmes, discussions et code source de la spécification.
• Gouvernance des plugins d'agents : charte de gouvernance communautaire et règles de neutralité vis-à-vis des fournisseurs.
• Licence des plugins d'agents : conditions de licence pour la spécification, la documentation, les schémas et le code.
• Plugins OpenAI dans ChatGPT et Codex : documentation produit d'OpenAI sur les plugins, applications, compétences et contrôles d'espace de travail.

Résumé

Le plugin d'agent 1.0 résout un problème concret dans l'écosystème croissant des agents : les développeurs conditionnent aujourd'hui les mêmes compétences et intégrations MCP de manière différente pour chaque client.

La spécification définit un noyau compact et portable — le fichier obligatoire plugin.json, les compétences dans le répertoire skills/, la configuration MCP dans mcp.json, les règles d'empaquetage, les schémas versionnés et les extensions client avec espaces de noms. La distribution, les places de marché, les autorisations, l'authentification et l'interface utilisateur restent contrôlées par le client.

Le projet répertorie le support de plusieurs clients d'agents majeurs, notamment VS Code, Cursor, GitHub Copilot, ChatGPT et Codex, ainsi que Kiro. Cela en fait bien plus qu'un simple format de plugin spécifique à OpenAI, même si OpenAI figure parmi les mainteneurs participants.

La version 1.0.0 est le contrat actuellement publié, bien que la page de spécification la marque encore comme un brouillon de travail. Les développeurs peuvent l'adopter dès maintenant, mais doivent suivre les processus publics de gouvernance et de versionnement.

Le changement principal est simple : au lieu de réécrire les mêmes extensions d'agent pour chaque plateforme, les développeurs peuvent désormais considérer leurs compétences et intégrations MCP comme des composants portables dotés d'une structure de paquet unifiée.