Piloter betool depuis Claude (serveur MCP)

betool expose un serveur MCP (Model Context Protocol) : un client MCP externe — Claude Code, Claude Desktop, ou toute application compatible — peut lire la configuration de votre organisation et proposer des changements en langage naturel (créer/éditer un pipeline, un rôle, une mission, une évaluation…). C'est l'équivalent d'un assistant qui configure betool avec vous, sous gouvernance complète.

Deux façons de se connecter, au même endpoint https://platform.betool.ai/mcp :

• une clé API MCP dans l'en-tête Authorization — le plus simple pour Claude Code ;
• OAuth 2.1 + PKCE — pour les applications tierces, sans manipuler de secret.

Ce que Claude peut faire

• Lire : inventaire des modèles, graphe et nœuds d'un pipeline, contrats de configuration, rôles/missions, outils disponibles, base de connaissances.
• Lire vos données : les bases de données no-code de votre organisation — bases, tables, colonnes et lignes. Le client les découvre lui-même ; une clé n'est pas limitable à un sous-ensemble de bases.
• Proposer : via l'outil proposals.create, une proposition de changement en attente — vous l'acceptez ou la refusez dans l'interface.
• Écrire des données (périmètre Complet) : créer, mettre à jour ou réserver une ligne d'une de vos bases, après votre accord explicite dans la conversation. Contrairement à la configuration, une écriture de donnée n'est pas versionnée — elle ne se restaure pas.
• Parler à vos modèles (périmètre Complet) : tenir une conversation multi-tours avec un modèle que vous avez explicitement ouvert aux agents externes — voir plus bas.

Claude découvre le contrat exact de chaque nœud (champs, valeurs autorisées) avant de proposer : pas d'invention, pas de configuration invalide.

Créer une clé MCP

Réservé aux administrateurs de l'organisation : une clé porte une autorité sur toute l'organisation.

1. Dans betool, ouvrez Paramètres → MCP.
2. Donnez un nom à la clé et choisissez son périmètre :
   • Lecture seule — lit la configuration et les données de vos bases, relit les fils ouverts par ce canal, ne propose rien ;
   • Lecture + propositions (recommandé) — lit et soumet des propositions, que vous validez dans betool ;
   • Complet — peut aussi résoudre ses propres propositions, écrire dans vos bases de données et converser avec vos modèles, après votre accord dans la conversation du client.
3. La clé brute n'est affichée qu'une seule fois — copiez-la immédiatement (elle n'est plus jamais relisible). Vous pouvez révoquer une clé à tout moment.

Les mêmes trois périmètres existent pour OAuth ; c'est vous qui les choisissez à l'écran de consentement.

Brancher Claude Code

Ajoutez le serveur MCP betool à Claude Code (la clé passe dans l'en-tête Authorization) :

claude mcp add betool \
  --transport http \
  --header "Authorization: Bearer <votre-clé-MCP>" \
  https://platform.betool.ai/mcp

Demandez ensuite à Claude, en langage naturel : « inspecte mon pipeline X et propose une étape qui résume le ticket avant l'envoi ». Claude lit la configuration, compose une proposition, et vous la validez dans betool.

Parler à vos modèles

Lire et proposer, c'est configurer betool. Une IA externe peut aussi s'en servir : tenir une vraie conversation avec un de vos modèles, tour après tour, comme le ferait n'importe quel client sur votre chat. De quoi faire éprouver un assistant par une autre IA, brancher betool derrière un agent partenaire, ou laisser un outil interne interroger un de vos processus en langage naturel.

Quatre outils : conversation.open ouvre ou retrouve un fil, conversation.send envoie un tour et rend la réponse, conversation.poll récupère une réponse qui a pris du temps, conversation.history relit le fil. Ce fil est un contexte betool comme un autre : il apparaît dans vos conversations, le modèle y voit les tours précédents, et vous relisez tout dans l'interface.

Une réponse n'est jamais perdue : si le modèle travaille plus longtemps que l'attente accordée, l'appel rend un ticket et le tour continue côté serveur — il survit même à un redéploiement. L'application relit alors la réponse avec conversation.poll. Renvoyer le message n'accélère rien — et pendant que le tour tourne, l'envoi est refusé.

Enfin, ce canal ne lit que ses propres fils. Un identifiant de conversation venu d'une autre entrée — chat public, téléphone, email — n'est pas lisible ici : les échanges de vos clients ne deviennent pas consultables parce qu'une application MCP est branchée.

Un modèle déjà en place fonctionne sans être retouché. Ce canal pose les mêmes clés qu'un chat : le message arrive dans user_message et l'événement est un on_message ordinaire — vos filtres et les sélections de vos agents continuent donc de marcher. Si le modèle visé a été écrit pour une autre entrée (il lit telegram.text, un objectif, une variable de page…), l'application peut fournir ces clés elle-même via variables : elles entrent dans le flux là où l'autre entrée les aurait posées. Ce qu'elle ne peut pas falsifier, c'est l'identité du tour — qui a parlé et par quel canal : ces clés sont posées par le serveur, et toute tentative est refusée et signalée dans la réponse.

Si le modèle reste muet, regardez son routage. Un modèle qui sert plusieurs canaux branche en général sur l'entrée (filter input.entry_kind == chat_widget…) : un tour arrivant avec l'entrée « agent externe » ne correspond alors à aucune branche, et rien ne répond — sans qu'aucune erreur ne soit levée. Passez as_entry_kind pour être acheminé comme ce canal-là. Cela ne change que la clé de routage : le descripteur de canal et le journal d'audit continuent de dire que le tour vient d'une IA externe, et les capacités réelles du canal s'appliquent toujours.

Un fil traite un tour à la fois. Tant que le tour précédent n'a pas rendu sa réponse, le suivant est refusé avec l'identifiant du tour à relire. Ce n'est pas une limite arbitraire : une réponse est rattachée à sa question par sa position dans le fil, donc deux tours en vol rendraient l'attribution ambiguë — mieux vaut un refus clair qu'une réponse plausible et fausse.

Brancher une application tierce (OAuth 2.1)

Une clé en en-tête convient à Claude Code. Les autres clients — Claude Desktop, ChatGPT, un éditeur, votre propre application — se connectent par OAuth 2.1 + PKCE, sans que personne ne manipule de secret. Vous n'avez rien à préparer : il n'y a pas de client à déclarer, ni d'identifiant à nous demander.

Côté utilisateur, le parcours tient en trois écrans :

1. Dans l'application, ajoutez le serveur MCP https://platform.betool.ai/mcp.
2. Votre navigateur s'ouvre sur un écran de consentement betool : il nomme l'application qui demande l'accès, l'organisation concernée, et où le retour aura lieu. Vérifiez ces trois informations — surtout si vous appartenez à plusieurs organisations.
3. Choisissez le périmètre que vous accordez, puis Autoriser. L'application ne reçoit jamais plus que ce que vous cochez, même si elle en avait demandé davantage.

Pour les intégrateurs, la découverte est entièrement automatique et conforme aux RFC : un appel non authentifié sur /mcp renvoie un 401 portant l'en-tête WWW-Authenticate avec l'adresse de nos métadonnées (RFC 9728), lesquelles pointent l'autorisation, l'échange de jetons, l'enregistrement dynamique du client (RFC 7591) et la révocation (RFC 7009). PKCE S256 est obligatoire, les jetons d'accès durent une heure et le jeton de rafraîchissement tourne à chaque usage.

# Ce qu'un client fait tout seul — utile pour vérifier depuis un terminal.
curl -i -X POST https://platform.betool.ai/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize"}'
# -> 401 + WWW-Authenticate: Bearer ... resource_metadata="..."

curl -s https://platform.betool.ai/.well-known/oauth-authorization-server

Un jeton n'est valable que pour betool : réutilisé ailleurs, il est refusé (RFC 8707). Et si un jeton de rafraîchissement déjà consommé est présenté une seconde fois — la signature d'un jeton dérobé — toute la session est révoquée et l'utilisateur doit autoriser à nouveau.

Applications connectées : voir et débrancher

Dans Paramètres → MCP, la section Applications connectées liste ce qui est branché sur votre organisation : le nom de l'application, le périmètre accordé, qui l'a autorisée et la date du dernier usage. Un bouton Débrancher coupe l'accès immédiatement — tous les jetons de cette application, pour votre organisation uniquement.

Une même application peut être branchée par plusieurs organisations : la débrancher chez vous n'affecte personne d'autre. Une application peut aussi se débrancher elle-même.

Périmètre & isolation

• Par défaut, une clé n'opère que sur votre propre organisation — l'org cible est forcée côté serveur ; vous ne passez jamais d'identifiant d'organisation en argument.
• Les clés vendor (organisation backoffice) peuvent cibler une autre organisation, sous le consentement explicite de celle-ci et avec traçabilité — utile pour un usage d'éditeur multi-tenant.

Journal d'audit

Chaque appel d'outil (externe via MCP et interne) écrit une ligne d'audit : qui, quel outil, quel canal, quel périmètre, quel résultat, quelle latence. Consultable dans Paramètres → MCP, scopé strictement à votre organisation.

À venir

• Exposition fine, par outil, de la surface accessible via MCP.
• Flux serveur→client (SSE) pour les notifications du serveur.

Voir aussi

• API Admin — automatiser betool depuis vos propres systèmes.
• Sécurité & conformité — le modèle de gouvernance des propositions.