Tools
Ajouter un outil
Comment ajouter un nouvel outil a Agent OS. Arbre de decision, checklist, format doc, et securite.
Ajouter un outil
Chaque outil ajoute de la complexite. Avant d'en ajouter un, prouver qu'il est necessaire.
Arbre de decision
Le besoin existe ?
|
├── Non → Ne rien faire
|
└── Oui → Un outil existant couvre le besoin ?
|
├── Oui → Utiliser l'existant
|
└── Non → Un MCP existe pour ce service ?
|
├── Oui → Installer le MCP
|
└── Non → Developper un MCP custom
ou ajouter un outil CLIRegle : MCP > outil CLI > code custom. Un MCP est preferable car il s'integre nativement avec les agents.
Checklist avant ajout
1. Justification
- Le besoin est documente (quel probleme, quel agent, quelle frequence)
- Aucun outil existant ne couvre le besoin (verifie dans le catalogue MCPs)
- Le cout de maintenance est acceptable
- L'outil est self-hostable ou open-source
2. Technique
- L'outil fonctionne en Docker ou CLI
- Les credentials sont stockees dans le Vault (jamais en clair)
- L'outil a une healthcheck
- L'outil a des logs exploitables
- Le rate limiting est gere (si API externe)
3. Integration
- L'outil est monte dans OpenClaw pour les agents concernes
- Les permissions sont minimales (un agent ne voit que ce dont il a besoin)
- Le fallback est defini (que faire si l'outil est down)
- Les tests d'integration passent
4. Documentation
- Page MDX dans
/docs/tools/ - Ajout dans le tableau de la page Overview
- Ajout dans le catalogue MCPs (si MCP)
- Exemples d'utilisation documentes
Format de documentation
Chaque outil a sa page MDX. Structure standard :
---
title: Nom de l'outil
description: "Une phrase qui dit ce que fait l'outil."
---
# Nom de l'outil
Phrase d'intro : ce que fait l'outil, pourquoi il existe.
## Role
Bullet points : ce que l'outil fait dans le systeme.
## Installation / Config
Comment le deployer et le configurer.
## Utilisation
Commandes, exemples, cas d'usage.
## Limites
Ce que l'outil ne fait pas. Contraintes connues.Securite
Credentials
Toutes les credentials passent par le Vault (Vaultwarden).
Agent → MCP → Vault → credential → Service externeJamais de token en dur dans :
- Les fichiers de config commits
- Les variables d'environnement non-chiffrees
- Les prompts agents
Permissions
Principe du moindre privilege :
| Regle | Exemple |
|---|---|
| Un agent ne voit que ses MCPs | Le Trader ne voit pas l'email MCP |
| Un MCP a les permissions minimales | Le Notion MCP n'a pas acces a toutes les databases |
| Les operations destructives sont loguees | Suppression d'un record = log |
| Les operations couteuses sont limitees | Rate limit sur les appels API |
Audit
Chaque nouvel outil doit repondre a ces questions :
- Quelles donnees transitent ? (sensibles, personnelles, financieres)
- Qui a acces ? (quels agents, quels humains)
- Que se passe-t-il si l'outil est compromis ? (blast radius)
- Les logs sont-ils suffisants pour investiguer un incident ?
Processus complet
1. Identifier le besoin
2. Verifier le catalogue existant
3. Choisir : MCP existant / MCP custom / outil CLI
4. Developper ou installer
5. Configurer dans OpenClaw
6. Stocker les credentials dans Vault
7. Tester (unit + integration)
8. Documenter (page MDX + catalogue)
9. Deployer en production
10. Monitorer les premieres 48hAnti-patterns
| Anti-pattern | Pourquoi c'est mauvais | Alternative |
|---|---|---|
| Ajouter un outil "au cas ou" | Complexite sans benefice | Attendre le besoin reel |
| Outil cloud-only sans fallback | Point de defaillance unique | Self-host ou fallback local |
| Token en dur dans le code | Fuite de credentials | Vault |
| Un outil pour un seul usage | Surcout de maintenance | Script simple |
| Pas de doc | Personne ne sait comment ca marche | Doc obligatoire |