BOSSCORE MCP PACK

Paquet MCP modulaire de l’écosystème BOSS : WordPress, fichiers, Git, déploiement, exécution contrôlée, santé et coordination multi-agents. Cross-platform Windows + Linux.

Principes

• Inventaire dynamique : 113 outils chargés avec le profil full au 24 juillet 2026. Toujours vérifier avec boss_tool_inventory; ne pas figer ce total dans les procédures d’exploitation.

• Profils composables : wordpress, files, full.

• Deux transports : stdio pour les agents locaux et HTTP/SSE pour les connecteurs distants.

• Moindre privilège : scopes OAuth, claims PACTE, chemins et hôtes bornés.

• Plans persistants : les plans de déploiement sont stockés sur disque, associés à l’acteur OAuth et consommés une seule fois.

• Aucun secret brut dans les plans : l’acteur est identifié par sujet OAuth ou empreinte SHA-256 non réversible du jeton.

Related MCP server: TanukiMCP

Lancement — stdio

Windows (PowerShell)

$env:WORDPRESS_URL = "https://core.bosserpnext.com"
$env:WORDPRESS_USERNAME = "boss"
$env:WORDPRESS_APP_PASSWORD = "..."
$env:DEPLOY_TOKEN = "..."
$env:BOSSCORE_WORKSPACE = "H:\...\companies"
python.exe server.py

Linux / VPS

export WORDPRESS_URL="https://core.bosserpnext.com"
export WORDPRESS_USERNAME="boss"
export WORDPRESS_APP_PASSWORD="..."
export DEPLOY_TOKEN="..."
export BOSSCORE_WORKSPACE="/home/bomoja/repos/companies"
python3 server.py

Lancement — HTTP/SSE

source ~/repos/companies/.env
python3 server_http.py --host 127.0.0.1 --port 8765

Le connecteur public utilise https://vps.bosserpnext.com/sse derrière NGINX. En production, activer BOSSCORE_MCP_ENFORCE_AUTH=1.

Cycle de déploiement multi-agents

Le cycle supporté est :

plan → redémarrage MCP → status → execute → verify

Conditions :

1. BOSSCORE_MCP_STORE_DIR doit pointer vers un répertoire persistant et accessible au compte de service.

2. BOSSCORE_DEPLOY_PLAN_TTL vaut 1800 secondes par défaut.

3. Le même acteur OAuth doit reprendre le plan après redémarrage.

4. Un autre acteur reçoit une erreur bornée et ne peut ni voir, ni exécuter, ni vérifier le plan.

5. Un mauvais confirm_token ne consomme pas le plan.

Runbook de récupération

Après interruption ou redémarrage :

1. Vérifier le service et l’inventaire réel des outils.

2. Appeler boss_deploy_status(plan_id=...) avec le même connecteur OAuth.

3. Si le statut est draft, reprendre avec le confirm_token initial.

4. Si le statut est success, lancer boss_deploy_verify.

5. Si le plan est expiré, étranger ou introuvable, créer un nouveau plan.

6. Ne jamais copier le magasin de plans vers un autre acteur ni modifier son champ actor.

7. Si le fichier du magasin est illisible, conserver une copie de preuve, corriger les permissions, puis recréer le plan. Ne jamais injecter manuellement un plan dans le JSON.

8. Le redémarrage du service doit passer par l’unité systemd et le runbook administrateur; aucun contournement par processus parallèle.

QA

python3 -m pytest

La suite ne dépend pas de chemins Windows externes ni de pytest-asyncio.

Différences Windows / Linux