Créer des plugiciels

Un plugiciel permet à toute organisation de la plateforme de donner aux modèles des outils que vous construisez : lire un Google Drive, chercher dans un CRM, ouvrir un billet. Une organisation installe votre plugiciel depuis le marché, et ses requêtes peuvent ensuite offrir vos outils à n’importe quel modèle. Le modèle décide quand les appeler; nous appelons votre serveur et remettons la réponse au modèle.

Étape 1 : Construire le serveur MCP

Votre serveur doit :

• Parler le transport MCP Streamable HTTP, version du protocole 2025-06-18 : du JSON-RPC par POST, avec une réponse en JSON ou en flux d’événements.
• Être joignable à une URL https publique. Les adresses privées et locales sont refusées, et les redirections ne sont pas suivies.
• Répondre à initialize, tools/list et tools/call. Nous lisons jusqu’à 5 pages d’outils.

Quelques limites déterminent ce que vos outils devraient renvoyer :

• Les noms d’outils peuvent contenir des lettres, des chiffres, _, . et -, jusqu’à 64 caractères. Un outil portant un autre nom n’est pas offert.
• Le modèle voit chaque outil sous le nom plugin__<slug>__<tool>, les traits d’union du slug devenant des traits de soulignement. Ce nom doit tenir en 64 caractères : gardez le slug et les noms d’outils courts.
• La description et le inputSchema de chaque outil sont transmis au modèle tels quels. Écrivez la description pour le modèle : dites quand utiliser l’outil et ce qu’il renvoie.
• Les résultats sont du texte. Nous transmettons les blocs de contenu text. Les autres types de contenu sont remplacés par une mention. S’il n’y a pas de texte, nous transmettons structuredContent en JSON. Un résultat avec isError: true parvient au modèle comme une erreur à laquelle il peut réagir.
• Une réponse peut atteindre 1 Mo. Le modèle voit au plus 100 000 caractères d’un résultat; le reste est coupé.
• Un appel a 120 secondes pour répondre.

Outils agents

Un outil peut être un agent. Il peut faire plusieurs étapes de votre côté, comme chercher, lire et résumer, puis répondre une seule fois avec le résultat. Nous l’appelons comme tout autre outil : rien de plus n’est nécessaire pour en construire un. Terminez en moins de 120 secondes et renvoyez une réponse courte que le modèle peut utiliser, pas le journal de chaque étape.

Étape 2 : Choisir comment les organisations se connectent

Votre serveur sait quelle organisation l’appelle seulement grâce à l’identifiant que nous envoyons. Choisissez l’une de ces trois options :

• none : aucun identifiant. À n’utiliser que pour des outils qui servent des données publiques.
• api_key : vous donnez une clé à chaque organisation, qui la saisit à l’installation. Nous l’envoyons à chaque appel dans l’en-tête nommé par auth_header (par défaut Authorization), exactement comme elle a été saisie. Si votre serveur attend Bearer, dites-leur de l’inclure.
• oauth2 : l’organisation se connecte sur votre propre serveur d’autorisation; c’est ainsi qu’elle vous donne accès à son compte Google, par exemple. Nous utilisons le flux par code d’autorisation avec PKCE (S256) et envoyons Authorization: Bearer <access token> à chaque appel.

Pour oauth2, enregistrez cette URI de redirection auprès de votre serveur d’autorisation :

https://autonomousrelay.com/v1/auth/oauth/plugin/callback

Votre point de terminaison de jetons reçoit un POST encodé en formulaire avec client_id, et avec client_secret si vous nous en avez donné un. Il doit répondre en JSON avec access_token. Si la réponse contient expires_in et refresh_token, nous rafraîchissons le jeton une minute avant son expiration. Sans expires_in, nous traitons le jeton comme un jeton qui n’expire pas. Si un jeton expire et ne peut pas être rafraîchi, on demande à l’organisation de se reconnecter.

Étape 3 : Enregistrer le plugiciel

Enregistrez-le dans Plugiciels → Publier du tableau de bord, ou avec une clé de gestion qui a config:write :

curl -X POST https://autonomousrelay.com/v1/plugins \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY" \
  -H 'content-type: application/json' \
  -d '{
    "slug": "drive-search",
    "name": "Drive Search",
    "summary": "Search and read the files in your Google Drive.",
    "publisher": "Example Labs",
    "mcp_url": "https://mcp.example.com/mcp",
    "auth": "oauth2",
    "oauth_authorize_url": "https://auth.example.com/authorize",
    "oauth_token_url": "https://auth.example.com/token",
    "oauth_client_id": "relay-client",
    "oauth_scopes": "drive.read",
    "privacy_url": "https://example.com/privacy",
    "categories": ["productivity", "data"]
  }'

• slug : de 2 à 40 lettres minuscules, chiffres ou traits d’union. C’est ainsi que les requêtes nomment votre plugiciel, et il ne peut pas changer.
• name et publisher : jusqu’à 80 caractères chacun. summary : jusqu’à 280. description : jusqu’à 4 000.
• publisher est votre nom ou celui de votre organisation, et le marché l’affiche comme « Conçu par » sur votre fiche. Les plugiciels que nous concevons portent la mention Officiel et affichent « Conçu par Autonomous Relay »; personne d’autre ne peut publier sous ce nom. Modifier publisher sur un plugiciel publié le renvoie en révision.
• homepage_url et privacy_url : des URL https publiques. Les réviseurs attendent une politique de confidentialité pour tout plugiciel qui traite les données d’une organisation.
• categories : jusqu’à 5 parmi productivity, data, developer, search, communication, finance, marketing, sales, support et other.
• oauth_client_secret : ajoutez-le si votre serveur d’autorisation vous en a donné un. Il est chiffré à l’enregistrement et n’est jamais renvoyé.

Une organisation peut enregistrer jusqu’à 20 plugiciels.

Étape 4 : Le tester en privé

Un nouveau plugiciel est privé : seule votre organisation peut le voir, l’installer et l’utiliser. Vous pouvez donc le tester de bout en bout avant que quiconque puisse le trouver. Installez-le, puis demandez-lui ses outils :

curl -X POST https://autonomousrelay.com/v1/plugins/drive-search/connect \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY"

curl https://autonomousrelay.com/v1/plugins/drive-search/tools \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_MANAGEMENT_KEY"

connect répond avec une authorize_url à ouvrir dans un navigateur. Pour un plugiciel api_key, installez-le avec POST /v1/plugins/{slug}/install et {"credential": "..."}. Pour un plugiciel sans connexion, envoyez un corps vide.

Étape 5 : Le soumettre à la révision

Quand il fonctionne, soumettez-le avec POST /v1/plugins/{id}/submit, ou avec Soumettre à la révision dans le tableau de bord. Il est alors en attente. Un réviseur d’Autonomous Relay l’approuve, ce qui le publie sous Connexions pour que chaque organisation le connecte elle-même, ou le refuse avec une note qui explique pourquoi. Corrigez ce que la note demande et soumettez-le de nouveau. Un logo (PNG, JPEG, WebP ou SVG, d’au plus 64 Ko) peut être ajouté ou changé en tout temps, avec le champ icon, sans nouvelle révision.

Comment les organisations utilisent votre plugiciel

Une fois votre plugiciel installé, une requête le nomme parmi ses tools, avec allowed_tools pour n’offrir que certains de vos outils. Une requête peut nommer jusqu’à 5 plugiciels :

curl -X POST https://autonomousrelay.com/v1/chat/completions \
  -H "Authorization: Bearer $AUTONOMOUSRELAY_API_KEY" \
  -H 'content-type: application/json' \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{"role": "user", "content": "Summarise the Q3 plan in my Drive"}],
    "tools": [{"type": "autonomousrelay:plugin", "plugin": "drive-search"}]
  }'

• 404 : l’organisation n’a pas installé le plugiciel.
• 403 : l’organisation l’a installé mais l’a désactivé.
• 502 : nous n’avons pas pu lister les outils du plugiciel. Le message dit pourquoi, par exemple qu’un plugiciel OAuth n’est pas encore connecté.