Politique Zero-Tokens MCP

Principe fondamental

Un MCP configuré dans config.yaml = chargé à CHAQUE session = 8K+ tokens gaspillés.

Un MCP invoqué via une skill = 0 tokens tant que la skill n’est pas utilisée.

→ Jamais de nouveau MCP permanent dans config.yaml. Le seul MCP permanent toléré est coolify (HTTP, léger, ~500 tokens, indispensable pour l’infra VPS).

Tout nouveau service externe (GitHub, Playwright, Linear, Notion, Slack, Jira, base de données, etc.) doit suivre ce patron :

Skill Hermes → CLI / API directe (curl, psql, gh, gog, ...) → 0 tokens overhead

État actuel

MCP permanent (config.yaml) — 1 seul, toléré

Skills Hermes existantes — 0 tokens overhead

Total tokens économisés par session : 32K+ (≈ réduction de 40-60% de la fenêtre de contexte).

Top MCPs recommandés + leurs alternatives skill

1. 🎭 Playwright — Automatisation navigateur

Quand l’utiliser : Scraping de sites JS-heavy (Centris.ca, Workday, LinkedIn), tests E2E, QA automatisée

Alternative skill : 3 options, de la plus légère à la plus complète :

Option A — Outils navigateur natifs Hermes (recommandé pour le scraping ad-hoc)
  ⚡ 0 dépendance, 0 tokens, déjà disponible
  → browser_navigate / browser_click / browser_vision / browser_console

Option B — Playwright CLI (pour scripting reproductible)
  ⚡ Le binaire `npx playwright` est disponible, 0 tokens sauf invocation
  → Scripts de test, capture d'écran automatisée, parcours utilisateur

Option C — API directe via curl sur un service Playwright (avancé)
  ⚡ Nécessite un service Playwright en écoute (serveur MCP ou standalone)
  → Usage intensif avec sessions persistantes

Patron de skill Playwright minimale :

# capture-page.sh — Script stocké dans la skill sous scripts/
npx playwright install chromium 2>/dev/null
npx playwright codegen "$1"  # OU
cat > /tmp/test.spec.ts << 'EOF'
import { test, expect } from '@playwright/test';
test('visit', async ({ page }) => {
  await page.goto('$URL');
  console.log(await page.title());
});
EOF
npx playwright test /tmp/test.spec.ts --reporter=list 2>&1 | tail -20

🗄️ PostgreSQL / Base de données — Accès bases Coolify

Quand l’utiliser : Debug bases de données hébergées sur Coolify, requêtes ad-hoc, migrations

Alternative skill : Pas de skill séparée. Les credentials sont accessibles via le MCP Coolify permanent :

# Obtenir les identifiants via le MCP coolify (déjà disponible)
mcp_coolify_get_database(uuid="foc8wkc004wskk0okskskcg8")
# → postgres_user, postgres_db, image, status

# Se connecter avec psql (si installé sur le host) :
PGPASSWORD=<password> psql -h <host> -p <port> -U <user> -d <db> -c "SELECT ..."

# Démarrer / arrêter via Coolify API :
curl -X POST "https://cool.iatuto.com/api/v1/databases/<uuid>/start"

Règle : Ne créer une skill PostgreSQL que si tu fais des requêtes SQL régulières. Pour un usage ponctuel (1-2x/mois), les identifiants via Coolify MCP suffisent.

→ Voir coolify-gateway → references/agent-ssh-unreachable.md pour le diagnostic complet des DB standalones.

3. 📋 Linear — Gestion de tickets

✅ Déjà fait. Skill productivity/linear avec GraphQL via curl + script Python. Voir la skill pour la doc complète.

Tokens économisés : 6K/session vs MCP Linear.

4. 📝 Notion — Base de connaissances

✅ Déjà fait. Skill productivity/notion avec API Notion via curl. Voir la skill pour la doc complète.

5. 📧 Google Workspace — Gmail, Drive, Sheets, Docs

✅ Déjà fait. Skill openclaw-imports/gog avec CLI gog. Voir la skill pour la doc complète.

Alternative script : /home/bf/openclaw-workspace/scripts/log-change-sheets.py pour les logs Google Sheets via REST API.

6. ⚡ n8n — Workflows automation

Quand l’utiliser : Lancer des workflows, vérifier leur état, créer des webhooks

Alternative skill : API REST n8n via curl

# L'instance n8n tourne sur Coolify (vérifier l'URL exacte)
curl -s "https://n8n.iatuto.com/api/v1/workflows" \
  -H "Authorization: Bearer $N8N_API_KEY" | jq '.[] | {id, name, active, createdAt}'

Pondération : Rarement nécessaire depuis Hermes (n8n est autonome). Créer une skill le jour où c’est utile.

7. 💬 Slack — Messagerie d’équipe

Quand l’utiliser : Envoyer des notifications, chercher dans l’historique, gérer les canaux

Alternative skill : Slack Web API via curl

# Envoyer un message
curl -s -X POST https://slack.com/api/chat.postMessage \
  -H "Authorization: Bearer $SLACK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"channel":"#general","text":"Hello from Hermes!"}'

Pondération : Utile si intégré à des workflows DevOps. Pas prioritaire si tu n’utilises pas Slack activement.

8. 🔐 Jira — Tickets (si client/travail l’exige)

Quand l’utiliser : Lier des tickets Jira à des actions DevOps

Alternative skill : Jira REST API via curl

curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
  "https://$JIRA_DOMAIN.atlassian.net/rest/api/3/search?jql=assignee=currentuser()" | jq '.issues[] | {key, fields.summary, fields.status.name}'

Pondération : À créer le jour où tu bosses avec un client qui utilise Jira.

Template de skill MCP zéro-token

Pour tout nouveau service, utiliser ce template :

---
name: mon-service
description: "Service X via CLI/API directe — zéro MCP, zéro overhead."
version: 1.0.0
author: Hermes Agent
license: MIT
platforms: [linux]
metadata:
  hermes:
    tags: [service-x, cli, api]
    category: mon-categorie
---

# Mon Service — via CLI/API

## Pourquoi pas un MCP

| Approche | Tokens overhead | Activation |
|----------|----------------|------------|
| MCP permanent dans config.yaml | ~XK à chaque session | Toujours |
| Skill Hermes (celle-ci) | 0 sauf invocation | À la demande |

## Prérequis

```bash
which curl        # curl est nécessaire
export SERVICE_KEY=...  # API key ou token

Commandes

Action 1 - Description

curl -s -H "Authorization: ..." "https://api.service.com/endpoint"

Action 2 - Description

curl -s -X POST -d '{}' "https://api.service.com/endpoint"

Vérification

curl -s -o /dev/null -w "%{http_code}" "https://api.service.com/health"
# Devrait retourner 200

---

## Règles d'or

1. **Un seul MCP permanent : coolify.** Tous les autres passent par une skill.
2. **Si tu veux un nouveau service → crée une skill d'abord.** Si la skill devient trop lourde/complexe, on reconsidérera un MCP dynamique.
3. **Pas d'exception.** GitHub MCP = 8K. Playwright MCP = 7K. Linear MCP = 6K. Mis bout à bout, 3 MCPs c'est la moitié de ta fenêtre de contexte en moins.
   **⚠️ GitHub MCP particulièrement dangereux :** 8K tokens ET beaucoup de développeurs l'installent par réflexe. Ne pas confondre `git push/pull` (terminal, 0 token) avec le MCP GitHub (API, 8K). La skill `github-ops` couvre tout ce dont on a besoin via `gh` CLI.
4. **CLI > API > MCP.** `gh` est plus rapide que GraphQL curl, qui est plus rapide que npx MCP server. Toujours préférer l'option la plus légère.
5. **Nouveau skill MCP → log dans audit + update cette skill.** La liste des MCP évités doit rester à jour.
6. **Fire and forget.** Si le service n'est pas utilisé dans 30 jours → le skill reste, zéro coût. Pas de ménage nécessaire.
7. **80/20 Claude Code pour les tâches complexes.** Claude Code (abonnement annuel déjà payé) = 80% du travail lourd. Hermes orchestre seulement. Le pattern `cat file | claude -p "goal:..."` consomme zéro token Hermes pour la réflexion — c'est l'extension naturelle de la politique zero-tokens MCP. Ne JAMAIS faire raisonner Hermes sur une tâche complexe (coûteux en tokens). Déléguer à Claude Code direct.

## Références

- `references/coolify-docker-status.md` — Comment gérer la discrepancy Coolify → Docker (conteneurs sains côté Docker mais marqués unhealthy dans Coolify)