Mes 3 MCP VFG : carte, bus et wizz — ce que l'agent voit vraiment

Mes 3 MCP VFG : carte, bus et wizz — ce que l'agent voit vraiment — 2026-06-16

J'ai branché Cursor sur mon fleet perso via trois serveurs MCP hébergés en prod (mcp-docs.vfg.lol, gandalf.vfg.lol). Ce n'est pas un gadget : c'est la façon dont l'agent arrête de deviner le contexte et commence à lire la même carte, le même bus et les mêmes SSOT que moi. Voici ce qui change concrètement, ce qui ne marche pas encore, et comment je compte continuer à l'intégrer.

Pour situer le protocole MCP en général, j'ai trouvé utile How to Use MCP in Cursor: The Missing Manual (2026) — surtout les passages sur la gouvernance (rules Cursor), le « token bloat » (trop d'outils = modèle moins fiable) et le passage chatbot → agent actif. Ma règle workspace vfg-mcp-docs.mdc joue ce rôle de gouvernance pour VFG.

Le problème qu'on résolvait

Avant les MCP, chaque session Cursor repartait de zéro. L'agent grepait STATUS.md dans un repo au hasard, confondait « idée #43 » avec une issue GitHub (alors que c'est IdeaPit), ou inventait des ports. J'avais une dizaine de sources de vérité concurrentes — exactement ce que le modèle « 3 niveaux » du workspace était censé éviter.

Les MCP ne remplacent pas le code local. Ils cadrent où l'agent cherche la vérité avant de coder.

Les trois couches

Ordre obligatoire pour l'agent : docs → feed → local. La phrase que je retiens : « Lis vfg-docs avant grep local ; vfg-feed pour le bus ; vfg-gate seulement pour agir. »

Config Cursor : D:\VFG_PT__\.cursor\mcp.json (3 URLs avec token path secret — ne pas committer ailleurs).

Scénario 1 — Reprendre un chantier (VFG_Hero)

Ce que je dis à Cursor : « Boot VFG_Hero, où en est le quatuor ? »

Ce que l'agent doit faire :

1. vfg_boot_context avec project: "VFG_Hero" — markdown boot (STATUS extrait, session resume, watchlist)
2. Si besoin de creuser : vfg_search_docs sur un mot-clé (« pre-post-alphatango », « C4b »)
3. SSOT ports : vfg_ssot_get { domain: "services", key: "ports" }

Limite : vfg_search_docs indexe une slice packée des docs git (allowlist), pas le code src/. Max 16 hits, extraits courts. Si hits vides → slice prod périmée → npm run mcp:docs:pack + push VPS.

Scénario 2 — Hotfix depuis une idée IdeaPit (#N)

Ce que je dis : « hotfix idée #43 » ou « idea #43 ».

Ce que l'agent doit faire :

1. vfg_ideas avec { id: 43 } sur vfg-feed — en premier, jamais gh issue
2. Lire text, project, tags → router le bon repo (souvent VFJah_Messenger)
3. Skill dev-idea-hotfix pour le reste du flux

Piège classique : #43 = numéro IdeaPit SQLite (ou relay_id hub inbox), pas GitHub. Les repos VFG n'ont pas d'issues #43.

Pour le sprint VFJah / #bettermsn : vfg_ideas_queue avec nextOnly: true donne la prochaine tâche INBOX recommandée.

Scénario 3 — Wizz depuis Cursor (AlphaTango)

Ce que je dis : « wizz moi » ou « vérifie VFGate puis wizz ».

Ce que l'agent doit faire :

1. vfg_gate_health — santé bridge + route vfjah.wizz + adapters OSC
2. vfg_wizz_notify — publie /matrice/wizz + /matrice/levelup via VFGate → UDP Chataigne

Limites : cooldown 5 secondes entre wizz ; VFGate et le PC fixe OSC doivent être up. Même chaîne que MSN Didou — Cursor rejoint la boucle show.

Inventaire complet — 21 outils

vfg-docs (5, lecture seule) : vfg_boot_context · vfg_search_docs · vfg_ssot_get · vfg_timeline · vfg_graph_neighbors

vfg-feed (9, lecture seule) : vfg_snapshot · vfg_ideas · vfg_ideas_queue · vfg_acts · vfg_health · vfg_events_recent · vfg_hotfix_catalog · vfg_hotfix_runbook

vfg-gate (7, écriture) : vfg_wizz_notify · vfg_osc_publish · vfg_gate_health · vfg_hotfix_deploy · vfg_hotfix_verify · vfg_hotfix_worktree · vfg_hotfix_worktrees

Doc technique condensée : D:\VFG_PT__\.cursor\MCP-README.md · procédures : VFVFGPT/docs/agentique/PROTOCOLES-VALIDES.md §8–§9.

Limites honnêtes

1. Slice doc pas temps réel — le git dirty local n'est pas visible tant qu'on n'a pas repacké et redéployé la slice prod.
2. Token bloat — 21 outils, c'est raisonnable ; éviter d'ajouter des MCP génériques en plus sans gouvernance.
3. Drift Cursor — le cache descripteurs MCP dans Cursor peut être en retard sur le code (ex. outils hotfix absents jusqu'au Reload MCP après redeploy image).
4. Hotfix deploy R3 — vfg_hotfix_deploy sans MCP_HOTFIX_EXEC=1 retourne le runbook, n'exécute pas docker sur le VPS. confirmR3: true obligatoire.
5. Worktrees hotfix — état en mémoire serveur, perdu au restart conteneur.
6. EVT devlog — les MCP ne remplacent pas swarm-notify.ps1 POST-only pour journaliser.

Ce que les MCP ne font pas

• Grep/read sur le code applicatif (src/, tests, composants) — outils locaux normaux
• Publier des EVT sur le bus — reste swarm-notify.ps1
• Lire Lucien (exclu allowlist, no-touch)
• Traiter le wiki narratif comme SSOT — STATUS.md > index.live.json > DERNIERE-INFO

Rituals pour continuer

Dépannage rapide

Suite

• Reload MCP Cursor pour exposer les outils hotfix/queue si absents du cache descripteurs
• Refresh slice doc hebdo après gros merges : npm run mcp:docs:pack + deploy VPS