Custom Tools (MCP)

MCP (Model Context Protocol) est un standard ouvert qui décrit comment un agent IA appelle des tools côté serveur. Un MCP server expose une liste de tools via une route HTTP unique, en JSON-RPC 2.0.

Gilbert est déjà un MCP server (voir Bridge MCP). Avec les custom tools, Gilbert devient aussi un client MCP : il peut consommer n’importe quel autre MCP server que ton équipe expose ou utilise.

• Notion MCP officiel : recherche dans ton workspace Notion, lecture de pages, création de blocs.
• Linear MCP : création de tickets, recherche d’issues.
• GitHub MCP : repo search, code lecture, issues.
• Atlassian MCP : Jira / Confluence.
• Ton MCP custom : wrap n’importe quelle API interne (CRM, ERP, wiki maison) en quelques heures via le SDK officiel.

Plutôt que de saisir manuellement une URL et un type d’authentification, la page Console → Workspace → MCP Servers affiche aussi une galerie de connecteurs préconfigurés et vérifiés par l’équipe Solve (Notion, Linear, Airtable, Google Drive, Google Chat, Atlassian, HubSpot, Sentry, Vercel, Stripe). Un clic sur Ajouter pré-remplit tout (URL, scopes, authentification) sans qu’un admin ait à connaître les détails techniques du connecteur.

Un membre non-admin voit la même galerie en lecture seule, avec un bouton Demander un connecteur qui prévient l’équipe Solve plutôt que d’ajouter directement (l’ajout reste réservé aux admins). Si l’endpoint d’un connecteur du catalogue correspond déjà à un serveur existant dans le workspace, Gilbert le signale (Ajouter quand même pour forcer, sinon rien n’est dupliqué silencieusement).

Sous le capot, le catalogue ne change rien à la mécanique de connexion : il ne fait que pré-remplir la même fiche workspace que l’ajout manuel décrit ci-dessous, avec les valeurs vérifiées par Solve. Une fois le serveur créé, tout se passe exactement comme pour un serveur ajouté à la main, y compris le consentement OAuth par membre pour les connecteurs qui l’exigent.

Va dans Console → Workspace → MCP Servers → Ajouter. Renseigne :

• Slug : identifiant kebab/snake court (acme_internal). Apparaîtra dans le nom des tools côté chat.
• URL endpoint : URL HTTPS du MCP server. Le MCP en stdio (local) n’est pas supporté : Gilbert tourne sur Vercel et a besoin d’une URL publique.
• Authentification : généralement Bearer token. Le token est chiffré AES-256-GCM côté DB avec une clé d’environnement dédiée.

# 1. Lance Notion MCP officiel (Docker)
docker run -i --rm \
  -e NOTION_API_KEY=secret_xxxxx \
  mcp/notion

# 2. Dans Gilbert Console → Workspace → MCP Servers → Ajouter
#    - URL : https://ton-tunnel.example.com  (ou self-hosted publique)
#    - Auth : Bearer + token
#    - Clique "Tester la connexion" → la liste des tools apparaît
#    - Clique "Créer"

Certains MCP servers (Notion, Linear, Google Drive et la plupart des intégrations SaaS grand public) n’acceptent pas de Bearer token statique : chaque personne doit se connecter avec son propre compte. Pour ce cas, choisis Authentification → OAuth (par membre) à la création du serveur. Renseigne l’URL endpoint et, si besoin, les scopes à demander au consent (un par ligne). Aucun token n’est saisi côté admin : il n’y a rien à chiffrer à cette étape, chaque membre autorisera son propre accès ensuite.

Une fois le serveur créé, chaque membre du workspace se rend sur Mon compte → MCP Servers et clique Connecter. Il est redirigé vers l’écran de consentement du fournisseur (Notion, Linear…), approuve les scopes demandés, puis revient sur Gilbert connecté. Sa connexion est strictement personnelle : elle n’ouvre jamais l’accès de ses collègues, et son token n’est visible que par lui.

• Statuts de connexion : « Pas connecté » → « Connecter » ; « Connecté » → « Déconnecter » (les tokens sont effacés immédiatement, on peut se reconnecter à tout moment) ; « À reconnecter » si le fournisseur a révoqué l’accès ou si le refresh token a expiré.
• Signaler sa connexion aux collègues : une case à cocher optionnelle, une fois connecté, permet d’indiquer aux autres membres du workspace que ce connecteur est déjà utilisé par quelqu’un dans l’équipe (utile pour savoir qui solliciter en cas de question). En dessous d’un petit nombre de collègues connectés, ce signal reste entièrement masqué pour ne jamais permettre de déduire qui précisément est connecté.

Gilbert appelle tools/list au moment du create et stocke la liste en cache (discovered_tools jsonb). Au prochain message du chat, ces tools sont injectés dans le toolset Anthropic et le LLM peut décider de les appeler, exactement comme les tools natifs (gmail_search, calendar_list_today, etc.).

Le cache ne s’invalide pas tout seul. Quand tu mets à jour ton MCP server (nouveau tool ou ancien tool changé), va dans l’édition du serveur et clique Refresh.

Les tools custom sont préfixés mcp_<slug>__<tool> pour éviter les collisions avec les tools natifs Gilbert. Le LLM les voit avec ce préfixe ; côté UI, Gilbert affiche le label slug · tool dans la bulle d’exécution.

// Un MCP server enregistré avec slug = "acme_internal"
// qui expose un tool MCP nommé "search_wiki"
// devient côté Gilbert :

mcp_acme_internal__search_wiki

// Gilbert peut l'appeler dans le chat sans config supplémentaire :
//   "Cherche dans le wiki Acme la doc onboarding"
//   → Gilbert appelle mcp_acme_internal__search_wiki({ query: "onboarding" })

Au moment de l’appel, Gilbert envoie un JSON-RPC standard :

// Côté MCP server, Gilbert envoie du JSON-RPC 2.0 :

POST https://mcp.acme.com
Content-Type: application/json
Authorization: Bearer <ton-token>

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_wiki",
    "arguments": { "query": "onboarding" }
  }
}

// Réponse attendue (content[] standard MCP) :
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      { "type": "text", "text": "Voici la doc onboarding..." }
    ]
  }
}

Dans /chat, le bouton Connecteurs du composer permet de restreindre, pour la conversation en cours seulement, quels MCP servers du workspace Gilbert peut appeler. Deux modes : Tous (défaut, tous les connecteurs du workspace sont exposés au modèle) ou Choisir (sélection explicite d’un sous-ensemble, y compris aucun). Ce choix est propre à la conversation : ouvrir une nouvelle conversation ou en rouvrir une autre applique sa propre sélection, jamais celle de la conversation précédente.

Si le workspace n’a encore aucun connecteur MCP configuré, le bouton affiche un lien direct vers la page d’ajout côté console plutôt que de disparaître silencieusement.

En mode Choisir, chaque connecteur en OAuth par membre affiche directement ton statut de connexion perso à la place de son identifiant technique : « Connecté », ou « Pas connecté » sous forme de lien qui ouvre la page Mon compte → MCP Servers dans un nouvel onglet pour t’y connecter sans perdre la conversation en cours. Les connecteurs en Bearer token ou sans authentification (« Aucune », pas de notion de connexion individuelle) continuent d’afficher leur identifiant comme avant.

Seul un admin du workspace peut ajouter, modifier ou supprimer un MCP server. Les members en voient l’existence (pour comprendre quels tools Gilbert peut utiliser) mais ne peuvent pas en créer.

Côté tools : tu peux désactiver individuellement les tools découverts qui ne t’intéressent pas (case à cocher dans l’édition). Par défaut, tous les tools de tools/list sont actifs.

La même fiche règle les confirmations interactives et contient une liste séparée d'outils explicitement autorisés. Cette liste permet à un tool de s'exécuter sans confirmation ; elle ne suffit pas, à elle seule, à le rendre utilisable par une routine autonome.

Un admin du workspacedéploie un MCP server pour toute l'équipe (même endpoint, même token partagé). Chaque membre peut le personnaliser depuis Mon compte → MCP Servers sans affecter les autres : le server workspace reste inchangé, seul l'utilisateur voit ses propres réglages.

Deux choses sont overridables par membre :

• Token d'authentification: remplace le token Bearer configuré par l'admin par ton propre token (PAT GitHub perso, credentials de ton compte sandbox, etc.). L'endpoint reste celui du workspace ; seul le header Authorization change.
• Allowlist de tools: restreins la liste des tools actifs pour toi (sous-ensemble de l'allowlist admin). Un membre ne peut pas élargir au-delà de ce que l'admin a autorisé.

• Tokens chiffrés AES-256-GCM avec rotation de version supportée (MCP_TOKEN_KEY). Aucun token n’est jamais renvoyé au client : tout passe par les API routes server-side.
• Anti-SSRF : Gilbert refuse de joindre localhost, les IPs privées RFC1918, les addresses link-local. Un MCP self-hosted derrière un firewall privé ne marchera pas depuis Vercel.
• Timeout 30 secondes par appel, body cap 1 MB.
• Trust boundary : un MCP server malveillant peut renvoyer du texte qui se présente comme une instruction au LLM («ignore previous instructions»). Comme pour fetch_url, le résultat est encapsulé en tool_result. Reste prudent quand tu connectes un MCP server tiers que tu ne contrôles pas.
• RLS : un member d’un workspace A ne peut jamais appeler un MCP server enregistré sur le workspace B, même en forgeant un nom de tool : le dispatch resolve par (workspace_id, slug) et non par préfixe seul.

Le plus simple : utiliser le TypeScript SDK et déployer sur Vercel/Cloudflare Workers/n’importe quel runtime Node. L’endpoint doit accepter du POST JSON-RPC 2.0 et répondre aux méthodes initialize, tools/list, tools/call.

La doc officielle MCP couvre le bootstrap en quelques minutes : modelcontextprotocol.io/quickstart.