Nom : greet Description : salue l'utilisateur et propose son aide. --- Salue brièvement l'utilisateur et demande comment l'aider. Si le plug...

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.
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.
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 :
Sans que l'auteur ait besoin de placer ces composants portables dans des structures totalement différentes pour chaque client.
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 :
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 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 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 :
Les mainteneurs principaux initiaux actuellement listés sur la page d'accueil du projet proviennent de :
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 page de compatibilité officielle répertorie actuellement :
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.
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 :
À 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.
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.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
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.
les modèles
Un même plugin peut se comporter différemment selon le modèle qui le charge.
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.
La gestion d'OAuth et des identifiants reste du ressort du client.
Les clients peuvent implémenter différents sous-ensembles.
Ceux-ci restent définis par le client.
La distribution reste hors du périmètre de la spécification de base.
L'inclusion d'un chemin dans le package ne signifie pas une isolation au moment de l'exécution.
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.
Les plugins portables peuvent étendre la portée de la distribution.
Cela augmente également l'importance de configurations de sécurité par défaut.
É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.
Ne vous fiez pas à une sortie du répertoire racine du plugin pour accéder à des fichiers arbitraires de l’hôte.
Les serveurs stdio peuvent lancer des processus.
Les utilisateurs et les administrateurs d’entreprise doivent savoir ce qu’ils installent.
Un plugin qui ne nécessite que des droits en lecture ne doit pas demander d’opérations en écriture.
Les serveurs MCP distants doivent avoir des politiques claires en matière de propriété, de confidentialité et d’utilisation des données.
Même si la structure des répertoires reste valide, des changements de comportement du serveur peuvent constituer des modifications cassantes.
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.
Déclarez explicitement Agent Plugins 1.0.0 dans plugin.json.
Placez les compétences Agent portables dans :
skills//SKILL.md
Utilisez un fichier racine :
mcp.json
plutôt que de dépendre uniquement des fichiers de configuration natifs du client.
Migrez les identifiants vers le système d’authentification de chaque client.
L’interopérabilité doit être vérifiée par des démonstrations réelles, et non tenue pour acquise.
É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é.
| 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 |
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.
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.
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.
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.
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.
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.
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.
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.
mcp.json.org/compatible-clients) : la matrice de support actuelle pour VS Code, Cursor, GitHub Copilot, ChatGPT et Codex, ainsi que Kiro.
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.
Partez d’une phrase et obtenez un site complet en quelques minutes.