boondmanager-mcp-server

mcp
Guvenlik Denetimi
Basarisiz
Health Uyari
  • License — License: NOASSERTION
  • Description — Repository has a description
  • Active repo — Last push 0 days ago
  • Low visibility — Only 5 GitHub stars
Code Basarisiz
  • 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 Gecti
  • Permissions — No dangerous permissions requested
Purpose
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.
SUMMARY

mcp server for boondmanager

README.md

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:

  1. Scraping de https://doc.boondmanager.com/api-externe/raml-build/
  2. Comparaison avec le snapshot précédent (api-snapshot.json)
  3. Détection des endpoints ajoutés/supprimés/modifiés
  4. Création d'issue automatique si changements détectés
  5. 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 9h
  • 0 14 * * 3 : Mercredi 14h
  • 0 6 1 * * : 1er du mois 6h
  • 0 */12 * * * : Toutes les 12h

Désactiver la surveillance

Pour désactiver temporairement:

  1. Via l'interface GitHub:

    • Actions → "Monitor BoondManager API Changes" → "⋯" → "Disable workflow"
  2. Via le code:

    • Commenter la section schedule: dans api-monitor.yml
    • Garder workflow_dispatch: pour les exécutions manuelles

🐛 Troubleshooting

Issue non créée malgré des changements

Diagnostic:

  1. Vérifier les logs du workflow (onglet "Actions")
  2. Télécharger l'artifact api-changes-{run} et inspecter changes.json
  3. Vérifier les permissions du workflow

Solutions:

  • S'assurer que contents: write et issues: write sont présents
  • Vérifier que le token GITHUB_TOKEN a 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:

  1. Ajuster la logique de comparaison dans le script Node.js
  2. Ajouter une whitelist de champs à ignorer
  3. Normaliser le JSON avant comparaison (tri des clés)

Rate limiting BoondManager

Si trop de requêtes vers la documentation:

Solutions:

  1. Réduire la fréquence du cron (ex: hebdomadaire → mensuel)
  2. Ajouter un cache avec actions/cache@v4
  3. Utiliser If-Modified-Since header HTTP

Snapshot git conflict

Si plusieurs PRs modifient api-snapshot.json:

Solutions:

  1. Le workflow commit avec [skip ci] pour éviter les loops
  2. En cas de conflit manuel, accepter la version la plus récente (par timestamp)
  3. Ou relancer le workflow après merge pour regénérer

📚 Références

🛠️ Maintenance

Checklist mensuelle

  • Vérifier que le workflow api-monitor s'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

Yorumlar (0)

Sonuc bulunamadi