boondmanager-mcp-server
Health Warn
- License — License: NOASSERTION
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Low visibility — Only 5 GitHub stars
Code Fail
- network request — Outbound network request in .github/workflows/api-monitor.test.yml
- child_process — Shell command execution capability in .github/workflows/api-monitor.yml
- execSync — Synchronous shell command execution in .github/workflows/api-monitor.yml
- fs module — File system access in .github/workflows/api-monitor.yml
- network request — Outbound network request in .github/workflows/api-monitor.yml
Permissions Pass
- Permissions — No dangerous permissions requested
This is an MCP server that acts as a bridge between AI models (like Claude) and the BoondManager API. It exposes 158 tools across 36 domains, allowing the AI to seamlessly search, create, modify, and delete CRM, project management, HR, and financial records in a user's BoondManager instance.
Security Assessment
Risk: Medium. The core function of this server requires making outbound network requests to the BoondManager API to manage your account data. Because it handles CRM, billing, and HR records, it processes highly sensitive business and personal information. The automated security scan raised warnings regarding shell command execution (`child_process` and `execSync`) and filesystem access. However, these flags were triggered specifically by a GitHub Actions workflow file (`api-monitor.yml`) used for testing and API monitoring, rather than the underlying TypeScript application code. No dangerous permissions or hardcoded secrets were detected in the tool itself.
Quality Assessment
The project is in active development, with its most recent push occurring today. The repository is well-structured and utilizes strict TypeScript, automated CI testing, and CodeQL security analysis. It also clearly states it is licensed under the Apache 2.0 license (though the exact license file isn't auto-detected by the scanner). The main drawback is its low community visibility; having only 5 GitHub stars indicates a very limited user base and minimal peer review.
Verdict
Use with caution. The server is technically sound and actively maintained, but its low community adoption combined with extensive access to highly sensitive business data warrants a careful security review of the source code before connecting it to your production environment.
mcp server for boondmanager
GitHub Workflows & Automation
Ce dossier contient les workflows GitHub Actions et la configuration pour l'automatisation du projet BoondManager MCP Server.
📋 Workflows
🔄 CI/CD Principaux
| Workflow | Déclenchement | Description |
|---|---|---|
| ci.yml | Push/PR → main |
Tests, lint, typecheck, couverture, MCPB validation |
| release.yml | Tags v* |
Publication npm, GitHub Releases, MCP Registry, GHCR |
| codeql.yml | Push/PR, schedule | Analyse de sécurité statique (CodeQL) |
🔔 Surveillance API
| Workflow | Déclenchement | Description |
|---|---|---|
| api-monitor.yml | Cron hebdo (Lun 9h) | Surveille les changements dans l'API BoondManager |
| api-monitor.test.yml | Manuel uniquement | Test du système de surveillance |
api-monitor.yml — Surveillance automatique
Objectif: Détecter automatiquement les nouveautés dans la documentation officielle de l'API BoondManager et créer des issues GitHub pour faciliter la maintenance.
Fonctionnement:
- Scraping de
https://doc.boondmanager.com/api-externe/raml-build/ - Comparaison avec le snapshot précédent (
api-snapshot.json) - Détection des endpoints ajoutés/supprimés/modifiés
- Création d'issue automatique si changements détectés
- Commit du nouveau snapshot
Déclenchement:
- Automatique: Tous les lundis à 9h00 UTC
- Manuel: Via Actions → "Monitor BoondManager API Changes" → "Run workflow"
Sorties:
- Issue GitHub avec label
enhancement,api-update - Commit du snapshot dans
.github/api-snapshot.json - Artifact
api-changes-{run_number}(90 jours de rétention)
Documentation complète: Voir API_MONITORING.md
api-monitor.test.yml — Tests
Workflow de test pour valider:
- Syntaxe YAML du workflow principal
- Accessibilité de la documentation BoondManager
- Installation des dépendances (axios, cheerio, diff)
Usage: Actions → "Test API Monitor Workflow" → "Run workflow"
📁 Fichiers de Configuration
| Fichier | Description |
|---|---|
| api-snapshot.json | Snapshot de référence de l'API BoondManager |
| API_MONITORING.md | Documentation détaillée du système de surveillance |
| README.md | Ce fichier |
api-snapshot.json
Structure du snapshot:
{
"timestamp": "2026-04-26T09:00:00.000Z",
"url": "https://doc.boondmanager.com/api-externe/raml-build/",
"endpointsCount": 156,
"endpoints": [
{
"type": "endpoint",
"method": "GET",
"name": "resources/search",
"description": "Recherche de ressources avec filtres..."
}
]
}
Gestion:
- ✅ Versionné dans Git (historique des changements API)
- ✅ Auto-mis à jour par le workflow hebdomadaire
- ✅ Commit automatique avec message
[skip ci](évite loop CI)
🧪 Tests Locaux
Pour tester le système de surveillance en local:
# Test simple (lecture seule)
npm run api:monitor:test
# Test + sauvegarde du snapshot
npm run api:monitor:save
Le script local (scripts/test-api-monitor.js) utilise uniquement les modules Node.js natifs + https pour minimiser les dépendances.
🔐 Permissions
Les workflows requièrent les permissions suivantes (configurées dans chaque workflow YAML):
api-monitor.yml
permissions:
contents: write # Commit du snapshot
issues: write # Création d'issues
ci.yml
permissions:
contents: read
id-token: write # Pour OIDC
release.yml
permissions:
contents: write # GitHub Releases
packages: write # GHCR
id-token: write # npm provenance + MCP Registry
📊 Artifacts
Les workflows génèrent les artifacts suivants:
| Workflow | Artifact | Rétention | Contenu |
|---|---|---|---|
| api-monitor | api-changes-{run} |
90 jours | changes.json + api-snapshot.json |
| ci | coverage-{node-version} |
30 jours | Rapports de couverture V8 |
| release | .mcpb bundle |
Permanent | Attaché à la GitHub Release |
🚀 Déploiement
Modifier le planning de surveillance
Pour changer la fréquence du monitoring, éditer api-monitor.yml:
on:
schedule:
- cron: '0 9 * * 1' # minute heure jour-mois mois jour-semaine
Exemples:
0 9 * * 1: Lundi 9h0 14 * * 3: Mercredi 14h0 6 1 * *: 1er du mois 6h0 */12 * * *: Toutes les 12h
Désactiver la surveillance
Pour désactiver temporairement:
Via l'interface GitHub:
- Actions → "Monitor BoondManager API Changes" → "⋯" → "Disable workflow"
Via le code:
- Commenter la section
schedule:dansapi-monitor.yml - Garder
workflow_dispatch:pour les exécutions manuelles
- Commenter la section
🐛 Troubleshooting
Issue non créée malgré des changements
Diagnostic:
- Vérifier les logs du workflow (onglet "Actions")
- Télécharger l'artifact
api-changes-{run}et inspecterchanges.json - Vérifier les permissions du workflow
Solutions:
- S'assurer que
contents: writeetissues: writesont présents - Vérifier que le token
GITHUB_TOKENa les droits nécessaires - Consulter les logs de l'étape "Create GitHub issue for changes"
Faux positifs (changements mineurs détectés)
Cause: Le système détecte tout changement JSON, même cosmétique (espace, ordre).
Solutions:
- Ajuster la logique de comparaison dans le script Node.js
- Ajouter une whitelist de champs à ignorer
- Normaliser le JSON avant comparaison (tri des clés)
Rate limiting BoondManager
Si trop de requêtes vers la documentation:
Solutions:
- Réduire la fréquence du cron (ex: hebdomadaire → mensuel)
- Ajouter un cache avec
actions/cache@v4 - Utiliser
If-Modified-Sinceheader HTTP
Snapshot git conflict
Si plusieurs PRs modifient api-snapshot.json:
Solutions:
- Le workflow commit avec
[skip ci]pour éviter les loops - En cas de conflit manuel, accepter la version la plus récente (par timestamp)
- Ou relancer le workflow après merge pour regénérer
📚 Références
- Documentation BoondManager API
- GitHub Actions - Events
- GitHub Actions - Cron syntax
- GitHub CLI - gh issue create
- Blog GitHub: Workflows Testing & Validation
🛠️ Maintenance
Checklist mensuelle
- Vérifier que le workflow
api-monitors'exécute correctement - Consulter les issues créées et leur statut
- Mettre à jour les dépendances du workflow si nécessaire
- Vérifier la taille du snapshot (< 1 MB pour perf Git)
Checklist annuelle
- Réviser la logique de détection (faux positifs/négatifs)
- Optimiser le scraping (nouveaux sélecteurs CSS si structure doc change)
- Archiver les anciennes issues d'API update (label
archived) - Évaluer l'ajout de métriques (Prometheus, DataDog, etc.)
Dernière mise à jour: 2026-04-26
Maintenu par: @fauguste
Reviews (0)
Sign in to leave a review.
Leave a reviewNo results found