エージェントを強化
公開元自身のコマンドです。PlugMCP のエンドポイントではありません。
キーとログ付きでコピーをホスト。
npx -y [email protected]Claude Code にはローカルコマンド用のインストールリンクがありません。下のコマンドをコピーして、ターミナルで実行してください。
claude mcp add boondmanager-mcp-server -- npx -y boondmanager-mcp-server@2.19.2ターミナルで実行します。
{ "mcpServers": { "boondmanager-mcp-server": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}claude_desktop_config.json
リモート URL か、手元のマシンのコマンドか 2 つのインストール方法の違い
PlugMCP で実行
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
起動Installation 1-clic :
LM Studio, Goose et Gemini CLI s'installent via leur procédure dédiée (deeplink natif ou commande) — voir la section Installation. GitHub ne rend pas cliquables les liens à schéma non-HTTP (
lmstudio://,goose://), c'est pourquoi ils n'ont pas de bouton 1-clic ici.
Serveur MCP (Model Context Protocol) pour l'API BoondManager, permettant a Claude (Desktop, Cowork, Code) de rechercher, consulter, creer et modifier des enregistrements dans votre instance BoondManager.
238 outils couvrant 42 domaines de l'API BoondManager. Voir TOOLS.md pour le catalogue auto-généré (outils + prompts + ressources).
Sorties structurées. En plus du texte lisible, les outils
search,create,updateetdeleterenvoient unstructuredContentconforme à unoutputSchemaMCP :search→{ total?, count, items[] }(résumés compacts, pas les ressources JSON:API complètes),create/update→{ id?, type? },delete→{ id, deleted, reason? }. Les clients MCP qui exploitent les sorties structurées obtiennent une référence d'entité fiable pour chaîner les appels. Les outilsgetrestent en texte seul (leur texte est déjà du JSON exploitable).
Les entites principales disposent d'outils dedies par onglet pour un acces cible :
Le serveur expose les dictionnaires de reference Boond comme ressources MCP (clients qui en supportent l'affichage : Claude Desktop, MCP Inspector, etc.). Permet au modele de traduire un state ou typeOf entier en libelle sans appel d'outil supplementaire.
Pour les dictionnaires hors de cette liste curee, l'outil boond_application_dictionary reste disponible.
En plus des outils, le serveur expose des prompts MCP (templates pre-cables) qui orchestrent les bons appels d'outils dans le bon ordre pour les workflows recurrents. Visibles dans les clients qui supportent les prompts (Claude Desktop, Cowork, Claude Code, MCP Inspector...) sous forme de slash-commands ou de menu.
Les prompts MCP sont des modeles de message utilisateur : tu les invoques toi-meme, le LLM execute ensuite le runbook qu'ils contiennent. Aucun filtre BoondManager a connaitre — tout est embarque cote serveur.
Claude Desktop / Cowork / MCP Inspector : tape / dans la barre de saisie, choisis le prompt dans la liste, remplis les arguments dans le formulaire qui s'affiche, valide.
Claude Code : pareil, / puis selection ; les arguments sont demandes inline.
Fallback (clients sans UI dediee aux prompts) : cite le prompt par son nom dans une demande libre, le client va recuperer la definition via le protocole MCP. Exemple : "lance le runbook staffing_disponible entre le 1er juin et le 1er septembre 2026, competences Java Spring AWS".
Exemples d'invocation des prompts ressources / competences / CV :
/staffing_disponible
start_date = 2026-06-01
end_date = 2026-09-01
competences = Java Spring AWS Kubernetes
manager_id = (vide -> mon equipe)
/fin_de_mission
horizon_jours = 30
/cartographie_competences
agency_id = 7
top_n = 15
/cvs_a_mettre_a_jour
seuil_mois = 6
/recherche_profil_competences
competences = .NET Azure DevOps
experience_min = 5 ans
dispo_avant = 2026-07-15
inclure_candidats = oui
Apres modification de la config Claude (
claude_desktop_config.jsonetc.), redemarrer le client : la liste des prompts MCP n'est pas hot-reloadee.
Telechargez le fichier .mcpb depuis la derniere release GitHub, puis dans Claude Desktop : Fichier > Installer une extension... et selectionnez le fichier. Les identifiants sont demandes a l'installation et stockes de maniere chiffree (Keychain macOS / Credential Manager Windows).
Meme confort que le one-click Desktop : un formulaire de configuration, aucune variable d'environnement a poser soi-meme.
/plugin marketplace add silamir/boondmanager-mcp-server
/plugin install boondmanager-mcp@boondmanager
Claude Code affiche alors le formulaire des 14 options (identifiants, URL de
base, restrictions d'acces). Tout est optionnel a l'ecran, mais il faut
renseigner un des trois modes d'authentification : le trio User Token +
Client Token + Client Key (JWT genere automatiquement, recommande), ou le
Token JWT pre-construit, ou le couple Utilisateur + Mot de passe
(BasicAuth). Les champs laisses vides retombent sur les valeurs par defaut.
Si le serveur n'apparait pas immediatement dans /mcp, un /reload-plugins
suffit — inutile de relancer Claude Code.
Details utiles :
User Token, Client Token, Client Key, Token JWT, Mot de passe) vont dans le Keychain macOS
(ou ~/.claude/.credentials.json a defaut), pas dans settings.json. Les
options non sensibles (URL, restrictions) sont stockees en clair dans
pluginConfigs de votre ~/.claude/settings.json.mcp__boondmanager__, par exemple mcp__boondmanager__boond_candidates_search.
C'est ce nom qu'il faut utiliser dans une allow-list de permissions./plugin marketplace update boondmanager puis
reinstaller le plugin.BOOND_MCP_* (profil metier, domaines, operations, lecture
seule). Voir docs/access-control.md.boond_*_delete demande une confirmation avant d'agir (option Confirmer les
suppressions, activee par defaut).Pour desinstaller : /plugin uninstall boondmanager-mcp@boondmanager.
claude mcp add)A privilegier si vous voulez piloter vous-meme les variables d'environnement, ou epingler une version differente de celle du plugin.
# Avec un token API (recommande)
claude mcp add --transport stdio --env BOOND_API_TOKEN=votre_token_jwt \
boondmanager -- npx -y boondmanager-mcp-server
# Avec BasicAuth
claude mcp add --transport stdio \
--env BOOND_USER=votre_login \
--env BOOND_PASSWORD=votre_mot_de_passe \
boondmanager -- npx -y boondmanager-mcp-server
Windows : ajoutez
cmd /cavantnpx:claude mcp add --transport stdio --env BOOND_API_TOKEN=votre_token \ boondmanager -- cmd /c npx -y boondmanager-mcp-server
Pour rendre le serveur disponible dans tous vos projets, ajoutez --scope user :
claude mcp add --transport stdio --scope user \
--env BOOND_API_TOKEN=votre_token_jwt \
boondmanager -- npx -y boondmanager-mcp-server
Ajoutez un fichier .mcp.json a la racine de votre projet (a commiter dans git) :
{
"mcpServers": {
"boondmanager": {
"type": "stdio",
"command": "npx",
"args": ["-y", "boondmanager-mcp-server"],
"env": {
"BOOND_API_TOKEN": "${BOOND_API_TOKEN}"
}
}
}
}
Chaque membre de l'equipe n'a qu'a definir la variable d'environnement BOOND_API_TOKEN sur sa machine. Le fichier .mcp.json supporte la syntaxe ${VAR} et ${VAR:-default} pour les variables d'environnement.
Les administrateurs peuvent deployer le serveur MCP pour tous les utilisateurs via le fichier managed-mcp.json :
{
"mcpServers": {
"boondmanager": {
"type": "stdio",
"command": "npx",
"args": ["-y", "boondmanager-mcp-server"],
"env": {
"BOOND_API_TOKEN": "${BOOND_API_TOKEN}",
"BOOND_BASE_URL": "https://votre-instance.boondmanager.com/api"
}
}
}
}
Ce fichier prend le controle exclusif des serveurs MCP : les utilisateurs ne peuvent pas ajouter ou modifier de serveurs en dehors de cette configuration.
Pour restreindre les serveurs autorises tout en laissant les utilisateurs en ajouter, utilisez plutot managed-settings.json :
{
"allowedMcpServers": [
{ "serverName": "boondmanager" }
]
}
Ajoutez dans votre fichier de configuration Claude :
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Windows : %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"boondmanager": {
"command": "npx",
"args": ["-y", "boondmanager-mcp-server"],
"env": {
"BOOND_API_TOKEN": "votre_token_jwt"
}
}
}
}
npx boondmanager-mcp-server
Ou installation globale :
npm install -g boondmanager-mcp-server
boondmanager-mcp-server
git clone https://github.com/silamir/boondmanager-mcp-server.git
cd boondmanager-mcp-server
npm install
npm run build
Le serveur est aussi disponible sur Smithery. La configuration est dans smithery.yaml à la racine du repo : Smithery propose une UI avec les champs d'authentification (JWT auto / JWT pré-construit / BasicAuth) et installe le serveur via npx.
Le serveur est listé sur le marketplace MCP de LobeHub. Dans LobeChat (auto-hebergé ou cloud), ajouter le MCP via Reglages > Plugins > MCP > Ajouter avec :
{
"name": "boondmanager",
"command": "npx",
"args": ["-y", "boondmanager-mcp-server"],
"env": {
"BOOND_USER_TOKEN": "<votre_user_token>",
"BOOND_CLIENT_TOKEN": "<votre_client_token>",
"BOOND_CLIENT_KEY": "<votre_client_key>"
}
}
Ou utiliser le transport HTTP (voir section Transports) pour un deploiement partage en mode gateway.
Cliquez sur le badge Add to Cursor en haut du README (ou ajoutez le serveur manuellement dans Settings > MCP > Add new MCP server). Renseignez ensuite l'authentification en ajoutant un bloc env au serveur dans ~/.cursor/mcp.json :
{
"mcpServers": {
"boondmanager": {
"command": "npx",
"args": ["-y", "boondmanager-mcp-server"],
"env": {
"BOOND_API_TOKEN": "votre_token_jwt"
}
}
}
}
Cliquez sur le badge Install in VS Code en haut du README, ou ajoutez le serveur a .vscode/mcp.json (par projet) ou a votre settings.json utilisateur :
{
"servers": {
"boondmanager": {
"type": "stdio",
"command": "npx",
"args": ["-y", "boondmanager-mcp-server"],
"env": {
"BOOND_API_TOKEN": "${input:boond_api_token}"
}
}
}
}
Dans LM Studio : Program > Install > Edit mcp.json et ajoutez :
{
"mcpServers": {
"boondmanager": {
"command": "npx",
"args": ["-y", "boondmanager-mcp-server"],
"env": {
"BOOND_API_TOKEN": "votre_token_jwt"
}
}
}
}
Ajoutez une extension de type STDIO dans Settings > Extensions > Add avec la commande npx -y boondmanager-mcp-server et la variable d'environnement BOOND_API_TOKEN. En CLI :
goose session --with-extension "npx -y boondmanager-mcp-server"
Le depot embarque un manifeste d'extension Gemini CLI (gemini-extension.json). Installez l'extension directement depuis GitHub :
gemini extensions install https://github.com/silamir/boondmanager-mcp-server
Definissez ensuite l'authentification dans votre environnement (Gemini interpole ${VAR} au demarrage) :
export BOOND_API_TOKEN="votre_token_jwt"
# ou le trio JWT auto :
export BOOND_USER_TOKEN="..." BOOND_CLIENT_TOKEN="..." BOOND_CLIENT_KEY="..."
Le serveur utilise pino pour des logs structures JSON (agrégateurs, observabilité).
En production (NODE_ENV=production), les logs sont en JSON par défaut. En dev, le format pretty (colorisé) est actif sauf si LOG_FORMAT=json. Chaque requête HTTP reçoit un corrId (8 hex) pour tracer la requête dans les logs.
Les logs sont toujours écrits sur stderr, quel que soit le transport : en mode stdio, stdout est réservé au flux JSON-RPC et toute autre écriture corrompt la connexion côté client. Claude Desktop capture stderr dans son visualiseur de logs (Developer → Logs), c'est donc là que les avertissements (politique d'accès, mise à jour disponible, dictionnaires) sont visibles.
Option 1 : Token API JWT (recommande)
export BOOND_API_TOKEN="votre_token_jwt"
Option 2 : BasicAuth
export BOOND_USER="votre_login"
export BOOND_PASSWORD="votre_mot_de_passe"
BOOND_HTTP_STATIC_AUTH)Par défaut, le transport HTTP (MCP_TRANSPORT=http) est une ressource protégée OAuth2 : chaque requête MCP porte le token BoondManager de son utilisateur (voir docs/oauth.md). BOOND_HTTP_STATIC_AUTH=true remplace ce modèle par les credentials d'environnement ci-dessus, partagés par toutes les requêtes — pour un déploiement mono-locataire auto-hébergé, un pipeline CI ou une passerelle interne sans flux OAuth.
Dans ce mode, plus rien n'authentifie le client MCP : quiconque atteint le port agit avec les droits BoondManager de l'opérateur (lecture et écriture selon la politique d'accès). D'où :
export MCP_TRANSPORT=http
export MCP_HTTP_HOST=0.0.0.0
export BOOND_HTTP_STATIC_AUTH=true
export MCP_HTTP_API_KEY="$(openssl rand -hex 32)"
export BOOND_USER_TOKEN=… BOOND_CLIENT_TOKEN=… BOOND_CLIENT_KEY=…
npx boondmanager-mcp-server
# côté client : Authorization: Bearer <MCP_HTTP_API_KEY>
/healthz reste accessible sans clé. En mode OAuth (défaut), MCP_HTTP_API_KEY est ignorée avec un avertissement : le Bearer y est le token BoondManager.
export BOOND_BASE_URL="https://votre-instance.boondmanager.com/api"
Par defaut, l'URL est https://ui.boondmanager.com/api.
Chaque requete vers l'API BoondManager expire au bout de 30 secondes par defaut. Pour les tenants lents ou des rapports volumineux, augmenter via :
export BOOND_HTTP_TIMEOUT_MS=60000 # 60 s
Si une requete depasse le delai, le serveur renvoie une erreur explicite mentionnant BOOND_HTTP_TIMEOUT_MS plutot que de rester bloque indefiniment.
Le client HTTP retente automatiquement les erreurs transitoires avec un backoff exponentiel + jitter :
5xx, 429, erreurs reseau (ECONNRESET, etc.) et timeouts (GET etant idempotent).429 afin d'eviter de dupliquer une ecriture cote serveur. Les 5xx et erreurs reseau remontent immediatement.Retry-After (en secondes ou en HTTP-date) est honore et plafonne a BOOND_HTTP_RETRY_MAX_MS.Pour eviter qu'une boucle d'outils emballee n'inonde l'API (et n'enchaine les 429), le client applique un token bucket local. Defauts : 10 req/s soutenu, rafale 20 — invisible en usage interactif normal. Les retentatives consomment aussi un jeton.
En transport HTTP OAuth, le bucket est par utilisateur (identite derivee du Bearer) : la rafale d'un utilisateur ne ralentit pas les autres. En stdio et en static auth, une seule identite, donc un seul bucket — la limite est par identite, pas par processus.
L'API BoondManager n'expose qu'un seul endpoint /application/dictionary qui renvoie l'intégralité des libellés (états, types, pays…). Le serveur le met en cache en mémoire pour éviter de le re-télécharger à chaque résolution état/type → libellé.
boond_documents_create accepte trois sources, exactement une par appel :
export BOOND_MCP_UPLOAD_DIRS="$HOME/Documents/Boond,$HOME/Downloads"
Garde-fous : chemin absolu obligatoire, confinement vérifié après résolution des liens symboliques (.. et symlinks sortants refusés), fichier régulier uniquement, type déterminé par les premiers octets (PDF, DOCX/XLSX/PPTX, ODT/ODS, DOC/XLS/PPT, RTF, PNG, JPEG, GIF, WebP) et non par l'extension. N'autorisez que des répertoires dédiés : tout fichier accepté qui s'y trouve peut être envoyé dans BoondManager à la demande du modèle.
Une pièce jointe glissée dans une conversation se trouve dans l'environnement d'exécution de code du client (bac à sable), pas sur le poste du serveur : filePath ne la voit pas, et le modèle ne peut pas la retranscrire de façon fiable en base64. Le relais la fait transiter hors de la sortie du modèle :
boond_documents_upload_slot({ fileName }) crée, dans une bibliothèque SharePoint dédiée, un dossier de transit et une session d'upload Microsoft Graph pré-authentifiée (15 min, un fichier, un usage) ;PUT (curl, commande fournie) ;boond_documents_create({ parentType, parentId, uploadSlot }) vérifie le fichier (taille, premiers octets), transmet à BoondManager son URL de lecture temporaire Graph via le mécanisme fileUrl, puis le supprime définitivement (permanentDelete, sans corbeille ; repli sur une suppression simple si le locataire la refuse). Les slots expirés sont purgés à l'ouverture suivante.Les identifiants Entra ID restent côté serveur ; le client ne voit que des URL limitées à un fichier.
Mise en place, avec le minimum de droits :
Sites.Selected et le consentement administrateur, puis le rôle write accordé sur ce seul site :Connect-MgGraph -Scopes "Sites.FullControl.All"
$site = Get-MgSite -SiteId "<tenant>.sharepoint.com:/sites/<site>"
New-MgSitePermission -SiteId $site.Id -BodyParameter @{
roles = @("write")
grantedToIdentities = @(@{ application = @{ id = "<client-id>"; displayName = "boond-mcp-relay" } })
}
<tenant>.sharepoint.com dans la liste blanche réseau de l'exécution de code.Compromis assumé : l'URL de lecture que reçoit BoondManager est pré-authentifiée pendant sa courte durée de vie (quelques minutes, fixée par Microsoft) ; elle est imprévisible et le fichier est supprimé dès que BoondManager l'a récupéré.
Vous pouvez restreindre ce que l'IA voit et peut faire, entièrement par variables d'environnement : exposer seulement certains domaines (ex. la comptabilité), et/ou bloquer les écritures et suppressions.
⚠️ Ce n'est pas une frontière de sécurité dure. Le filtre masque des outils à l'IA mais n'altère pas les droits du compte BoondManager utilisé. Pour un vrai cloisonnement, configurez d'abord les droits du compte/rôle BoondManager (lecture seule, périmètre comptable…) ; ce filtre vient en complément (économie de tokens, garde-fou anti-action accidentelle).
Exemple — tout le périmètre gestion, en lecture seule :
export BOOND_MCP_PROFILE=finance
export BOOND_MCP_READ_ONLY=true
Guide complet, règles de résolution, contenu de chaque profil (et le nombre d'outils qui en résulte) : docs/access-control.md.
Les outils, prompts et ressources portent une icône par domaine (SVG inline en
data: URI, aucun asset à héberger). Coût mesuré : ~40 Kio, soit ~14 % du
payload tools/list. Les déploiements qui ne les affichent pas (passerelles,
clients texte) peuvent les supprimer :
Si votre instance BoondManager utilise des libellés de dictionnaire
personnalisés (ex. types d'action ou états en anglais), vous pouvez déclarer
le mapping libellé→ID via BOOND_DICTIONARY_OVERRIDES (JSON inline ou chemin
vers un fichier JSON) :
export BOOND_DICTIONARY_OVERRIDES='{"action":{"contact":{"Call":61,"Email":63}},"state":{"candidate":{"Interviewed":2}}}'
Le serveur accepte alors ces libellés pour le typeOf de
boond_actions_create et les champs state des créations/modifications, les
résout automatiquement en IDs numériques, et enrichit les descriptions des
outils avec les libellés disponibles. Sans cette variable, le comportement est
strictement inchangé.
Format complet, entités supportées et limites : docs/dictionary-overrides.md.
Le serveur supporte deux transports MCP, selectionnables via la variable d'environnement MCP_TRANSPORT.
Depuis la v1.4.0, le serveur peut etre expose en HTTP (transport MCP Streamable HTTP) afin d'etre branche derriere une passerelle MCP ou deploye comme service. La revision de protocole negociee est celle du SDK installe (2025-11-25).
Authentification BoondManager : OAuth2 protected resource. Le serveur HTTP ne detient aucun secret (ni
client_secret, ni refresh token, ni stockage utilisateur). Chaque requete MCP doit porterAuthorization: Bearer <boond_access_token>; le serveur transmet le token tel quel a BoondManager. C'est le client MCP (Claude Desktop, Claude Code, gateway…) qui fait la danse OAuth contre BoondManager et qui gere le refresh. Procedure complete : docs/oauth.md.
export MCP_TRANSPORT=http
export MCP_HTTP_HOST=0.0.0.0 # defaut: 127.0.0.1
export MCP_HTTP_PORT=3000 # defaut: 3000
export MCP_HTTP_PATH=/mcp # defaut: /mcp
# Optionnel: requis uniquement derriere un reverse proxy, pour que
# la discovery annonce la bonne URL publique.
export MCP_HTTP_PUBLIC_URL=https://mcp.votre-domaine.com/mcp
npx boondmanager-mcp-server
# 🚀 BoondManager MCP Server running (streamable HTTP transport)
# 📡 Endpoint: http://0.0.0.0:3000/mcp
# 🔑 Mode: stateless
# 🔐 Boond auth: OAuth2 (per-request Bearer from MCP client)
Variables d'environnement HTTP
Variables OAuth2 — discovery (toutes optionnelles)
Stateless (defaut) : chaque requete HTTP POST est independante, idealement adapte a un gateway qui multiplexe plusieurs serveurs MCP. Aucune session n'est conservee cote serveur.
Stateful : le serveur genere un Mcp-Session-Id a l'initialisation que le client doit renvoyer dans chaque requete suivante. Utile pour les clients MCP natifs qui beneficient du streaming SSE et des notifications serveur.
# Public, pas d'auth -> documente OU envoyer le user pour autoriser
curl -s http://localhost:3000/.well-known/oauth-protected-resource | jq .
# {
# "resource": "http://0.0.0.0:3000/mcp",
# "authorization_servers": ["https://ui.boondmanager.com"],
# "bearer_methods_supported": ["header"]
# }
# Appel MCP sans token -> 401 + WWW-Authenticate qui pointe vers la discovery
curl -s -o /dev/null -w "%{http_code}\n%header{www-authenticate}\n" \
-X POST http://localhost:3000/mcp -d '{}'
# 401
# Bearer realm="http://0.0.0.0:3000/mcp", resource_metadata="http://0.0.0.0:3000/.well-known/oauth-protected-resource/mcp"
Avec un client MCP conforme a la spec MCP Authorization 2025-06-18, la decouverte OAuth est automatique :
claude mcp add --transport http boondmanager https://mcp.votre-domaine.com/mcp
# Le client recoit le 401 + WWW-Authenticate, fetch la metadata, ouvre
# le navigateur pour autoriser l'App BoondManager, puis re-emet la requete
# avec le Bearer token recu.
Une image Docker prete a l'emploi est publiee a chaque release sur deux registres miroirs, multi-arch (linux/amd64 + linux/arm64) :
Memes digests, memes tags — choisissez celui qui s'aligne avec votre tooling. L'image demarre par defaut en transport HTTP, sur le port 3000, sur l'interface 0.0.0.0. Aucun volume, aucun secret a stocker — le serveur est stateless par construction.
# Via GHCR (authentification GitHub si registre prive)
docker run -d --restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-e MCP_HTTP_PUBLIC_URL=https://mcp.votre-domaine.com/mcp \
--name boondmanager-mcp \
ghcr.io/silamir/boondmanager-mcp-server:latest
# Ou via Docker Hub (anonyme)
docker run -d --restart unless-stopped \
-p 127.0.0.1:3000:3000 \
-e MCP_HTTP_PUBLIC_URL=https://mcp.votre-domaine.com/mcp \
--name boondmanager-mcp \
fauguste/boondmanager-mcp-server:latest
Tags disponibles sur les deux registres : :latest, :X, :X.Y, :X.Y.Z pour chaque release stable (la version exacte est recommandee pour la prod). Les prereleases (par exemple :2.0.0-alpha) sont publiees uniquement sous leur tag pinne — ni :latest, ni :X, ni :X.Y ne bougent. Variables d'environnement supportees : voir Configuration et Transports.
Le repo embarque un docker-compose.yml pret a l'emploi : un seul service stateless, aucun volume, aucun secret cote serveur.
# Optionnel : surcharger MCP_HTTP_PUBLIC_URL si fronted par un reverse proxy
cp .env.example .env
docker compose up -d
docker compose logs -f mcp
Securite : le serveur HTTP est stateless et ne stocke aucun secret BoondManager. Chaque utilisateur authentifie le serveur via son propre token OAuth2 (issu de sa propre App BoondManager), et toutes les actions sont attribuees a son identite dans l'audit log Boond. Derriere un reverse proxy : terminez TLS (HTTPS), forwardez l'en-tete
Authorization, et reglezMCP_HTTP_PUBLIC_URLsur l'URL publique pour que la discovery soit coherente.
MCP est un protocole agnostique du modele : le meme endpoint HTTP/OAuth2 est consomme tel quel par tout hote compatible MCP, pas seulement Claude. Aucun package ni build specifique a un LLM n'est requis — il suffit de pointer l'hote sur votre URL MCP_HTTP_PUBLIC_URL.
Le contrat est identique a celui de Claude Code en HTTP (voir l'exemple claude mcp add --transport http ci-dessus) : seule la maniere de declarer le serveur cote client change.
Une fois configure, vous pouvez demander a Claude :
CRM & Commercial
Gestion de projets
Facturation & Finance
RH & Temps
Suivi d'activite
Reporting
Administration
boondmanager-mcp-server/
├── src/
│ ├── index.ts # Point d'entree MCP (selection du transport)
│ ├── server.ts # Factory createMcpServer() + liste des domaines
│ ├── constants.ts # Configuration, API paths, onglets
│ ├── types.ts # Types TypeScript (JSON:API)
│ ├── transports/
│ │ └── http.ts # Transport Streamable HTTP (gateway/remote)
│ ├── services/
│ │ └── boond-client.ts # Client HTTP API BoondManager
│ ├── schemas/
│ │ └── index.ts # Schemas Zod (validation des entrees)
│ └── tools/
│ ├── index.ts # Barrel export de tous les domaines
│ ├── crud-factory.ts # Factory generique CRUD (DRY)
│ ├── candidates.ts # 10 outils (CRUD + 5 onglets)
│ ├── resources.ts # 20 outils (CRUD + 10 onglets + references/timesheets)
│ ├── contacts.ts # 11 outils (CRUD + 6 onglets)
│ ├── companies.ts # 14 outils (CRUD + 9 onglets)
│ ├── opportunities.ts # 10 outils (CRUD + 5 onglets)
│ ├── projects.ts # 12 outils (CRUD + 7 onglets)
│ ├── actions.ts # 5 outils
│ ├── timesheets.ts # 3 outils
│ ├── invoices.ts # 5 outils
│ ├── orders.ts # 5 outils
│ ├── deliveries.ts # 2 outils
│ ├── absences.ts # 5 outils
│ ├── expenses.ts # 5 outils
│ ├── products.ts # 5 outils
│ ├── positionings.ts # 4 outils
│ ├── payments.ts # 2 outils
│ ├── advantages.ts # 2 outils
│ ├── contracts.ts # 2 outils
│ ├── purchases.ts # 4 outils
│ ├── provider-invoices.ts # 2 outils
│ ├── accounts.ts # 2 outils
│ ├── agencies.ts # 2 outils
│ ├── business-units.ts # 2 outils
│ ├── poles.ts # 2 outils
│ ├── roles.ts # 2 outils
│ ├── calendars.ts # 2 outils
│ ├── flags.ts # 2 outils
│ ├── webhooks.ts # 2 outils
│ ├── logs.ts # 2 outils
│ ├── notifications.ts # 2 outils
│ ├── threads.ts # 2 outils
│ ├── todolists.ts # 2 outils
│ ├── validations.ts # 2 outils
│ ├── reporting.ts # 5 outils
│ ├── planning-absences.ts # 1 outil
│ └── application.ts # 2 outils
├── dist/ # Build JavaScript
├── .github/ # CI/CD, templates, Dependabot
├── package.json
├── tsconfig.json
├── vitest.config.ts
├── eslint.config.js
└── README.md
*_searchSymptome. Les outils de recherche (boond_candidates_search, boond_resources_search,
boond_opportunities_search...) echouent systematiquement, alors que les outils de fiche
(boond_*_get), les dictionnaires et les workflows textuels fonctionnent. La dissymetrie est
le diagnostic : seuls les ~59 outils qui declarent un outputSchema sont concernes, parce que
c'est ce schema-la que l'hote compile -- au moment ou il enregistre l'outil, donc avant tout
appel. L'outil n'echoue pas, il devient inutilisable.
Cause. Les versions 2.1.0 a 2.12.1 annoncaient "$schema": "http://json-schema.org/draft-07/schema#"
sur leurs schemas (le SDK MCP convertit les schemas Zod avec target: 'draft-7', en dur). Un hote
qui valide avec un validateur 2020-12 uniquement refuse de compiler un tel schema.
Correctif : mettre a jour vers >= 2.12.2. Depuis cette version le serveur n'annonce plus
aucun dialecte (src/schema-dialect.ts), ce que la suite de tests verifie sur les 185 outils
a travers un vrai client, sous validateur 2020-12 et draft-07.
Redemarrer le connecteur ne suffit pas : un redemarrage relance le binaire installe, il ne le met pas a jour. Verifiez la version reellement chargee plutot que celle affichee par le catalogue :
# npm / npx : quelle version est resolue et depuis quel cache
npm view boondmanager-mcp-server version
npx --yes boondmanager-mcp-server@latest --version 2>/dev/null || true
# Le serveur annonce sa version dans la reponse `initialize` (champ serverInfo.version),
# lue depuis son propre package.json -- c'est la seule source fiable.
Selon le canal d'installation :
Verifiez aussi la version de Node : le serveur requiert Node.js >= 22. Un poste encore en Node 20 est en general un poste dont l'installation n'a pas ete rafraichie depuis longtemps.
Authorization: Bearer <token> (le serveur ne stocke aucun secret). Terminez TLS (HTTPS via reverse proxy), forwardez l'en-tete Authorization, reglez MCP_HTTP_PUBLIC_URL sur l'URL publique, et activez la protection anti DNS rebinding via MCP_HTTP_ALLOWED_HOSTS. Restreignez aussi l'acces reseau a votre gateway. Voir docs/oauth.md.# Mode watch pour le developpement
npm run dev
# Build
npm run build
# Lancer le serveur
npm start
# Tests
npm test # 645 tests
npm run test:coverage # Avec couverture
# Qualite
npm run lint
npm run typecheck
Apache License 2.0 — Copyright (c) 2025-2026 Silamir. Créé à l'origine par Frédéric Auguste.
BoondManager est une marque de BoondManager SAS. Ce projet est un client indépendant et non officiel de l'API publique BoondManager, sans affiliation avec BoondManager SAS.
MCP Server for BoondManager API - 185 tools, 13 prompts, 22 resources (ERP/CRM)
{ "mcpServers": { "boondmanager-mcp-server": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}ツール
ツール一覧はまだありません。リモートサーバーは、最初のヘルスチェック後に取得されます。
よくある質問
このページで Cursor、Claude Desktop、Claude Code、VS Code 用の stdio 設定をコピーできます。PlugMCP のプロキシではなく、公開元のインストール方法を使います。
このレコードに必須の環境変数は記載されていません。
Boondmanager は stdio 経由でローカル実行されます。
最終チェックは 2026-11-13 です。 MCP Server for BoondManager API - 185 tools, 13 prompts, 22 resources (ERP/CRM)