fauguste/boondmanager-mcp-server repository overview

⁠BoondManager MCP Server – Docker Image

Serveur MCP (Model Context Protocol) pour l'API BoondManager en mode HTTP transport. Conçu pour les déploiements distants, gateways MCP et orchestrateurs multi-utilisateurs (LobeChat, Khoj, custom gateways).

158 outils, 6 prompts, 20 ressources exposés via une API HTTP/SSE. Documentation complète sur GitHub⁠.

⁠Image de base

L'image est construite sur node:<LTS actif>-alpine, épinglée par digest multi-arch (Dependabot rafraîchit le digest chaque semaine). Politique : la ligne Node en Active LTS au moment de la release — jamais la ligne « current ». Node 24 est LTS depuis octobre 2025 ; Node 26 ne le devient qu'en octobre 2026, date à laquelle le Dockerfile passera à node:26-alpine. Le serveur lui-même exige Node ≥ 22 (engines), donc l'image de prod tourne toujours sur une version que la CI teste (matrice 22 / 24 / 26).

⁠Images disponibles

Deux registres, même image multi-architecture (linux/amd64 + linux/arm64) :

• Docker Hub : docker.io/fauguste/boondmanager-mcp-server
• GHCR : ghcr.io/silamir/boondmanager-mcp-server

Tags :

• :2.0.0 (recommandé en production – version pinned)
• :2.0 (dernier patch de la minor)
• :2 (dernier minor de la major)
• :latest (edge – demos uniquement)

Les prereleases (2.1.0-alpha) publient uniquement le tag exact (:2.1.0-alpha), jamais :latest / :2.

⁠Usage rapide

⁠Pull & run

docker pull fauguste/boondmanager-mcp-server:2.0.0
docker run -d \
  --name boondmanager-mcp \
  -p 3000:3000 \
  -e MCP_TRANSPORT=http \
  fauguste/boondmanager-mcp-server:2.0.0

Le serveur écoute sur http://0.0.0.0:3000/mcp (0.0.0.0 par défaut dans l'image Docker).

⁠Docker Compose

services:
  boondmanager-mcp:
    image: fauguste/boondmanager-mcp-server:2.0.0
    container_name: boondmanager-mcp
    ports:
      - "3000:3000"
    environment:
      MCP_TRANSPORT: http
      # Port/path (optionnels, defaults = 3000 / /mcp)
      MCP_HTTP_PORT: 3000
      MCP_HTTP_PATH: /mcp
      # Public URL (requis derrière un reverse proxy)
      MCP_HTTP_PUBLIC_URL: https://mcp.example.com/mcp
      # Stateful sessions (optionnel, default = false)
      MCP_HTTP_STATEFUL: "false"
      # Logging
      LOG_LEVEL: info
      LOG_FORMAT: json
      # BoondManager API base (optionnel si non-standard)
      BOOND_BASE_URL: https://ui.boondmanager.com/api
    restart: unless-stopped

⁠Authentication : OAuth2 Protected Resource

L'image Docker fonctionne en mode HTTP transport uniquement. L'authentification se fait via OAuth2 :

1. Le client MCP (Claude Desktop, LobeChat, gateway, …) obtient un access_token auprès de BoondManager via le flow Authorization Code.
2. Chaque requête MCP transporte Authorization: Bearer <access_token>.
3. Le serveur ne stocke aucun secret : il forward le token tel quel vers l'API BoondManager.
4. Le client gère le refresh — le serveur n'est jamais impliqué.

Discovery : RFC 9728 protected-resource metadata publié à /.well-known/oauth-protected-resource + /.well-known/oauth-protected-resource/mcp. Les clients compatibles MCP l'utilisent pour auto-découvrir l'authorization server (BoondManager).

⁠Variables d'environnement – Auth

Documentation complète : docs/oauth.md⁠ sur GitHub.

⁠Variables d'environnement – Transport HTTP

⁠Variables d'environnement – BoondManager API

⁠Variables d'environnement – Logging

⁠Exemple derrière un reverse proxy (Traefik)

services:
  traefik:
    image: traefik:v3.0
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command:
      - "--providers.docker=true"
      - "--entrypoints.websecure.address=:443"
      - "[email protected]"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"

  boondmanager-mcp:
    image: fauguste/boondmanager-mcp-server:2.0.0
    environment:
      MCP_TRANSPORT: http
      MCP_HTTP_PUBLIC_URL: https://mcp.example.com/mcp
      LOG_LEVEL: info
      LOG_FORMAT: json
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.mcp.rule=Host(`mcp.example.com`) && PathPrefix(`/mcp`)"
      - "traefik.http.routers.mcp.entrypoints=websecure"
      - "traefik.http.routers.mcp.tls.certresolver=letsencrypt"
      - "traefik.http.services.mcp.loadbalancer.server.port=3000"
    restart: unless-stopped

Important : MCP_HTTP_PUBLIC_URL doit pointer vers l'URL publique (celle vue par le client MCP), pas l'adresse interne Docker. Sinon le discovery metadata publiera l'URL interne et le client ne pourra pas atteindre le serveur OAuth.

⁠Domaines couverts

CRM & Commercial : Candidats (10 tools), Ressources (15), Contacts (11), Sociétés (14), Opportunités (10)
Projets : Projets (12), Positionnements (4), Livraisons/CRA (2), Achats (4)
Facturation : Factures client (5), Factures fournisseur (2), Bons de commande (5), Paiements (2), Notes de frais (5), Produits (5)
RH & Temps : Absences (5), Planning absences (1), Feuilles de temps (3), Contrats (2), Avantages (2)
Suivi d'activité : Actions (4), Validations (2), Todolists (2)
Reporting : Sociétés, Projets, Ressources, Synthèse, Plans de production (1 chacun)
Administration : Comptes (2), Agences (2), Business Units (2), Poles (2), Roles (2), Calendriers (2), Drapeaux (2), Webhooks (2), Logs audit (2), Notifications (2), Fils de discussion (2), Application (2)

Catalogue complet : TOOLS.md⁠

⁠Healthcheck

Le serveur n'expose pas de route /health dédiée — le check se fait via une requête MCP initialize. Exemple Docker healthcheck :

healthcheck:
  test: ["CMD", "curl", "-f", "-X", "POST", "http://localhost:3000/mcp", "-H", "Content-Type: application/json", "-d", '{"method":"initialize","jsonrpc":"2.0","id":1,"params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"healthcheck","version":"1.0"}}}']
  interval: 30s
  timeout: 5s
  retries: 3
  start_period: 10s

Réponse 200 = serveur opérationnel (les appels MCP réels échoueront sans Authorization: Bearer valide, mais le healthcheck lui-même ne nécessite pas d'auth pour le check basique).

⁠Provenance & SBOM

Chaque image publiée inclut :

• Provenance (SLSA Build L3) — atteste de la source GitHub + commit SHA + workflow
• SBOM (SPDX) — bill of materials pour audit de dépendances

Vérification :

docker buildx imagetools inspect \
  --format "{{ json .Provenance }}" \
  fauguste/boondmanager-mcp-server:2.0.0

⁠Support & Contributions

• Source & Documentation : github.com/silamir/boondmanager-mcp-server⁠
• Issues : GitHub Issues⁠
• Changelog : CHANGELOG.md⁠
• Licence : Apache-2.0

Contributions welcome via pull requests. Tests requis (npm test) avant merge.

⁠Liens rapides

• npm : npmjs.com/package/boondmanager-mcp-server⁠
• MCP Registry : registry.modelcontextprotocol.io⁠
• GHCR : ghcr.io/silamir/boondmanager-mcp-server⁠

Multi-arch ready : linux/amd64 + linux/arm64 (x86 servers + Apple Silicon / Graviton).