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.

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"

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..." }
    ]
  }
}

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.

• 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.