# BoondManager MCP Server [Health: Active] **Category:** 💻 Developer Tools **Repository:** https://github.com/silamir/boondmanager-mcp-server **GitHub Stars:** 21 **npm Downloads (last month):** 2285 **Views:** 0 **Installs:** 0 **Upvotes:** 0 **Directory Page:** https://allmcps.com/mcp/boondmanager-mcp-server ## Description MCP Server for BoondManager API - 158 tools across 36 domains for ERP/CRM data ## Tools Capabilities this server exposes over MCP: - **boond_candidates_search** — Recherche des candidats dans BoondManager avec filtres serveur. Plutôt que : `boond_resources_search` pour les collaborateurs internes — candidats et ressources sont deux référentiels distincts, et une personne recrutée cesse d'être trouvable ici. Cas d'usage courants : • **Mes candidats** sans connaître son propre ID : `perimeterDynamic: ["data"]`. Pour "candidats de l'équipe X" : `perimeterManagers: []` (utiliser `perimeterManagersType: "main"|"hr"` pour cibler Main vs HR Manager). • **États / types** : `candidateStates: []` (dictionnaire `setting.state.candidate`), `candidateTypes` (`setting.typeOf.resource`), `contractTypes`, `availabilityTypes`. IDs entiers issus du dictionnaire. • **Profil technique** : `tools: []` (OU; pour ET: `["#AND#", "1", "2"]`), `expertiseAreas`, `activityAreas`, `experiences`, `trainings`, `mobilityAreas`, `languages` (format `langueId|niveauId`). • **Sourcing** : `sources: []` (origine du candidat), `evaluations`. • **Période** : `period: "created"|"updated"|"available"|"withActions"|...` + `startDate`/`endDate`. • **Recherche par nom** : `keywords: "Dupont"` + `keywordsType: "lastName"` (ou firstName, fullName avec `"NOM#PRENOM"`, emails, phones, title, titleSkills…). Sans `keywordsType`, recherche par défaut dans le CV. • **Géolocalisation** : `coordinates: "lat,lon"` ou `location` + `geoDistance` (km, 5-200). Tri : `sort` + `order`. Returns : liste paginée des candidats. Utiliser `boond_candidates_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_candidates_get** — Récupère la fiche complète d'un(e) candidat par son ID numérique. Quand : après un `boond_candidates_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_candidates_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou `boond_find` pour résoudre un nom / un e-mail en ID. - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_candidates_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_candidates_create** — Crée un(e) candidat dans BoondManager. Quand : pour ajouter un(e) candidat inexistant(e). Plutôt que : `boond_candidates_update` pour modifier un enregistrement existant, et `boond_candidates_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_candidates_update** — Met à jour un(e) candidat existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_candidates_create` si l'enregistrement n'existe pas encore, ou `boond_find` pour résoudre un nom / un e-mail en ID. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_candidates_delete** — Supprime définitivement un(e) candidat de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_candidates_get`. Plutôt que : `boond_candidates_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_candidates_technical_data_update** — Met à jour le dossier technique (DT) d'un candidat : compétences, outils, langues, profils (activityAreas), secteurs (expertiseAreas), formation, diplômes, expérience, résumé. Quand : pour coder le dossier technique d'un candidat (profils, secteurs, outils, langues, expérience, formation). Plutôt que : `boond_candidates_update` pour l'onglet Information (coordonnées, disponibilité, mobilité, évaluation) ; `boond_resources_technical_data_update` pour un collaborateur interne. Mode 'merge' (défaut, recommandé pour automation) — enrichit sans rien écraser : • skills (CSV) : concatène les compétences absentes • tools / languages : ajoute les entrées dont la clé (slug outil / langue) est nouvelle, conserve le niveau existant pour les autres • expertiseAreas, activityAreas, diplomas : ajoute les items absents • title, summary, training, experience : remplis UNIQUEMENT si actuellement vides Mode 'replace' — remplace intégralement chaque champ fourni. Les champs non passés ne sont pas touchés. ⚠️ experience, training, expertiseAreas, activityAreas et tools prennent des IDs de dictionnaire (`setting.experience`, `setting.training`, `setting.expertiseArea`, `setting.activityArea`, `setting.tool`), jamais des libellés. Returns : confirmation, liste des champs envoyés mais non retrouvés dans la réponse de l'API (écriture ignorée par Boond), puis le DT mis à jour. - **boond_candidates_administrative_update** — Met à jour l'onglet Administratif d'un candidat : nationalité, salaire souhaité (fourchette), salaire actuel, contrat souhaité, commentaires. Quand : pour renseigner nationalité, salaire souhaité ou contrat souhaité d'un candidat. Plutôt que : `boond_candidates_technical_data_update` pour les compétences et le parcours. Seuls les champs fournis sont envoyés. Données personnelles : n'écrire que ce que le candidat a communiqué (CV, entretien). Returns : confirmation, liste des champs non retrouvés dans la réponse de l'API, puis le bloc administratif mis à jour. - **boond_candidates_information** — Récupère les informations générales (coordonnées, adresse, état civil, photo, tags, source) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Bloc identité et coordonnées du candidat. Lecture seule. - **boond_candidates_technical_data** — Récupère le profil technique (compétences, expériences, formations, certifications, langues, CV) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Profil technique du candidat. Les ID de documents (CV) qui s'y trouvent alimentent `boond_documents_get`. Lecture seule. - **boond_candidates_administrative** — Récupère les données administratives (pièces justificatives, documents contractuels, informations RH) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Bloc administratif du candidat, avec les ID de documents exploitables par `boond_documents_get`. Lecture seule. - **boond_candidates_actions** — Récupère les actions (appels, emails, RDV, notes) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Liste des actions rattachées au candidat. Lecture seule. - **boond_candidates_positionings** — Récupère les positionnements (placements du candidat sur des opportunités ou des projets) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Liste des positionnements du candidat. Lecture seule. - **boond_resources_search** — Recherche des ressources (collaborateurs internes) dans BoondManager avec filtres serveur. Plutôt que : `boond_candidates_search` pour les profils externes en cours de recrutement — deux référentiels distincts, un candidat n'apparaît pas ici avant son embauche. Cas d'usage courants : • **Mes données / mon équipe / mon agence** sans connaître son propre ID : `perimeterDynamic: ["data"]` (mes ressources), `["managers"]` (mes N-1), `["agencies"]` (mes agences). • **Équipe d'une personne X** : `perimeterManagers: []` (filtre les ressources dont X est le N+1). • **Mon ID utilisateur** : appeler `boond_application_current_user` puis passer cet ID dans `perimeterManagers`. • **États / types** : `resourceStates: []`, `resourceTypes: []`. IDs entiers issus du dictionnaire (voir `boond_application_dictionary` avec `setting.state.resource` ou `setting.typeOf.resource`). `excludeResourceStates` / `excludeResourceTypes` pour exclure. • **Compétences / outils** : `tools: [, ...]` (OU par défaut ; pour ET: `["#AND#", "1", "2"]`). `expertiseAreas`, `activityAreas`, `languages` (format `langueId|niveauId`). • **Disponibilité / activité** : `period: "available"` + `startDate`/`endDate`. Autres valeurs : `working`, `hired`, `left`, `employed`, `birthday`, `seniority`… • **Recherche par nom** : `keywords: "Dupont"` + `keywordsType: "lastName"` (ou `firstName`, `fullName` avec `keywords: "Dupont#Jean"`). • **Géolocalisation** : `coordinates: "48.85,2.35"` (ou `location: "Paris"`) + `geoDistance: 50` (km). Tri : `sort: "lastName"` (ou firstName/title/availability/state/updateDate/creationDate) + `order: "asc"|"desc"`. Returns : liste paginée. Utiliser `boond_resources_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_resources_get** — Récupère la fiche complète d'un(e) ressource par son ID numérique. Quand : après un `boond_resources_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_resources_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou `boond_find` pour résoudre un nom / un e-mail en ID. - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_resources_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_resources_create** — Crée un(e) ressource dans BoondManager. Quand : pour ajouter un(e) ressource inexistant(e). Plutôt que : `boond_resources_update` pour modifier un enregistrement existant, et `boond_resources_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_resources_update** — Met à jour un(e) ressource existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_resources_create` si l'enregistrement n'existe pas encore, ou `boond_find` pour résoudre un nom / un e-mail en ID. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_resources_delete** — Supprime définitivement un(e) ressource de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_resources_get`. Plutôt que : `boond_resources_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_resources_information** — Récupère les informations générales (coordonnées, adresse, état civil, photo, tags, manager) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Bloc identité et rattachement hiérarchique de la ressource. Lecture seule. - **boond_resources_technical_data** — Récupère le profil technique (compétences, expériences, formations, certifications, langues, CV) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Profil technique de la ressource. Modifiable via `boond_resources_technical_data_update`. Lecture seule. - **boond_resources_administrative** — Récupère les données administratives et RH (salaire, TJM, coût journalier, contrat) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Bloc administratif de la ressource — données salariales, à manier avec prudence. Lecture seule. - **boond_resources_advantages** — Récupère les avantages (tickets restaurant, mutuelle, véhicule, primes) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Liste des avantages de la ressource. Lecture seule. - **boond_resources_actions** — Récupère les actions (appels, emails, RDV, notes) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Liste des actions rattachées à la ressource. Lecture seule. - **boond_resources_positionings** — Récupère les positionnements (placements de la ressource sur des opportunités ou des projets) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Liste des positionnements de la ressource. Lecture seule. - **boond_resources_projects** — Récupère les projets (missions en cours et passées auxquelles la ressource participe) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Liste des projets de la ressource. Lecture seule. - **boond_resources_times_reports** — Récupère les feuilles de temps (CRA) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Liste des CRA de la ressource. Pour le détail jour par jour d'un mois, utiliser `boond_timesheets_get`. Lecture seule. - **boond_resources_expenses_reports** — Récupère les notes de frais d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Liste des notes de frais mensuelles de la ressource. Le détail des lignes est dans `boond_expenses_get`. Lecture seule. - **boond_resources_absences_reports** — Récupère les demandes d'absences (congés, RTT, maladie) d'un(e) ressource, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_resources_get` pour la fiche de base, ou `boond_resources_search` si l'ID est inconnu. Returns : Liste des demandes d'absences de la ressource. Lecture seule. - **boond_resources_contracts** — Liste les contrats de travail d'une ressource (type, dates, période d'essai, motif de fin), par son ID. Quand : pour connaître le contrat en cours, l'historique contractuel ou la fin de période d'essai d'un collaborateur. Plutôt que : `boond_contracts_search` pour balayer un périmètre entier (fins de contrat du mois…), `boond_contracts_get` pour la fiche complète d'un contrat. - Lit `/resources/{id}/administrative` et en extrait les contrats inclus — il n'existe pas d'onglet `contracts` côté API. Returns : une ligne par contrat, du plus récent au plus ancien tel que BoondManager les renvoie, avec les IDs pour `boond_contracts_get`. Lecture seule. - **boond_resources_technical_data_update** — Met à jour le dossier technique (DT) d'une ressource : compétences, outils, langues, expertises, formations, diplômes, expérience. Quand : pour mettre à jour le dossier technique d'une ressource (compétences, formations, langues…). Plutôt que : `boond_resources_reference_create` / `_update` / `_delete` pour les seules expériences professionnelles : elles vivent dans le même bloc, mais ces outils évitent d'avoir à republier le tableau entier. Mode 'merge' (défaut, recommandé pour automation) — enrichit sans rien écraser : • skills (CSV) : concatène les compétences absentes • tools / languages : ajoute les entrées dont la clé (slug outil / langue) est nouvelle, conserve le niveau existant pour les autres • expertiseAreas, activityAreas, diplomas : ajoute les items absents • title, summary, training, experience : remplis UNIQUEMENT si actuellement vides Mode 'replace' — remplace intégralement chaque champ fourni par la valeur passée. Les champs non passés ne sont pas touchés. Seuls les champs explicitement fournis dans l'appel sont envoyés à l'API — un champ omis ne sera jamais réinitialisé à vide. Les expériences professionnelles (références) ne sont PAS gérées ici : utiliser boond_resources_reference_{create|update|delete}. Returns : confirmation et dossier technique mis à jour. Réponse inchangée si aucun champ n'était à écrire dans le mode demandé. - **boond_resources_reference_create** — Crée une expérience professionnelle (référence) rattachée au DT d'une ressource. Plutôt que : `boond_resources_technical_data_update` pour les autres blocs du dossier technique (compétences, formations, langues), que cet outil ne touche pas. ⚠️ Les références sont des sous-objets embarqués dans le DT, pas une entité REST autonome. L'outil fait read-modify-write : lit la liste actuelle via /resources/{id}/technical-data, ajoute la nouvelle référence et republie la liste complète. Champs requis : resourceId, title, company, description. Dates : startMonth/endMonth en int 1..12 (ou string '1'..'12' sans leading zero) ; startYear/endYear en int 4 chiffres. ⚠️ "05" avec leading zero est rejeté par l'API. Pour compléter une référence existante, utiliser boond_resources_reference_update pour ne pas dupliquer. Returns : confirmation, nombre total de références et ID de celle créée (l'API ne le renvoie pas systématiquement). - **boond_resources_reference_update** — Met à jour une référence existante. Read-modify-write sur /resources/{id}/technical-data — seuls les champs explicitement fournis remplacent ceux de la référence ciblée, les autres champs et toutes les autres références restent intacts. Quand : pour corriger une expérience professionnelle existante. Plutôt que : `boond_resources_reference_create` pour en ajouter une nouvelle. Cas d'usage type : compléter startMonth/startYear/endMonth/endYear sur une référence sans toucher au titre, à la société ou à la description. Returns : confirmation et dossier technique republié. Un `referenceId` introuvable renvoie `isError: true` avec la liste des ID présents. - **boond_resources_reference_delete** — Supprime une référence (expérience professionnelle) du DT d'une ressource. Read-modify-write : lit la liste actuelle, en retire la référence ciblée, republie le reste. ⚠️ Action irréversible — vérifier l'ID au préalable. Quand : pour retirer une expérience saisie par erreur, sur demande explicite de l'utilisateur. Plutôt que : `boond_resources_reference_update` pour corriger une référence plutôt que la détruire. Returns : confirmation et nombre de références restantes. Un `referenceId` introuvable renvoie `isError: true` avec la liste des ID présents. - **boond_contacts_search** — Recherche des contacts (interlocuteurs clients / prospects) dans BoondManager avec filtres serveur. Plutôt que : `boond_companies_search` pour les sociétés elles-mêmes, `boond_candidates_search` / `boond_resources_search` pour les profils — un contact est un interlocuteur client, pas un profil. Cas d'usage courants : • **Mes contacts** sans connaître son propre ID : `perimeterDynamic: ["data"]`. Pour "contacts gérés par X" : `perimeterManagers: []`. • **Contacts d'une société donnée** : utiliser `keywords: "CSOC"` (préfixe CSOC + ID). Exemple : `keywords: "CSOC6420"` pour la société 6420. • **États / types** : `states: []` (dictionnaire `setting.state.contact`), `typesOf: []` (⚠️ avec un 's' final, dictionnaire `setting.typeOf.contact`), `companyStates` (états des sociétés rattachées). IDs entiers. • **Profil métier** : `activityAreas`, `expertiseAreas`, `tools`, `origins` (sources), `influencers`. • **Période** : `period: "created"|"updated"|"withActions"|"withoutActions"|"noAction"` + `startDate`/`endDate`. • **Complétude** : `completeness: ["email:empty","phone:empty"]` (OU par défaut, '#AND#' en 1er pour ET) — utile pour "contacts sans email". • **Recherche par nom** : `keywords: "Dupont"` + `keywordsType: "lastName"` (ou firstName, fullName `"NOM#PRENOM"`, companyFullName `"CSOCid#NOM#PRENOM"`, emails, phones, socialNetworks). Tri : `sort` + `order`. Returns : liste paginée des contacts. Utiliser `boond_contacts_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_contacts_get** — Récupère la fiche complète d'un(e) contact par son ID numérique. Quand : après un `boond_contacts_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_contacts_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou `boond_find` pour résoudre un nom / un e-mail en ID. - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_contacts_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_contacts_create** — Crée un(e) contact dans BoondManager. Quand : pour ajouter un(e) contact inexistant(e). Plutôt que : `boond_contacts_update` pour modifier un enregistrement existant, et `boond_contacts_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_contacts_update** — Met à jour un(e) contact existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_contacts_create` si l'enregistrement n'existe pas encore, ou `boond_find` pour résoudre un nom / un e-mail en ID. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_contacts_delete** — Supprime définitivement un(e) contact de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_contacts_get`. Plutôt que : `boond_contacts_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_contacts_information** — Récupère les informations générales (coordonnées, société de rattachement, fonction, tags) d'un(e) contact, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_contacts_get` pour la fiche de base, ou `boond_contacts_search` si l'ID est inconnu. Returns : Bloc identité et rattachement du contact. Lecture seule. - **boond_contacts_actions** — Récupère les actions (appels, emails, RDV, notes) d'un(e) contact, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_contacts_get` pour la fiche de base, ou `boond_contacts_search` si l'ID est inconnu. Returns : Liste des actions rattachées au contact. Lecture seule. - **boond_contacts_opportunities** — Récupère les opportunités commerciales (affaires portées par ce contact) d'un(e) contact, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_contacts_get` pour la fiche de base, ou `boond_contacts_search` si l'ID est inconnu. Returns : Liste des opportunités du contact. Lecture seule. - **boond_contacts_projects** — Récupère les projets d'un(e) contact, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_contacts_get` pour la fiche de base, ou `boond_contacts_search` si l'ID est inconnu. Returns : Liste des projets rattachés au contact. Lecture seule. - **boond_contacts_orders** — Récupère les bons de commande d'un(e) contact, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_contacts_get` pour la fiche de base, ou `boond_contacts_search` si l'ID est inconnu. Returns : Liste des bons de commande du contact. Lecture seule. - **boond_contacts_invoices** — Récupère les factures d'un(e) contact, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_contacts_get` pour la fiche de base, ou `boond_contacts_search` si l'ID est inconnu. Returns : Liste des factures adressées au contact. Lecture seule. - **boond_companies_search** — Recherche des sociétés (clients, prospects, fournisseurs…) dans BoondManager avec filtres serveur. Plutôt que : `boond_contacts_search` pour les personnes physiques ; noter aussi que `/companies` n'expose aucun filtre de type, seulement `states`. Cas d'usage courants : • **Mes comptes** sans connaître son propre ID : `perimeterDynamic: ["data"]`. Pour "comptes gérés par X" : `perimeterManagers: []`. • **États** : `states: []` (dictionnaire `setting.state.company`). IDs entiers. • **Segmentation métier** : `expertiseAreas` (dictionnaire `setting.expertiseArea`), `origins`, `influencers`. • **Période** : `period: "created"|"updated"|"withActions"|"withoutActions"|"noAction"` + `startDate`/`endDate`. • **Recherche** : `keywords` + `keywordsType` ('default' = nom/ville/pays/expertise/info, ou 'name', 'phones', 'emails', 'socialNetworks'). Pour cibler une société par ID : `keywords: "CSOC"`. Tri : `sort` + `order`. Note : il n'y a PAS de filtre `typeOf` pour les sociétés dans l'API search. Le type (client/prospect/fournisseur) doit être inféré via le détail de la société (`boond_companies_get`). Returns : liste paginée des sociétés. Utiliser `boond_companies_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_companies_get** — Récupère la fiche complète d'un(e) société par son ID numérique. Quand : après un `boond_companies_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_companies_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou `boond_find` pour résoudre un nom / un e-mail en ID. - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_companies_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_companies_create** — Crée un(e) société dans BoondManager. Quand : pour ajouter un(e) société inexistant(e). Plutôt que : `boond_companies_update` pour modifier un enregistrement existant, et `boond_companies_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_companies_update** — Met à jour un(e) société existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_companies_create` si l'enregistrement n'existe pas encore, ou `boond_find` pour résoudre un nom / un e-mail en ID. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_companies_delete** — Supprime définitivement un(e) société de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_companies_get`. Plutôt que : `boond_companies_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_companies_information** — Récupère les informations générales (coordonnées, SIRET, site web, secteur, taille, tags) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Fiche signalétique de la société. Lecture seule. - **boond_companies_contacts** — Récupère les contacts (interlocuteurs rattachés à la société) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des contacts de la société. Lecture seule. - **boond_companies_actions** — Récupère les actions (appels, emails, RDV, notes) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des actions rattachées à la société. Lecture seule. - **boond_companies_opportunities** — Récupère les opportunités commerciales d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des opportunités de la société. Lecture seule. - **boond_companies_projects** — Récupère les projets d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des projets de la société. Lecture seule. - **boond_companies_orders** — Récupère les bons de commande d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des bons de commande de la société. Lecture seule. - **boond_companies_invoices** — Récupère les factures client d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des factures de vente adressées à la société. Ne pas confondre avec `boond_companies_provider_invoices` (achat). Lecture seule. - **boond_companies_purchases** — Récupère les achats et la sous-traitance d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des achats engagés auprès de la société. Lecture seule. - **boond_companies_provider_invoices** — Récupère les factures fournisseur (factures reçues de la société en tant que prestataire) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des factures d'achat. Ne pas confondre avec `boond_companies_invoices` (vente). Lecture seule. - **boond_opportunities_search** — Recherche des opportunités commerciales dans BoondManager avec filtres serveur. Plutôt que : `boond_projects_search` une fois l'affaire gagnée : le projet est la suite de l'opportunité. Cas d'usage courants : • **Mes opportunités** sans connaître son propre ID : `perimeterDynamic: ["data"]`. Pour "opportunités de X" : `perimeterManagers: []` (combiner avec `perimeterManagersType: "main"|"hr"`). • **États / types** : `opportunityStates: []` (dictionnaire `setting.state.opportunity`), `opportunityTypes: []` (`setting.typeOf.project`). IDs entiers issus du dictionnaire. • **Lié à une société/contact/candidat** : utiliser `keywords` avec préfixes — `"CSOC"` (société), `"CCON"` (contact), `"CAND"` (candidat), `"COMP"` (ressource), `"PROD"` (produit), `"AO"` (opportunité). • **Métier** : `activityAreas`, `expertiseAreas`, `tools`, `places` (zones), `durations`, `origins`. • **Positionnements** : `positioningStates: []` ou `["none"]` pour les opportunités sans positionnement. • **Période** : `period: "created"|"started"|"closingDate"|"updated"|"updatedPositioning"|"withActions"|...` + `startDate`/`endDate`. Ex: clôtures 2026 → `period: "closingDate", startDate: "2026-01-01", endDate: "2026-12-31"`. Tri : `sort: "creationDate"|"title"|"company.name"|"startDate"|"endDate"|"state"|"closingDate"|"answerDate"|"updateDate"|...` + `order`. Returns : liste paginée des opportunités. Utiliser `boond_opportunities_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_opportunities_get** — Récupère la fiche complète d'un(e) opportunité par son ID numérique. Quand : après un `boond_opportunities_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_opportunities_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou `boond_find` pour résoudre un nom / un e-mail en ID. - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_opportunities_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_opportunities_create** — Crée un(e) opportunité dans BoondManager. Quand : pour ajouter un(e) opportunité inexistant(e). Plutôt que : `boond_opportunities_update` pour modifier un enregistrement existant, et `boond_opportunities_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_opportunities_update** — Met à jour un(e) opportunité existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_opportunities_create` si l'enregistrement n'existe pas encore, ou `boond_find` pour résoudre un nom / un e-mail en ID. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_opportunities_delete** — Supprime définitivement un(e) opportunité de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_opportunities_get`. Plutôt que : `boond_opportunities_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_opportunities_information** — Récupère les informations générales (client, dates, montant, probabilité, état) d'un(e) opportunité, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_opportunities_get` pour la fiche de base, ou `boond_opportunities_search` si l'ID est inconnu. Returns : Fiche de l'opportunité. Lecture seule. - **boond_opportunities_actions** — Récupère les actions (appels, emails, RDV, notes) d'un(e) opportunité, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_opportunities_get` pour la fiche de base, ou `boond_opportunities_search` si l'ID est inconnu. Returns : Liste des actions rattachées à l'opportunité. Lecture seule. - **boond_opportunities_positionings** — Récupère les positionnements (candidats et ressources proposés au client) d'un(e) opportunité, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_opportunities_get` pour la fiche de base, ou `boond_opportunities_search` si l'ID est inconnu. Returns : Liste des positionnements de l'opportunité. Lecture seule. - **boond_opportunities_projects** — Récupère les projets (missions nées de cette affaire une fois gagnée) d'un(e) opportunité, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_opportunities_get` pour la fiche de base, ou `boond_opportunities_search` si l'ID est inconnu. Returns : Liste des projets liés à l'opportunité. Lecture seule. - **boond_opportunities_simulation** — Récupère la simulation financière (marge, CA prévisionnel, coûts) d'un(e) opportunité, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_opportunities_get` pour la fiche de base, ou `boond_opportunities_search` si l'ID est inconnu. Returns : Chiffrage prévisionnel de l'opportunité — prévisionnel, pas du réalisé. Lecture seule. - **boond_actions_search** — Recherche des actions (appels, emails, RDV, notes) dans BoondManager par entité rattachée (candidat, ressource, contact, société, opportunité, projet), type (`actionTypes`), période (`period` + dates ou `periodDynamic`) et périmètre (`perimeter*`). Quand : pour balayer l'historique commercial ou RH sur un périmètre, plusieurs entités confondues. Plutôt que : les onglets `actions` d'une entité connue (`boond_candidates_actions`, `boond_companies_actions`, `boond_projects_actions`…) : plus direct et sans filtre de périmètre à construire. Les filtres `candidateId` / `resourceId` / `contactId` / `companyId` sont convertis en références `keywords` (CAND / COMP / CCON / CSOC) : l'API n'a pas de paramètre dédié. Returns: Liste des actions correspondantes. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_actions_get** — Récupère la fiche complète d'un(e) action par son ID numérique. Quand : après un `boond_actions_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_actions_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_actions_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_actions_create** — Crée une nouvelle action (appel, email, RDV, note) dans BoondManager, rattachée à un contact, candidat, ressource, opportunité ou projet (relation dependsOn, obligatoire). Plutôt que : `boond_actions_update` pour compléter une action déjà enregistrée plutôt que d'en créer un doublon. Exactement une entité de rattachement parmi `contactId` / `candidateId` / `resourceId` / `opportunityId` / `projectId` est requise (422 sinon) ; `companyId` n'est accepté qu'en complément d'un `contactId`, et `positioningId` est exigé par l'API pour les types d'action liés aux positionnements (ex. RQ). Returns: L'action créée avec son ID. - **boond_actions_update** — Met à jour une action existante dans BoondManager (PUT partiel, seuls les champs fournis sont modifiés). Plutôt que : `boond_actions_create` si l'action n'existe pas encore. ⚠️ Aucune relation n'est envoyée : le rattachement (dependsOn), le positionnement et la synchronisation calendrier (event Outlook/Teams, invités) sont préservés. Idéal pour ajouter un compte-rendu sans casser l'agenda — contrairement à delete + recreate qui supprime l'événement. `text` remplace le contenu existant (pas d'ajout). Returns: L'action mise à jour. - **boond_actions_delete** — Supprime définitivement un(e) action de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_actions_get`. Plutôt que : `boond_actions_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_timesheets_default** — Renvoie ce qu'il faut savoir avant d'écrire le CRA d'une ressource sur un mois : types d'unité d'œuvre autorisés, couples projet/prestation imputables, planning prévu et absences déjà posées. Quand : AVANT `boond_timesheets_create` / `boond_timesheets_update` — les codes `workUnitTypeReference` ne sont publiés nulle part ailleurs (ni dans `boond_application_dictionary`, ni sur `boond_agencies_get`). Plutôt que : aucun autre outil ne donne ces codes ; `boond_timesheets_get` pour relire un CRA existant. - Lecture seule (`GET /times-reports/default`). La réponse brute est réduite : les types viennent de la ressource incluse (`workUnitTypesAllowed`), les imputations des projets inclus, le planning de `plannedTimes`. - Une ressource sans imputation ce mois-là ne peut saisir que des absences. Returns : texte : agence, types d'unité d'œuvre (reference | libellé | activityType), imputations `projectId` / `deliveryId` (et `batchId`), planning prévu agrégé par imputation, absences déjà posées. - **boond_timesheets_create** — Crée la feuille de temps (CRA) d'un mois pour une ressource, avec ses lignes jour par jour. Quand : pour ouvrir le CRA d'un couple (ressource, mois) qui n'existe pas encore, après `boond_timesheets_default`. Plutôt que : `boond_timesheets_search` (`startMonth`/`endMonth` + `resourceId`) d'abord : l'API ne déduplique pas, deux CRA peuvent coexister sur le même mois ; `boond_timesheets_update` si le CRA existe déjà. - Un CRA est un conteneur mensuel (`term` + `resource`) ; les lignes vont dans `regularTimes[]` (production et absences) et `exceptionalTimes[]` — chaque ligne = un jour, une durée, un type d'unité d'œuvre, et pour la production un couple `projectId` / `deliveryId` imputable. - `state` n'est pas un champ d'écriture : il est piloté par le workflow de validation (`boond_validations_search`). - Écriture non idempotente. Modèle d'écriture établi en lecture depuis l'API (forme des CRA existants et de `/times-reports/default`), pas encore éprouvé en écriture sur un tenant de test — voir CLAUDE.md. Returns : confirmation, ID créé (`structuredContent.id`) et fiche du CRA. - **boond_timesheets_update** — Met à jour un CRA existant : commentaires, clôture, ou remplacement complet de ses lignes. Quand : pour compléter ou corriger le CRA d'un mois déjà ouvert (trouvé via `boond_timesheets_search`). Plutôt que : `boond_timesheets_create` si aucun CRA n'existe encore pour ce couple (ressource, mois). - Mise à jour partielle sur les champs simples, MAIS `regularTimes` / `exceptionalTimes` **remplacent le tableau entier** : relire le CRA (`boond_timesheets_get`), fusionner, renvoyer la liste complète — envoyer une seule ligne efface le mois. - `state` n'est pas un champ d'écriture (workflow de validation). Returns : confirmation et fiche du CRA mis à jour. - **boond_resources_timesheets** — Récupère les feuilles de temps (times reports) d'une ressource par son ID, avec filtre optionnel par mois/année (défaut : mois courant). Quand : pour lister les CRA d'une ressource sur un mois donné, sans connaître leurs ID. Plutôt que : `boond_timesheets_get` pour le détail d'un CRA précis, `boond_timesheets_search` pour couvrir plusieurs ressources d'un coup. Returns: Liste des feuilles de temps de la ressource avec jours/heures et statut. - **boond_timesheets_search** — Recherche des feuilles de temps (CRA mensuels) dans BoondManager, par mois, ressource, état de validation (`validationStates` : waitingForValidation / validated / rejected) et périmètre (`perimeter*`). Quand : pour balayer les CRA de plusieurs ressources sur une période. Plutôt que : `boond_resources_timesheets` quand on part d'une ressource précise, et `boond_timesheets_get` pour le détail jour par jour d'un CRA. ⚠️ `startMonth` et `endMonth` (format YYYY-MM) sont requis par l'API — passer YYYY-MM-DD ou les omettre renvoie un 422. Returns: Liste des feuilles de temps correspondantes (une ligne par CRA : mois, période, statut, totaux). - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_timesheets_get** — Récupère les informations détaillées d'une feuille de temps (CRA mensuel) par son ID. Quand : après une recherche, pour le détail jour par jour d'un CRA identifié. Plutôt que : `boond_resources_timesheets` pour lister les CRA d'une ressource sans connaître leurs ID. Returns: Données JSON complètes de la feuille de temps (jours, heures, statut, détails). - **boond_projects_search** — Recherche des projets / missions dans BoondManager avec filtres serveur. Plutôt que : `boond_opportunities_search` pour l'avant-vente — un projet est une affaire déjà gagnée. Cas d'usage courants : • **Mes projets** sans connaître son propre ID : `perimeterDynamic: ["data"]`. Pour "projets de X" : `perimeterManagers: []`. • **États / types** : `projectStates: []` (dictionnaire `setting.state.project`), `projectTypes: []` (`setting.typeOf.project`). IDs entiers. • **Société cliente** : `companies: []` (filtre les projets rattachés à ces sociétés). • **Lié à un contact / opportunité / contrat / ressource / produit** : utiliser `keywords` avec préfixes — `"PRJ"` (projet), `"CSOC"` (société), `"CCON"` (contact), `"AO"` (opportunité), `"CTR"` (contrat), `"COMP"` (ressource), `"PROD"` (produit), `"MIS"` (livraison). • **Métier** : `activityAreas`, `expertiseAreas`, `flags` (tags). • **Période** : `period: "running"` (en cours), `"created"`, `"started"`, `"stopped"`, `"closed"`, `"updated"`, `"hasAdditionalDataOrPurchase"` + `startDate`/`endDate`. Ex: projets en cours en 2026 → `period: "running", startDate: "2026-01-01", endDate: "2026-12-31"`. Tri : `sort: "startDate"|"endDate"|"reference"|"company.name"|"mainManager.lastName"` + `order`. Returns : liste paginée des projets. Utiliser `boond_projects_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_projects_get** — Récupère la fiche complète d'un(e) projet par son ID numérique. Quand : après un `boond_projects_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_projects_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou `boond_find` pour résoudre un nom / un e-mail en ID. - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_projects_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_projects_create** — Crée un(e) projet dans BoondManager. Quand : pour ajouter un(e) projet inexistant(e). Plutôt que : `boond_projects_update` pour modifier un enregistrement existant, et `boond_projects_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_projects_update** — Met à jour un(e) projet existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_projects_create` si l'enregistrement n'existe pas encore, ou `boond_find` pour résoudre un nom / un e-mail en ID. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_projects_delete** — Supprime définitivement un(e) projet de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_projects_get`. Plutôt que : `boond_projects_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_projects_information** — Récupère les informations générales (client, dates, état, description, responsable) d'un(e) projet, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_projects_get` pour la fiche de base, ou `boond_projects_search` si l'ID est inconnu. Returns : Fiche du projet. Lecture seule. - **boond_projects_actions** — Récupère les actions (appels, emails, RDV, notes) d'un(e) projet, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_projects_get` pour la fiche de base, ou `boond_projects_search` si l'ID est inconnu. Returns : Liste des actions rattachées au projet. Lecture seule. - **boond_projects_simulation** — Récupère la simulation financière (marge, CA, coûts, rentabilité) d'un(e) projet, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_projects_get` pour la fiche de base, ou `boond_projects_search` si l'ID est inconnu. Returns : Chiffrage du projet. Lecture seule. - **boond_projects_deliveries_groupments** — Récupère les livraisons et leurs groupements (lignes de mission facturables du projet) d'un(e) projet, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_projects_get` pour la fiche de base, ou `boond_projects_search` si l'ID est inconnu. Returns : Liste des livraisons du projet. Les ID de livraison qui s'y trouvent sont ceux qu'exige une ligne de note de frais. Lecture seule. - **boond_projects_orders** — Récupère les bons de commande d'un(e) projet, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_projects_get` pour la fiche de base, ou `boond_projects_search` si l'ID est inconnu. Returns : Liste des bons de commande adossés au projet. Lecture seule. - **boond_projects_purchases** — Récupère les achats et la sous-traitance d'un(e) projet, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_projects_get` pour la fiche de base, ou `boond_projects_search` si l'ID est inconnu. Returns : Liste des achats imputés au projet. Lecture seule. - **boond_projects_productivity** — Récupère les données de productivité (temps passé, jours consommés) d'un(e) projet, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_projects_get` pour la fiche de base, ou `boond_projects_search` si l'ID est inconnu. Returns : Consommé du projet — du réalisé, contrairement à `boond_projects_simulation`. Lecture seule. - **boond_invoices_search** — Liste et recherche les factures client, par société, projet, état (`states`), période (`period` + dates, ou `periodDynamic`), périmètre (`perimeter*`) ou avoir / facture (`creditNote`). Quand : pour suivre la facturation client (encours, retards, règlements attendus). Plutôt que : `boond_provider_invoices_search` pour les factures d'achat — celui-ci ne couvre que le sens vente, et les deux ne partagent pas d'endpoint. `companyId` / `projectId` sont convertis en références `keywords` (`CSOC`, `PRJ`) — l'API n'a pas de paramètre dédié et ignorerait un `companyId` brut. Returns : page de résumés (référence, date, montants HT/TTC, état). Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_invoices_get** — Récupère la fiche complète d'un(e) facture par son ID numérique. Quand : après un `boond_invoices_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_invoices_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_invoices_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_invoices_create** — Crée un(e) facture dans BoondManager. Quand : pour ajouter un(e) facture inexistant(e). Plutôt que : `boond_invoices_update` pour modifier un enregistrement existant, et `boond_invoices_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_invoices_update** — Met à jour un(e) facture existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_invoices_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_invoices_delete** — Supprime définitivement un(e) facture de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_invoices_get`. Plutôt que : `boond_invoices_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_invoices_information** — Récupère les informations complètes (lignes facturées, coordonnées de facturation et bancaires, échéance, état d'envoi, commande et projet liés) d'un(e) facture, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_invoices_get` pour la fiche de base, ou `boond_invoices_search` si l'ID est inconnu. Returns : Fiche complète de la facture (relations société, contact, commande, projet, prestation incluses). Lecture seule. - **boond_invoices_actions** — Récupère les actions (envois, relances, notes) d'un(e) facture, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_invoices_get` pour la fiche de base, ou `boond_invoices_search` si l'ID est inconnu. - Un envoi de facture par e-mail apparaît ici comme une action, avec ses destinataires dans `text`. Returns : Liste des actions rattachées à la facture, la plus récente en premier. Lecture seule. - **boond_orders_search** — Recherche des bons de commande dans BoondManager avec filtres par société et projet. Quand : pour suivre les bons de commande client. Plutôt que : `boond_invoices_search` pour la facturation qui en découle, `boond_orders_get` si l'ID est connu. `companyId` / `projectId` sont convertis en références `keywords` (CSOC / PRJ) : l'API n'a pas de paramètre dédié. Returns: Liste des bons de commande correspondants. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_orders_get** — Récupère la fiche complète d'un(e) bon de commande par son ID numérique. Quand : après un `boond_orders_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_orders_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_orders_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_orders_create** — Crée un(e) bon de commande dans BoondManager. Quand : pour ajouter un(e) bon de commande inexistant(e). Plutôt que : `boond_orders_update` pour modifier un enregistrement existant, et `boond_orders_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_orders_update** — Met à jour un(e) bon de commande existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_orders_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_orders_delete** — Supprime définitivement un(e) bon de commande de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_orders_get`. Plutôt que : `boond_orders_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_orders_information** — Récupère les informations complètes (période, conditions de paiement, références acheteur, prestations et projet liés) d'un(e) bon de commande, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_orders_get` pour la fiche de base, ou `boond_orders_search` si l'ID est inconnu. Returns : Fiche complète du bon de commande (relations société, contact, projet, prestations incluses). Lecture seule. - **boond_orders_actions** — Récupère les actions (envois, relances, notes) d'un(e) bon de commande, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_orders_get` pour la fiche de base, ou `boond_orders_search` si l'ID est inconnu. Returns : Liste des actions rattachées au bon de commande. Lecture seule. - **boond_orders_invoices** — Récupère les factures émises (référence, période, état, montants HT/TTC) d'un(e) bon de commande, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_orders_get` pour la fiche de base, ou `boond_orders_search` si l'ID est inconnu. - C'est l'entrée de la préparation de facturation : `deltaInvoicedExcludingTax` > 0 signifie qu'il reste à facturer sur la commande. Returns : Liste des factures rattachées au bon de commande, précédée des totaux calculés par BoondManager : commandé HT, facturé HT/TTC, reste à facturer (`deltaInvoicedExcludingTax`) et répartition par état. Lecture seule. - **boond_deliveries_create** — Crée une prestation (livraison) rattachée à un projet et à une ressource. Quand : pour ouvrir la ligne de mission qui rendra la ressource facturable sur ce projet. Plutôt que : `boond_projects_deliveries_groupments` pour lister les prestations déjà en place sur le projet. - `project` et `resource` sont obligatoires et attendent des ID numériques. - L'ID de prestation retourné est celui qu'exigent les lignes de note de frais (`boond_expenses_create`). - Écriture non idempotente. Returns : confirmation et fiche de la prestation créée, avec son ID dans `structuredContent.id`. - **boond_deliveries_search** — Recherche des prestations / livraisons dans BoondManager par projet, société, ressource, état (`deliveryStates`, `projectStates`), période (`period: "running"` + dates pour les prestations en cours) et périmètre (`perimeter*`). Quand : pour retrouver des prestations (lignes de mission facturables) sur un périmètre. Plutôt que : `boond_projects_deliveries_groupments` quand on part d'un projet connu — plus direct. `projectId` / `companyId` sont convertis en références `keywords` (PRJ / CSOC) : l'API n'a pas de paramètre dédié. Returns: Liste des livraisons correspondantes. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_deliveries_get** — Récupère la fiche complète d'un(e) livraison (CRA) par son ID numérique. Quand : après un `boond_deliveries_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_deliveries_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_deliveries_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_deliveries_update** — Met à jour un(e) livraison (CRA) existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_deliveries_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_deliveries_delete** — Supprime définitivement un(e) livraison (CRA) de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_deliveries_get`. Plutôt que : `boond_deliveries_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_absences_default** — Renvoie les types d'absence autorisés pour une ressource (RTT, maladie, congés payés… avec leur code) et les valeurs par défaut d'une demande. Quand : AVANT `boond_absences_create` — le code `workUnitTypeReference` n'est publié que par `GET /absences-reports/default` (ni dans `boond_application_dictionary`, ni sur l'agence). Plutôt que : `boond_timesheets_default` pour les mêmes codes vus du CRA (production comprise) ; aucun autre outil ne donne les types d'absence. - Lecture seule ; la réponse brute est réduite aux types (ressource incluse, `workUnitTypesAllowed`) et aux scalaires de la demande. Returns : texte : ressource, agence, types d'absence (reference | libellé | activityType), valeurs par défaut. - **boond_absences_search** — Recherche des demandes d'absence dans BoondManager, par période (`startMonth` / `endMonth` en YYYY-MM, requis), ressource, état de validation (`validationStates`) et périmètre (`perimeter*`). Quand : pour retrouver des demandes d'absence et leur état de validation. Plutôt que : `boond_planning_absences_search` pour la vue calendaire (qui est absent quand), et `boond_validations_search` pour ce qui reste en attente de validation. `resourceId` est converti en référence `keywords` COMP : l'API n'a pas de paramètre dédié. Returns: Liste des demandes d'absence correspondantes. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_absences_get** — Récupère la fiche complète d'un(e) demande d'absence par son ID numérique. Quand : après un `boond_absences_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_absences_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_absences_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_absences_create** — Crée une demande d'absence (congés, RTT, maladie…) pour une ressource. Quand : pour poser une absence au nom d'une ressource identifiée par son ID. Plutôt que : `boond_absences_update` pour modifier une demande déjà déposée. - Le détail est porté par `absencesPeriods` ; si le tableau est omis, une période unique est déduite de `startDate`/`endDate`. - Pas de `state` : sur `/absences-reports` l'état est une chaîne du workflow de validation (`waitingForValidation`, `validated`…) que seul le workflow déplace — la demande part en attente de validation, elle n'est pas validée par cet appel (suivi via `boond_validations_search`). - Écriture non idempotente — l'API ne déduplique pas deux demandes sur les mêmes dates. Returns : confirmation et fiche de la demande créée. - **boond_absences_update** — Met à jour une demande d'absence existante, identifiée par son ID. Quand : pour corriger les dates, le motif ou le commentaire d'une demande déjà déposée. Plutôt que : `boond_absences_create` si la demande n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits. - `absencesPeriods` fait exception — le tableau fourni **remplace** l'intégralité des périodes existantes. Returns : confirmation et fiche mise à jour. - **boond_absences_delete** — Supprime définitivement un(e) demande d'absence de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_absences_get`. Plutôt que : `boond_absences_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_expenses_search** — Recherche des notes de frais dans BoondManager avec filtres par ressource, projet et période. Quand : avant toute création : l'API ne déduplique pas, deux notes de frais peuvent coexister sur le même couple (ressource, mois). Plutôt que : `boond_expenses_get` pour le détail des lignes d'une note de frais identifiée. `resourceId` / `projectId` sont convertis en références `keywords` (COMP / PRJ) : l'API n'a pas de paramètre dédié. Returns: Liste des notes de frais correspondantes. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_expenses_get** — Récupère la fiche complète d'un(e) note de frais par son ID numérique. Quand : après un `boond_expenses_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_expenses_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_expenses_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_expenses_default** — Retourne les référentiels nécessaires pour saisir une note de frais pour une ressource et un mois donnés : agence, devise et taux de change agence, **types de frais** (`reference` + libellé + taux de TVA), barèmes kilométriques, et couples projet / prestation imputables. Quand : systématiquement avant `boond_expenses_create` — c'est la seule source des codes de types de frais et des couples (projet, prestation) imputables. Plutôt que : rien d'autre : `boond_application_dictionary` ne publie aucune table de types de frais, et `/agencies/{id}` ne renvoie qu'un nom. Il n'existe pas de chemin alternatif. À appeler AVANT `boond_expenses_create` : les types de frais sont définis **par agence** et ne figurent pas dans `boond_application_dictionary`. Les ids `projectId` et `deliveryId` sont obligatoires sur chaque ligne et l'API refuse un couple qu'elle ne juge pas imputable sur ce mois. Returns: Les références à recopier dans `boond_expenses_create`. - **boond_expenses_create** — Crée une note de frais dans BoondManager. Une note de frais = **un mois** (`term`) × **une ressource**, dont les lignes sont portées par `actualExpenses`. Plutôt que : `boond_expenses_update` pour ajouter des lignes à un mois déjà ouvert — mais `actualExpenses` y **remplace** tout le tableau, ce qui efface les lignes existantes si elles ne sont pas renvoyées. ⚠️ Appeler `boond_expenses_default` d'abord : il fournit `agencyId`, `currencyAgency`, `exchangeRateAgency`, les `expenseTypeReference` disponibles (définis par agence, absents de `boond_application_dictionary`) et les couples `projectId` / `deliveryId` imputables. Sans ces valeurs l'API répond 422. Sur une ligne, `amountIncludingTax` est le montant **TTC** et `tax` un **taux** de TVA en %. Le montant HT et le montant de TVA sont recalculés par BoondManager, ils ne se saisissent pas. L'état de la note de frais n'est pas pilotable ici : une création part toujours en `savedAndNoValidation`, le passage en validation relève du workflow BoondManager. Returns: Données de la note de frais créée avec son ID. - **boond_expenses_update** — Met à jour un(e) note de frais existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_expenses_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_expenses_delete** — Supprime définitivement un(e) note de frais de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_expenses_get`. Plutôt que : `boond_expenses_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_products_search** — Liste et recherche les produits de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) produit à partir de son nom, ou pour énumérer les produits existant(e)s. Plutôt que : `boond_products_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par produit. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_products_get** — Récupère la fiche complète d'un(e) produit par son ID numérique. Quand : après un `boond_products_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_products_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_products_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_products_create** — Crée un(e) produit dans BoondManager. Quand : pour ajouter un(e) produit inexistant(e). Plutôt que : `boond_products_update` pour modifier un enregistrement existant, et `boond_products_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel. - **boond_products_update** — Met à jour un(e) produit existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_products_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_products_delete** — Supprime définitivement un(e) produit de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_products_get`. Plutôt que : `boond_products_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_positionings_search** — Recherche des positionnements (placement de candidats/ressources sur des projets/opportunités) dans BoondManager. Quand : pour suivre l'avancement des profils proposés, plusieurs affaires confondues. Plutôt que : les onglets `positionings` (`boond_candidates_positionings`, `boond_opportunities_positionings`, `boond_resources_positionings`) quand on part d'une entité connue. L'API ne propose pas de paramètres de filtre dédiés : le filtrage par entité liée passe par des références dans `keywords` (AO=opportunité, CAND=candidat, COMP=ressource, CSOC=société, CCON=contact, PROD=produit). Les filtres *Id du schéma sont convertis automatiquement en ces références. Returns: Liste des positionnements correspondants. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_positionings_get** — Récupère la fiche complète d'un(e) positionnement par son ID numérique. Quand : après un `boond_positionings_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_positionings_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_positionings_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_positionings_create** — Crée un positionnement : place un candidat ou une ressource sur une opportunité ou un projet. Quand : pour matérialiser une proposition de profil au client. Plutôt que : `boond_positionings_update` pour faire avancer l'état d'un positionnement existant (proposé → retenu → refusé) plutôt que d'en créer un second. - Écriture non idempotente : rien n'empêche deux positionnements du même profil sur la même affaire. - L'état est un ID entier du dictionnaire (`boond://dictionary/states/positionings`), pas un libellé. Returns : confirmation et fiche du positionnement créé. - **boond_positionings_update** — Met à jour un positionnement existant dans BoondManager (PUT /positionings/{id}). Seuls les champs fournis sont modifiés ; `stateReasonTypeOf` / `stateReasonDetail` sont repliés en `stateReason: { typeOf, detail }`. Quand : pour faire avancer l'état d'un positionnement (proposé → retenu → refusé). Plutôt que : `boond_positionings_create` si le positionnement n'existe pas encore. Returns: Données mises à jour du positionnement. - **boond_positionings_delete** — Supprime définitivement un(e) positionnement de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_positionings_get`. Plutôt que : `boond_positionings_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_payments_create** — Enregistre un paiement / règlement fournisseur adossé à un achat. Quand : pour solder tout ou partie d'un achat existant. Plutôt que : `boond_purchases_create` si l'achat lui-même n'existe pas encore — un paiement ne peut pas être orphelin. - L'API `/payments` **exige** une relation `purchase` : sans ID d'achat valide, l'appel est refusé. - Écriture non idempotente : deux appels identiques enregistrent deux règlements. Returns : confirmation et fiche du paiement créé, avec son ID dans `structuredContent.id`. - **boond_payments_search** — Recherche des paiements / règlements fournisseur dans BoondManager. Quand : pour retrouver les règlements adossés à un achat, une société, un projet ou une ressource, ceux d'un état (`paymentStates`), d'une période (`period: "expected"` + dates) ou d'un périmètre (`perimeter*`). Plutôt que : `boond_purchases_search` pour les achats eux-mêmes, `boond_provider_invoices_search` pour les factures fournisseur. - `purchaseId`, `companyId`, `projectId` et `resourceId` sont convertis en préfixes `keywords` (`ACH`, `CSOC`, `PRJ`, `COMP`) et concaténés aux `keywords` fournis — l'API n'a pas de paramètre dédié. Pas de filtre par facture : `/payments` ne connaît pas de référence `FACT`. Returns : page de résumés des paiements (ID + libellé principal). Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_payments_get** — Récupère la fiche complète d'un(e) paiement par son ID numérique. Quand : après un `boond_payments_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_payments_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_payments_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_payments_update** — Met à jour un(e) paiement existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_payments_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_payments_delete** — Supprime définitivement un(e) paiement de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_payments_get`. Plutôt que : `boond_payments_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_advantages_search** — Liste les avantages (tickets restaurant, mutuelle, véhicule, primes...) d'une ressource. Plutôt que : `boond_resources_advantages` quand on part d'une ressource précise. `resourceId` est obligatoire : l'API n'a pas de recherche globale des avantages (`GET /advantages` n'existe pas), la liste est servie par `GET /resources/{id}/avantages`. `advantageTypes` restreint aux types `_`. Returns: Liste des avantages de la ressource. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_advantages_default** — Renvoie les valeurs par défaut d'un avantage pour une ressource (types d'avantage de l'agence, montants pré-remplis, devise) avant sa création. Quand : AVANT `boond_advantages_create` — les types (`advantageType`) et leurs quotas viennent de là. Plutôt que : `boond_advantages_search` pour les avantages déjà attribués à la ressource. - Lecture seule (`GET /advantages/default`) ; la réponse est rendue telle quelle. Returns : JSON de l'avantage vide pré-rempli, avec les types d'avantage inclus. - **boond_advantages_create** — Attribue un avantage (tickets restaurant, mutuelle, véhicule, prime…) à une ressource. Quand : après `boond_advantages_default` pour connaître les types et montants de l'agence. Plutôt que : `boond_advantages_search` d'abord : l'API ne déduplique pas. - Corps déduit de `models.advantage` (`date`, `quantity`, `advantageType`, montants, relations `resource` / `contract` / `project` / `delivery`) — non éprouvé sur un tenant de test. - Écriture non idempotente. Returns : confirmation et ID de l'avantage (`structuredContent.id`). - **boond_advantages_get** — Récupère la fiche complète d'un(e) avantage par son ID numérique. Quand : après un `boond_advantages_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_advantages_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_advantages_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_find** — Résout un libellé (« Jean Dupont », « ACME », un intitulé de projet) ou un e-mail en ID BoondManager, pour un candidat, une ressource, un contact, une société, une opportunité ou un projet. Quand : dès qu'une demande nomme une entité sans donner son ID — avant un `_get`, un `_update`, un onglet ou un filtre `perimeterManagers` / `companyId`. Plutôt que : le `*_search` du domaine quand il faut une liste filtrée (états, périmètre, pagination) plutôt qu'une résolution. - Choisit le champ à interroger : `fullName` (essayé dans les deux ordres, l'API attend `NOM#PRENOM`) puis texte libre pour les personnes, `name` pour les sociétés, `emails` quand `email` est fourni ; au plus 10 résultats. - Ne tranche jamais entre homonymes : plusieurs correspondances exactes → `isError` avec la liste (ID + détail) à soumettre à l'utilisateur ; une seule → `structuredContent.match.id`. - Aucune correspondance exacte mais des résultats proches → la liste est renvoyée sans `match` : confirmer avec l'utilisateur avant d'utiliser un ID. Returns : `{ entity, query, count, match?, ambiguous?, items[{ id, label, detail?, exact }] }` et le même contenu en texte. Lecture seule. - **boond_rights_get** — Renvoie les droits de l'utilisateur authentifié sur un enregistrement précis (lecture, écriture, suppression, actions du workflow…), tels que BoondManager les publie sur `GET /{entité}/{id}/rights`. Quand : avant un `*_update` ou un `*_delete` dont l'issue est incertaine (fiche d'une autre agence, document validé, facture clôturée) — un 403 évité coûte moins qu'un 403 expliqué. Plutôt que : `boond://application/current-user/rights` pour les droits *globaux* par entité (création, périmètre) ; cet outil est le droit sur **un** enregistrement. - Lecture seule ; le payload est rendu tel quel — les clés varient selon l'entité (`canWrite`, `canDelete`, `canValidate`…) et n'ont pas été normalisées, la RAML ne les documente pas. - Les entités proposées suivent la politique d'accès du serveur. Returns : JSON des droits sur l'enregistrement. - **boond_application_dictionary** — Récupère un dictionnaire de référence BoondManager (états, types, pays, devises, langues, outils, expertises, ...). Quand : pour traduire un état ou un type BoondManager entre son ID entier et son libellé, avant de filtrer une recherche. Plutôt que : les ressources `boond://dictionary/*` pour les tables courantes (états, typeOf, pays, devises, langues) : même contenu par un `resources/read`, sans consommer un appel d'outil. Cet outil reste nécessaire pour les tables non publiées en ressource. L'API expose un seul endpoint `/application/dictionary` qui renvoie tout — le serveur le cache (TTL 1h, configurable via `BOOND_DICTIONARY_TTL_MS`) et extrait un sous-arbre par chemin dotté. Chemins usuels de `dictionaryType` (relatifs à `data`) : - "setting.state.{resource,candidate,contact,company,opportunity,project,invoice,order,positioning}" → états par entité - "setting.typeOf.{resource,contact,project}" → types par entité - "setting.action.{candidate,resource,opportunity,project,...}" → actions disponibles - "setting.tool" → outils / technos (Java, AWS...) - "setting.expertiseArea" → domaines d'expertise - "setting.experience" → niveaux d'expérience - "setting.languageSpoken" → langues parlées - "setting.activityArea" → secteurs d'activité - "setting.mobilityArea" → mobilités géographiques - "setting.currency" → devises - "setting.civility" → civilités - "country" → pays - "languages" → langues d'interface (fr, en, es) Note : l'ancienne forme "states/resources" (slash) n'est pas valide — utilisez "setting.state.resource". Returns : le sous-arbre demandé (souvent un tableau `{id, value, …}`), ou `isError: true` avec le chemin fautif s'il est introuvable. - **boond_application_current_user** — Récupère les informations de l'utilisateur actuellement connecté à l'API BoondManager (profil, permissions, agence...). Quand : en début de session, pour connaître l'identité, l'agence et le périmètre du compte utilisé — donc ce que « mes données » désigne. Plutôt que : la ressource `boond://application/current-user`, identique et moins coûteuse ; et `boond_resources_search` pour quelqu'un d'autre que le titulaire du compte, cet outil ne prenant aucun paramètre. Returns: Données JSON de l'utilisateur courant. - **boond_contracts_search** — Recherche les contrats de travail (CDI, CDD, freelance…) des ressources d'un périmètre, avec filtres de type et de période (fins de contrat, périodes d'essai qui expirent). Quand : pour « contrats qui se terminent ce mois », « périodes d'essai qui expirent », « CDD à renouveler », ou les contrats d'une ressource. Plutôt que : `boond_resources_contracts` pour les contrats d'une seule ressource connue, `boond_contracts_get` pour la fiche complète d'un contrat. - Recherche **composée** : BoondManager n'a pas de liste de contrats (`GET /contracts` n'existe pas). L'outil sélectionne les ressources (`keywords`, `perimeter*`, `resourceStates` ; `page` / `pageSize` portent sur les ressources parcourues) puis lit l'onglet administratif de chacune : une requête par ressource — préférer des pages modestes —, progression notifiée. - `contractTypes` et `period` + `startDate` / `endDate` sont appliqués côté serveur sur les contrats lus ; un contrat sans `endDate` compte comme en cours. - `resourceId` court-circuite la sélection : seuls les contrats de cette ressource sont lus. Returns : une ligne par contrat (ressource, type, dates, fin de période d'essai, motif de fin) et `structuredContent.items[]` ; `total` = nombre de contrats retenus. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - **boond_contracts_get** — Récupère la fiche complète d'un contrat de travail par son ID numérique. Quand : après `boond_contracts_search` ou `boond_resources_contracts`, qui listent les contrats avec leurs IDs. Plutôt que : `boond_resources_contracts` pour tous les contrats d'une ressource en un appel — cet outil n'accepte pas de nom. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir d'une liste de contrats, jamais d'une supposition. Returns : JSON du contrat (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_contracts_create** — Crée un contrat de travail rattaché à une ressource. Quand : pour enregistrer un nouveau contrat (embauche, avenant, renouvellement). Plutôt que : `boond_resources_contracts` d'abord, pour vérifier qu'un contrat couvrant la même période n'existe pas déjà. - Écriture non idempotente : deux appels identiques créent deux contrats. - `typeOf` est un ID entier de `boond://dictionary/typeOf/contracts`, pas un libellé. Returns : confirmation et fiche du contrat créé, avec son ID dans `structuredContent.id`. - **boond_contracts_update** — Met à jour un(e) contrat existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_contracts_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_purchases_search** — Recherche des achats et sous-traitances dans BoondManager, avec filtres par société et projet. Quand : pour suivre les engagements de dépense et la sous-traitance. Plutôt que : `boond_provider_invoices_search` pour les factures effectivement reçues : l'achat est l'engagement, la facture fournisseur le document qui le solde. `companyId` / `projectId` sont convertis en références `keywords` (CSOC / PRJ) : l'API n'a pas de paramètre dédié. Returns: Liste des achats correspondants. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_purchases_get** — Récupère la fiche complète d'un(e) achat par son ID numérique. Quand : après un `boond_purchases_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_purchases_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_purchases_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_purchases_create** — Crée un achat ou une ligne de sous-traitance. Quand : pour engager une dépense fournisseur, généralement rattachée à un projet. Plutôt que : `boond_provider_invoices_create` pour la facture reçue du fournisseur — l'achat est l'engagement, la facture fournisseur en est le règlement attendu. - Écriture non idempotente. - Les ID de société, contact et projet sont des ID numériques BoondManager, à résoudre au préalable via les recherches correspondantes. Returns : confirmation et fiche de l'achat créé, avec son ID dans `structuredContent.id`. - **boond_purchases_update** — Met à jour un(e) achat existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_purchases_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_purchases_delete** — Supprime définitivement un achat / sous-traitance de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_purchases_get`. Plutôt que : `boond_purchases_update` pour corriger un montant, une période ou un état — vérifier avec `boond_payments_search` (`purchaseId`) qu'aucun règlement n'y est adossé avant de détruire. - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_purchases_information** — Récupère les informations complètes (période, quantité, montants, taux de TVA, conditions de paiement, ressource, projet et prestation liés) d'un(e) achat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_purchases_get` pour la fiche de base, ou `boond_purchases_search` si l'ID est inconnu. Returns : Fiche complète de l'achat (relations ressource, agence, projet, prestation incluses). Lecture seule. - **boond_provider_invoices_create** — Crée une facture fournisseur (facture reçue d'un prestataire). Quand : pour enregistrer la facture émise par un sous-traitant. Plutôt que : `boond_invoices_create` pour une facture de vente adressée à un client — les deux sens ne partagent pas d'endpoint. - `resource`, `providerCompany` et `providerContact` sont attendus sous forme d'ID numériques. - Écriture non idempotente. Returns : confirmation et fiche de la facture fournisseur créée, avec son ID dans `structuredContent.id`. - **boond_provider_invoices_search** — Liste et recherche les factures fournisseur (factures reçues des prestataires). Quand : pour suivre les factures d'achat, par fournisseur, état ou période. Plutôt que : `boond_invoices_search` pour les factures de vente adressées aux clients — sens opposé, endpoint distinct. Returns : page de résumés de factures fournisseur (référence, date, montants). Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_provider_invoices_get** — Récupère la fiche complète d'un(e) facture fournisseur par son ID numérique. Quand : après un `boond_provider_invoices_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_provider_invoices_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_provider_invoices_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_provider_invoices_update** — Met à jour un(e) facture fournisseur existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_provider_invoices_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour. - **boond_provider_invoices_delete** — Supprime définitivement un(e) facture fournisseur de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_provider_invoices_get`. Plutôt que : `boond_provider_invoices_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_accounts_search** — Liste et recherche les comptes utilisateurs de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) compte utilisateur à partir de son nom, ou pour énumérer les comptes utilisateurs existant(e)s. Plutôt que : `boond_accounts_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par compte utilisateur. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_accounts_get** — Récupère la fiche complète d'un(e) compte utilisateur par son ID numérique. Quand : après un `boond_accounts_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_accounts_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_accounts_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_agencies_search** — Liste et recherche les agences de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) agence à partir de son nom, ou pour énumérer les agences existant(e)s. Plutôt que : `boond_agencies_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par agence. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination sans effet : cette route renvoie toujours la table complète, `pageSize` et `page` sont ignorés par l'API — inutile de paginer, tout est déjà là. - **boond_agencies_get** — Récupère la fiche complète d'un(e) agence par son ID numérique. Quand : après un `boond_agencies_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_agencies_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_agencies_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_business_units_search** — Liste et recherche les business units de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) business unit à partir de son nom, ou pour énumérer les business units existant(e)s. Plutôt que : `boond_business_units_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par business unit. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_business_units_get** — Récupère la fiche complète d'un(e) business unit par son ID numérique. Quand : après un `boond_business_units_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_business_units_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_business_units_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_roles_search** — Liste et recherche les rôles de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) rôle à partir de son nom, ou pour énumérer les rôles existant(e)s. Plutôt que : `boond_roles_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par rôle. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_roles_get** — Récupère la fiche complète d'un(e) rôle par son ID numérique. Quand : après un `boond_roles_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_roles_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_roles_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_logs_search** — Recherche des logs d'audit dans BoondManager (historique des actions utilisateurs). Quand : pour retracer qui a modifié quoi et quand. Plutôt que : le `_get` du domaine concerné (`boond_candidates_get`, `boond_projects_get`…) pour l'état *actuel* d'un enregistrement : celui-ci ne renvoie que l'historique des modifications. Returns: Liste des logs correspondants. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_logs_get** — Récupère la fiche complète d'un(e) log par son ID numérique. Quand : après un `boond_logs_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_logs_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_logs_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_notifications_search** — Recherche des notifications dans BoondManager. Plutôt que : `boond_validations_search` pour ce qui requiert réellement une action de validation — une notification n'est qu'un message. ⚠️ Le paramètre `category` est REQUIS par l'API (singulier, pas de tableau). Returns: Liste des notifications correspondantes. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_notifications_get** — Récupère la fiche complète d'un(e) notification par son ID numérique. Quand : après un `boond_notifications_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_notifications_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_notifications_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_threads_search** — Liste et recherche les fils de discussion de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) fil de discussion à partir de son nom, ou pour énumérer les fils de discussion existant(e)s. Plutôt que : `boond_threads_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par fil de discussion. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_threads_get** — Récupère la fiche complète d'un(e) fil de discussion par son ID numérique. Quand : après un `boond_threads_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_threads_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_threads_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_todolists_search** — Liste et recherche les todolists de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) todolist à partir de son nom, ou pour énumérer les todolists existant(e)s. Plutôt que : `boond_todolists_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par todolist. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_todolists_get** — Récupère la fiche complète d'un(e) todolist par son ID numérique. Quand : après un `boond_todolists_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_todolists_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_todolists_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_todolists_create** — Crée une todolist (modèle de tâches) avec ses tâches ordonnées, applicable à un type de fiche. Quand : pour définir une checklist réutilisable (onboarding consultant, préparation de facturation…). Plutôt que : `boond_todolists_search` d'abord : l'API ne déduplique pas les titres. - Corps déduit de `models.todolist` (`title`, `profile`, `profileTypesOf`, `profileStates`, `tasks[]`, relation `agencies`) — non éprouvé sur un tenant de test. - Les tâches d'une fiche (`boond_tasks_get`) ne se créent pas ici : aucune route de création de tâche n'est documentée. Returns : confirmation et ID de la todolist (`structuredContent.id`). - **boond_tasks_get** — Liste les tâches (todolist instanciée) d'un candidat, d'une ressource, d'un contact, d'une société, d'une opportunité, d'un projet, d'une commande, d'un produit, d'un achat, d'un positionnement, d'une facture, d'un contrat, d'une prestation ou d'un paiement. Quand : pour voir où en est la checklist d'une fiche (tâches faites / à faire, validées par qui). Plutôt que : `boond_actions_search` pour les rappels datés — une tâche est un item de checklist, une action un événement daté. Aucune route de création de tâche n'est documentée par l'API. Returns : les tâches (`description`, `state`, `row`, `validatedAt`, `validatedBy`, sous-tâches). Lecture seule. - **boond_flags_search** — Liste et recherche les drapeaux de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) drapeau à partir de son nom, ou pour énumérer les drapeaux existant(e)s. Plutôt que : `boond_flags_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par drapeau. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_flags_get** — Récupère la fiche complète d'un(e) drapeau par son ID numérique. Quand : après un `boond_flags_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_flags_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_flags_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_flags_create** — Crée un drapeau (tag) réutilisable — « vivier Java Q4 », « à rappeler », « VIP ». Quand : avant `boond_flags_attach` quand aucun drapeau existant ne convient (`boond_flags_search` d'abord). Plutôt que : `boond_flags_attach` pour poser un drapeau existant sur un enregistrement. - Écriture non idempotente : deux appels créent deux drapeaux homonymes. - Corps déduit de `models.flag` (`name`, `mainManager`) — non éprouvé sur un tenant de test. Returns : confirmation et ID du drapeau (`structuredContent.id`). - **boond_flags_attached** — Liste les drapeaux (tags) posés sur un candidat, une ressource, un contact, une société, une opportunité, un projet, une commande, un produit, un achat, une action, un positionnement ou une facture. Quand : pour savoir comment un enregistrement est tagué avant d'ajouter ou retirer un drapeau. Plutôt que : `boond_flags_search` pour le catalogue des drapeaux existants (pas leurs rattachements). Returns : une ligne par drapeau posé (`GET /{entité}/{id}/attached-flags`). Lecture seule. - **boond_flags_attach** — Pose un drapeau existant sur un enregistrement (tagging) — `POST /attached-flags`. Quand : pour marquer un lot de fiches après un tri (« ces 12 candidats → vivier Java Q4 ») : un appel par fiche. Plutôt que : `boond_flags_create` si le drapeau n'existe pas encore ; `boond_flags_detach` pour le retirer. - Corps JSON:API `{ relationships: { flag, dependsOn } }` déduit du modèle — la RAML ne documente que la route ; non éprouvé sur un tenant de test. - Idempotent côté intention : reposer un drapeau déjà présent ne doit rien changer. Returns : `{ entity, id, flagId, attached: true }`. - **boond_flags_detach** — Retire un drapeau d'un enregistrement — `DELETE /attached-flags?flag=&=` (route et paramètres documentés dans la RAML). Quand : pour dé-taguer une fiche ; réversible par `boond_flags_attach`, le drapeau lui-même n'est pas supprimé. Plutôt que : aucun outil ne supprime un drapeau du catalogue : un drapeau se retire fiche par fiche. - Idempotent : retirer un drapeau absent n'échoue pas côté intention (l'erreur API éventuelle est remontée telle quelle). Returns : `{ entity, id, flagId, attached: false }`. - **boond_calendars_search** — Liste et recherche les calendriers de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) calendrier à partir de son nom, ou pour énumérer les calendriers existant(e)s. Plutôt que : `boond_calendars_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par calendrier. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination sans effet : cette route renvoie toujours la table complète, `pageSize` et `page` sont ignorés par l'API — inutile de paginer, tout est déjà là. - **boond_calendars_get** — Récupère la fiche complète d'un(e) calendrier par son ID numérique. Quand : après un `boond_calendars_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_calendars_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_calendars_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_webhooks_search** — Liste et recherche les webhooks de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) webhook à partir de son nom, ou pour énumérer les webhooks existant(e)s. Plutôt que : `boond_webhooks_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par webhook. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination sans effet : cette route renvoie toujours la table complète, `pageSize` et `page` sont ignorés par l'API — inutile de paginer, tout est déjà là. - **boond_webhooks_get** — Récupère la fiche complète d'un(e) webhook par son ID numérique. Quand : après un `boond_webhooks_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_webhooks_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_webhooks_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_validations_search** — Recherche des validations en attente dans BoondManager (absences, notes de frais, feuilles de temps...). Quand : pour lister ce qui attend une validation managériale sur une plage de mois. Plutôt que : `boond_absences_search`, `boond_expenses_search` ou `boond_timesheets_search` pour les documents eux-mêmes : celui-ci renvoie l'en-cours de validation, pas leur contenu. ⚠️ `startMonth` et `endMonth` (YYYY-MM) sont requis par l'API. Returns: Liste des validations correspondantes. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_validations_get** — Récupère la fiche complète d'un(e) validation par son ID numérique. Quand : après un `boond_validations_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_validations_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_validations_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_validations_update** — Approuve (`validate`) ou refuse (`reject`) une validation en attente : CRA, note de frais ou demande d'absence. Quand : après `boond_validations_search` (`validationStates: ["waitingForValidation"]`) et l'examen du document (`boond_timesheets_get`, `boond_expenses_get`, `boond_absences_get`). Plutôt que : `boond_validations_get` pour relire la validation avant de décider ; il n'existe pas d'autre chemin d'écriture sur le workflow de validation (`state` n'est pas un champ des CRA / notes / absences). - `PUT /validations/{id}` avec `state: validated | rejected` (le vocabulaire de `validationStates`) et `reason`. Route déduite du modèle `validation` et non éprouvée sur un tenant de test : un 404 / 405 doit être remonté tel quel. - Un **refus** demande une confirmation à l'utilisateur final si le client MCP déclare la capacité `elicitation` (désactivable par `BOOND_MCP_CONFIRM_REJECT=0`) ; un refus de confirmer renvoie `decided: false` sans appel API. - Idempotent : rejouer la même décision renvoie le même état. Returns : `{ id, decided, state, documentType, documentId, reason? }` et la fiche de la validation mise à jour. - **boond_poles_search** — Liste et recherche les pôles de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) pôle à partir de son nom, ou pour énumérer les pôles existant(e)s. Plutôt que : `boond_poles_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par pôle. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination sans effet : cette route renvoie toujours la table complète, `pageSize` et `page` sont ignorés par l'API — inutile de paginer, tout est déjà là. - **boond_poles_get** — Récupère la fiche complète d'un(e) pôle par son ID numérique. Quand : après un `boond_poles_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_poles_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_poles_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule. - **boond_reporting_companies** — Reporting des sociétés (CA, marge, activité...). Quand : pour obtenir des agrégats (CA, marge, taux, volumes) sur un périmètre et une période. Plutôt que : `boond_companies_search` pour la liste des enregistrements eux-mêmes : ce reporting renvoie des totaux calculés, pas les lignes qui les composent. Filtres clés : périmètre (`perimeterDynamic` / `perimeterManagers` / `perimeterAgencies`…), période (`period`, `periodDynamic`), companiesStates, companies, maxCompanies, showPercentage. - ⚠️ `startDate` + `endDate` (YYYY-MM-DD) sont REQUIS : l'API répond 422 sans eux. - Sans filtre de périmètre, l'agrégation porte sur **tout** le périmètre autorisé du compte — un total « entreprise » là où l'utilisateur attendait souvent son équipe. - Les états et types sont des ID entiers du dictionnaire (`boond_application_dictionary`), pas des libellés. - Une agrégation large peut durer plusieurs dizaines de secondes ; l'avancement est signalé via `notifications/progress` quand le client fournit un `progressToken`. Returns : tableau d'indicateurs agrégés, rendu en texte. Lecture seule. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_reporting_projects** — Reporting des projets (CA, marge, rentabilité...). Quand : pour obtenir des agrégats (CA, marge, taux, volumes) sur un périmètre et une période. Plutôt que : `boond_projects_search` pour la liste des enregistrements eux-mêmes : ce reporting renvoie des totaux calculés, pas les lignes qui les composent. Filtres clés : périmètre (`perimeterDynamic` / `perimeterManagers` / `perimeterAgencies`…), période (`period`, `periodDynamic`), projectTypes, projectStates, resources, projects, contacts, companies, maxProjects. - Sans filtre de périmètre, l'agrégation porte sur **tout** le périmètre autorisé du compte — un total « entreprise » là où l'utilisateur attendait souvent son équipe. - Les états et types sont des ID entiers du dictionnaire (`boond_application_dictionary`), pas des libellés. - Une agrégation large peut durer plusieurs dizaines de secondes ; l'avancement est signalé via `notifications/progress` quand le client fournit un `progressToken`. Returns : tableau d'indicateurs agrégés, rendu en texte. Lecture seule. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_reporting_resources** — Reporting des ressources (taux d'occupation, CA, productivité...). Quand : pour obtenir des agrégats (CA, marge, taux, volumes) sur un périmètre et une période. Plutôt que : `boond_resources_search` pour la liste des enregistrements eux-mêmes : ce reporting renvoie des totaux calculés, pas les lignes qui les composent. Filtres clés : périmètre (`perimeterDynamic` / `perimeterManagers` / `perimeterAgencies`…), période (`period`, `periodDynamic`), reportingCategory, resourceTypes, resourceStates, period, resources/projects/contacts/companies, maxResources. - Sans filtre de périmètre, l'agrégation porte sur **tout** le périmètre autorisé du compte — un total « entreprise » là où l'utilisateur attendait souvent son équipe. - Les états et types sont des ID entiers du dictionnaire (`boond_application_dictionary`), pas des libellés. - Une agrégation large peut durer plusieurs dizaines de secondes ; l'avancement est signalé via `notifications/progress` quand le client fournit un `progressToken`. Returns : tableau d'indicateurs agrégés, rendu en texte. Lecture seule. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_reporting_synthesis** — Reporting de synthèse globale (commercial, RH, recrutement, facturation...). Quand : pour obtenir des agrégats (CA, marge, taux, volumes) sur un périmètre et une période. Plutôt que : un `boond_reporting_*` plus ciblé (sociétés, projets, ressources) pour la liste des enregistrements eux-mêmes : ce reporting renvoie des totaux calculés, pas les lignes qui les composent. Filtres clés : périmètre (`perimeterDynamic` / `perimeterManagers` / `perimeterAgencies`…), période (`period`, `periodDynamic`), reportingType, reportingCategory, period, resources/projects/contacts/companies, compareIndicators. - ⚠️ `startDate` + `endDate` (YYYY-MM-DD) sont REQUIS : l'API répond 422 sans eux. - Sans filtre de périmètre, l'agrégation porte sur **tout** le périmètre autorisé du compte — un total « entreprise » là où l'utilisateur attendait souvent son équipe. - Les états et types sont des ID entiers du dictionnaire (`boond_application_dictionary`), pas des libellés. - Une agrégation large peut durer plusieurs dizaines de secondes ; l'avancement est signalé via `notifications/progress` quand le client fournit un `progressToken`. Returns : tableau d'indicateurs agrégés, rendu en texte. Lecture seule. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_reporting_production_plans** — Reporting des plans de production (disponibilités, positionnements...). Quand : pour obtenir des agrégats (CA, marge, taux, volumes) sur un périmètre et une période. Plutôt que : `boond_positionings_search` pour la liste des enregistrements eux-mêmes : ce reporting renvoie des totaux calculés, pas les lignes qui les composent. Filtres clés : périmètre (`perimeterDynamic` / `perimeterManagers` / `perimeterAgencies`…), période (`period`, `periodDynamic`), resourceTypes, resourceStates, positioningStates, positioningPeriod, showContracts, projects/contacts/companies. - ⚠️ `startDate` + `endDate` (YYYY-MM-DD) sont REQUIS : l'API répond 422 sans eux. - Sans filtre de périmètre, l'agrégation porte sur **tout** le périmètre autorisé du compte — un total « entreprise » là où l'utilisateur attendait souvent son équipe. - Les états et types sont des ID entiers du dictionnaire (`boond_application_dictionary`), pas des libellés. - Une agrégation large peut durer plusieurs dizaines de secondes ; l'avancement est signalé via `notifications/progress` quand le client fournit un `progressToken`. Returns : tableau d'indicateurs agrégés, rendu en texte. Lecture seule. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_planning_absences_search** — Recherche le planning des absences dans BoondManager (vue globale des absences prévues). Quand : pour savoir qui est absent sur une période — une vue calendaire, pas un suivi de demandes. Plutôt que : `boond_absences_search` pour les demandes elles-mêmes (motif, état de validation, demandeur), que cette vue ne détaille pas. Returns: Planning des absences. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres. - **boond_inactivities_default** — Renvoie les valeurs par défaut d'une période d'inactivité (intercontrat, formation, congé sans solde…) pour une ressource : types d'inactivité, coût journalier retenu, contrat en cours. Quand : AVANT `boond_inactivities_create` — le type d'inactivité n'est publié que là. Plutôt que : `boond_resources_get` pour la fiche de la ressource ; `boond_reporting_resources` pour le taux d'occupation agrégé. - Lecture seule (`GET /inactivities/default?resource=`) ; la réponse est rendue telle quelle. Returns : JSON de l'inactivité vide pré-remplie, avec les types inclus. - **boond_inactivities_get** — Récupère une période d'inactivité (intercontrat, formation…) par son ID. Quand : après `boond_inactivities_create`, ou depuis l'ID lu dans les relations d'une ressource. Plutôt que : il n'existe pas de liste des inactivités côté API (`GET /inactivities` n'est pas documenté) : `boond_reporting_resources` donne l'occupation, `boond_resources_get` la fiche. Returns : JSON de la période (attributs + relations). Lecture seule. - **boond_inactivities_create** — Déclare une période d'inactivité (intercontrat, formation interne, congé sans solde…) pour une ressource, entre deux prestations. Quand : quand une ressource sort de mission sans relais immédiat — c'est ce qui rend le taux d'occupation et le coût de l'intercontrat justes. Plutôt que : `boond_absences_create` pour une absence (congés, maladie) ; `boond_deliveries_create` pour une nouvelle prestation. - Corps déduit de `models.inactivity` (`title`, `startDate`, `endDate`, `inactivityType`, coûts, relations `resource` / `contract`) — non éprouvé sur un tenant de test. - Écriture non idempotente. Returns : confirmation et ID de la période (`structuredContent.id`). - **boond_forms_default** — Renvoie un formulaire vide pré-rempli pour un modèle et une entité (questions du modèle, validateur et destinataire par défaut). Quand : AVANT `boond_forms_create`, pour connaître les questions et les dates que le modèle attend. Plutôt que : `boond_forms_get` pour un formulaire déjà créé. - Lecture seule (`GET /forms/default?template=&resource=`) ; la réponse est rendue telle quelle. Returns : JSON du formulaire vide (questions incluses). - **boond_forms_get** — Récupère un formulaire (entretien annuel, bilan de fin de mission, évaluation) par son ID : questions, réponses, état, validateur. Quand : après `boond_forms_create`, ou depuis l'ID lu dans les relations d'une ressource / d'un candidat. Plutôt que : il n'existe pas de liste des formulaires côté API (`GET /forms` n'est pas documenté) ; `boond_tasks_get` avec `entity: "form"` pour ses tâches. Returns : JSON du formulaire (attributs + relations). Lecture seule. - **boond_forms_create** — Instancie un formulaire à partir d'un modèle (entretien annuel, bilan de fin de mission, évaluation) pour une ressource ou un candidat. Quand : pour lancer une campagne d'évaluation ou un bilan, formulaire par formulaire. Plutôt que : `boond_forms_default` d'abord, pour les questions et les dates attendues par le modèle. - Corps déduit de `models.form` (`template`, `dependsOn`, `validator`, `recipient`, `validateDate`, `remindDate`) — non éprouvé sur un tenant de test ; exactement une entité visée parmi `resourceId` / `candidateId`. - Écriture non idempotente. Returns : confirmation et ID du formulaire (`structuredContent.id`). - **boond_groupments_default** — Renvoie un regroupement vide pré-rempli pour un projet : prestations regroupables, prix et coûts par défaut. Quand : AVANT `boond_groupments_create`. Plutôt que : `boond_projects_deliveries_groupments` pour les prestations et regroupements déjà en place sur le projet. - Lecture seule (`GET /groupments/default?project=`) ; la réponse est rendue telle quelle. Returns : JSON du regroupement vide, prestations incluses. - **boond_groupments_get** — Récupère un regroupement de prestations (facturation multi-prestations) par son ID. Quand : depuis l'ID lu dans `boond_projects_deliveries_groupments`. Plutôt que : `boond_projects_deliveries_groupments` pour la liste des regroupements d'un projet — il n'y a pas de liste globale. Returns : JSON du regroupement (attributs + relations `project`, `deliveries`). Lecture seule. - **boond_groupments_create** — Regroupe plusieurs prestations d'un projet sous un même prix et une même période, pour les facturer ensemble. Quand : pour la facturation multi-prestations (forfait sur plusieurs consultants, lot). Plutôt que : `boond_groupments_default` d'abord ; `boond_groupments_update` pour ajuster un regroupement existant. - Corps déduit de `models.groupment` (`title`, dates, prix / coûts journaliers, relations `project` / `deliveries`) — non éprouvé sur un tenant de test. - Écriture non idempotente. Returns : confirmation et ID du regroupement (`structuredContent.id`). - **boond_groupments_update** — Met à jour un(e) regroupement de prestations existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_groupments_create` si l'enregistrement n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. Returns : confirmation et fiche mise à jour. - **boond_alerts_search** — Liste les indicateurs d'alerte configurés sur le tableau de bord de l'utilisateur (fins de contrat, périodes d'essai, CRA / notes / absences non validés, actions à venir…) avec leurs seuils : période en jours, états visés, périmètre. Quand : en premier, pour « qu'est-ce qui demande mon attention aujourd'hui ? » — la liste dit *quoi* surveiller et avec quels seuils ; l'outil `*_search` du module donne les éléments. Plutôt que : la ressource `boond://alerts/me` (même contenu en JSON) ; le prompt `attention_du_jour` enchaîne indicateur → recherche. - `GET /alerts` renvoie la **configuration** des indicateurs, pas des occurrences (vérifié le 2026-09-26) : une ligne par indicateur, `params.period` en jours (`-1` = mois précédent), `X` / `Y` = IDs d'états ou de types, `perimeter` (`dynamic_data` = mes données). Aucun filtre, aucune pagination, pas de `/alerts/{id}`. - Correspondances : `contractsEndedUpcoming` → `boond_contracts_search` `period: "ending"` ; `resourcesProbationaryDateUpcoming` → `period: "probationEnding"` ; `timesReportsWithNoValidation` / `expensesReportsWithNoValidation` / `absencesReportsWithNoValidation` → `boond_validations_search` (`documentTypes`, `waitingForValidation`) ; `actionsUpcoming` → `boond_actions_search` `period: "started"`. Returns : une ligne par indicateur (`module`, `indicator`, paramètres, cadence de rapport) et `structuredContent.items[]`. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - **boond_documents_get** — Télécharge un document BoondManager (CV de candidat/ressource, justificatif, contrat, facture...) par son ID, et le rend lisible : texte extrait pour un PDF ou un DOCX, contenu `image` (visible par le modèle) pour une image, texte brut pour un fichier texte. Quand : pour récupérer le contenu d'un CV ou d'un justificatif dont l'ID a été relevé dans un onglet d'entité. Plutôt que : `boond_candidates_information` / `boond_candidates_administrative` (relations `resumes` / `files`) pour *trouver* l'ID : celui-ci exige un ID exact, suffixe compris (`123_resume`), et un ID tronqué désigne un autre document. Où trouver les IDs de documents : dans les onglets des entités — ex. boond_candidates_information expose les relations 'resumes' (CV) et 'files' (dossier administratif). ⚠️ Reprendre l'ID **tel quel**, suffixe compris (ex. '123_resume') : un ID tronqué à sa partie numérique ne désigne aucun document. `mode: "text"` (défaut) : PDF / DOCX → texte extrait côté serveur (borné à 50000 caractères, taille et nombre de pages d'origine indiqués) ; image PNG / JPEG / GIF / WebP → contenu `image` jusqu'à 2 Mo. Un PDF scanné ou chiffré, dont rien ne s'extrait, est renvoyé tel quel avec un avertissement. `mode: "raw"` : le fichier tel quel en ressource embarquée (base64) — coûteux en contexte, à réserver aux cas où les octets sont nécessaires (transfert, format non géré). Taille max téléchargée : 5 Mo. Returns : texte extrait, contenu `image`, ou ressource embarquée (`blob` base64) selon le format et le mode. Un ID inconnu est rejeté explicitement plutôt que de renvoyer la page d'accueil BoondManager, que l'API sert en HTTP 200 à la place d'un 404. - **boond_documents_upload_slot** — Ouvre un slot d'upload à usage unique sur le relais de stockage configuré par l'opérateur (`BOOND_MCP_UPLOAD_RELAY`, ex. SharePoint), pour transmettre à BoondManager un fichier qui n'est ni à une URL publique ni sur le poste du serveur — typiquement une pièce jointe de conversation, présente dans l'environnement d'exécution de code du client. Quand : pour attacher à Boond une pièce jointe de conversation (fichier présent dans l'environnement d'exécution de code, pas sur le poste du serveur). Plutôt que : `boond_documents_create` directement si le fichier est à une URL publique (`fileUrl`) ou sur le poste du serveur (`filePath`). Ne jamais retranscrire la pièce jointe en base64 : passer par ce slot. Déroulé : (1) appeler cet outil avec le nom du fichier ; (2) déposer le fichier sur `uploadUrl` en **une seule requête PUT** depuis l'environnement d'exécution, avec la commande `curl` renvoyée — les octets ne passent pas par la réponse du modèle ; (3) appeler `boond_documents_create` avec `uploadSlot`. Le fichier est vérifié (taille, premiers octets), transmis à Boond par une URL de lecture temporaire, puis supprimé définitivement du relais. Slot valable 15 min, un seul fichier, un seul usage. `uploadUrl` est pré-authentifiée : ne pas la réutiliser ni la partager. Returns: `uploadSlot`, `uploadUrl`, `expiresAt`, `maxBytes`, `fileName` et la commande d'upload. - **boond_documents_create** — Attache un document à une entité BoondManager. Exactement une source par appel : - `fileUrl` : URL https que BoondManager télécharge lui-même ; - `filePath` : chemin absolu d'un fichier local, lu par le serveur MCP — transport stdio uniquement, sous un répertoire de `BOOND_MCP_UPLOAD_DIRS` (désactivé par défaut) ; - `uploadSlot` : fichier déposé sur un slot de `boond_documents_upload_slot` — **la voie pour une pièce jointe de conversation** ; - `fileContent` (base64) + `fileName` : petit fichier inline, 2 Mo max, réservé à un appelant qui détient déjà les octets exacts (un modèle ne retranscrit pas fiablement une pièce jointe en base64). Quand : pour attacher un fichier à une entité : URL publique, fichier local (si l'opérateur l'a autorisé), slot du relais d'upload ou petit fichier en base64. Plutôt que : aucune alternative : c'est le seul outil d'écriture de documents. Si `filePath` est refusé (transport HTTP ou BOOND_MCP_UPLOAD_DIRS non défini), passer par `fileUrl` ou, sous 2 Mo, par `fileContent`. Le format est vérifié sur les premiers octets du fichier (PDF, Office, ODF, RTF, images), pas sur l'extension. Cas d'usage typiques : CV d'un candidat (parentType=candidateResume, parsing=true pour l'analyse IA Boond), pièce jointe d'un besoin / AO (parentType=opportunity), d'un positionnement (positioning), justificatif de note de frais (expensesReport), bon de commande, contrat... `parentType` n'est pas limité à une liste fermée : il est transmis tel quel à BoondManager, qui valide le type. Un type que l'API ne gère pas est refusé sans rien écrire. Returns: Métadonnées du document créé (ID). - **boond_documents_delete** — Supprime définitivement un document (CV, justificatif, pièce jointe) de BoondManager. Quand : pour retirer une pièce jointe erronée, sur demande explicite de l'utilisateur. Plutôt que : `boond_documents_get` d'abord, pour confirmer qu'il s'agit du bon fichier — les ID de documents sont suffixés et un ID mal recopié pointe sur autre chose. ⚠️ Irréversible, sans corbeille côté API. Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur. - **boond_workflow_synthese_equipe** — Produit un état d'équipe : qui est sur quoi, qui est absent, qui est disponible. Si manager_id est omis, utilise l'utilisateur courant comme manager. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `synthese_equipe` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_pipeline_commercial** — Analyse les opportunités commerciales avec closing prévu dans la période donnée : répartition par état, CA pondéré, top opportunités. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `pipeline_commercial` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_factures_a_relancer** — Liste les factures impayées avec date d'échéance dépassée, regroupées par société. Optionnellement filtrable sur une société spécifique. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `factures_a_relancer` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_candidats_pour_opportunite** — À partir d'une opportunité (ses outils, expertise, mobilité), trouve les candidats actifs qui matchent. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `candidats_pour_opportunite` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_fiche_consultant** — Vue 360° d'une ressource : info, profil technique, positionnements, absences, CRA récents. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `fiche_consultant` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_staffing_disponible** — Identifie les ressources internes disponibles pour un staffing sur une fenêtre donnée, avec filtres optionnels par compétences (texte libre) et périmètre. Trie par date de disponibilité croissante et propose les profils prioritaires à activer. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `staffing_disponible` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_fin_de_mission** — Liste les ressources dont la mission se termine dans les prochains jours, pour anticiper le repositionnement. Met en évidence les fins imminentes sans relais identifié. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `fin_de_mission` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_cartographie_competences** — Produit une cartographie des compétences techniques d'un périmètre (équipe, agence, …) : top compétences, compétences rares (risque bus-factor) et compétences manquantes vs opportunités ouvertes. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `cartographie_competences` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_cvs_a_mettre_a_jour** — Identifie les ressources dont le CV ou le dossier technique est obsolète, incomplet, ou manquant. Priorise celles bientôt sur le marché (en intercontrat ou disponibles à court terme). Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `cvs_a_mettre_a_jour` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_recherche_profil_competences** — Recherche un profil correspondant à un mix de compétences libres, en croisant ressources internes et candidats. Sortie classée par adéquation. Utile en amont d'un staffing ou d'une opportunité non encore qualifiée. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `recherche_profil_competences` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_recap_hebdo** — Compile en une vue ce qui s'est passé / va se passer cette semaine pour moi et mon équipe : opportunités, projets, absences, CRA. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `recap_hebdo` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_traiter_note_de_frais** — À partir d'une photo ou d'un PDF de justificatif joint à la conversation, extrait les données de la dépense et crée la ligne de frais correspondante dans BoondManager, après récapitulatif et validation explicite. Aucun montant n'est inventé : un champ illisible est demandé à l'utilisateur. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `traiter_note_de_frais` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_alertes_contrats** — Liste les contrats de travail qui se terminent et les périodes d'essai qui expirent dans les prochains jours sur un périmètre, pour anticiper renouvellements, ruptures et entretiens de fin de PE. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `alertes_contrats` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_relance_cra** — Pour un mois et une équipe : qui n'a pas saisi son CRA, qui l'a saisi sans le soumettre, et quels CRA attendent la validation du manager — avec la liste à relancer et les validations à traiter. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `relance_cra` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_absences_a_valider** — Liste les demandes d'absence en attente de validation sur une équipe, les recoupe avec les absences déjà posées sur la période, et prépare la décision (validation ou refus motivé) pour chacune. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `absences_a_valider` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_marge_projet** — Compare le chiffre d'affaires, les coûts et la marge simulés d'un projet à son réalisé (productivité, reporting), prestation par prestation, et explique l'écart. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `marge_projet` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_preparation_entretien** — Rassemble en une fiche tout ce que BoondManager sait d'un candidat (parcours, compétences, CV, positionnements, historique des échanges) et, si une opportunité est visée, confronte le profil au besoin pour lister les points à creuser. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `preparation_entretien` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_preparation_rdv_client** — Brief de rendez-vous pour une société cliente : contacts, opportunités en cours, projets et prestations, factures impayées, derniers échanges — et les sujets à aborder. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `preparation_rdv_client` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_relance_devis** — Trouve les opportunités en phase de proposition envoyée / négociation sans action depuis N jours sur un périmètre, et prépare les relances. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `relance_devis` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_purge_rgpd_candidats** — Identifie les candidats sans mise à jour ni positionnement actif depuis N mois, présente la liste à confirmer, puis supprime candidat par candidat avec confirmation — jamais en lot silencieux. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `purge_rgpd_candidats` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_preparation_facturation** — Pour un mois : CRA validés, prestations en cours et commandes concernées, reste à facturer par commande, factures déjà émises — et la liste de ce qui bloque (CRA manquants ou non validés). Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `preparation_facturation` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_ingest_communication** — À partir d'un e-mail, d'un compte rendu d'appel ou d'une note de réunion collés dans la conversation : extrait les entités (contact, société, engagements), déduplique contre BoondManager, présente le plan d'écriture, puis crée ou rattache contact / société / action après validation explicite. Aucun Sampling : c'est le modèle qui extrait. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `ingest_communication` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_attention_du_jour** — Lit les indicateurs d'alerte configurés sur le tableau de bord (fins de contrat, périodes d'essai, CRA / notes / absences non validés, actions à venir…), exécute la recherche correspondante avec les seuils configurés, et classe ce qui en sort par urgence. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `attention_du_jour` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. - **boond_workflow_saisir_cra** — Saisit la feuille de temps (CRA) d'un collaborateur pour un mois : référentiels de saisie, planning prévu, vérification d'un CRA existant, récapitulatif validé par l'utilisateur, puis création ou mise à jour. Quand : pour dérouler ce scénario multi-étapes sans avoir à retrouver soi-même le bon enchaînement d'outils et les bons noms de filtres. Plutôt que : le prompt MCP `saisir_cra` si le client l'expose — contenu identique, sans consommer un appel d'outil. Cette variante existe pour les clients qui traitent mal `prompts/get` (claude.ai notamment). - N'appelle aucune API BoondManager et ne lit aucune donnée : la réponse est générée côté serveur MCP. Returns : un runbook en texte — la liste ordonnée des appels Boond à effectuer, avec les filtres exacts. C'est ensuite au modèle de les exécuter ; rien n'est fait par cet appel. ## Claude Desktop Quick Installation Install path detected from listing signals. Uses `npx` (confidence: high): ```json "mcpServers": { "boondmanager-mcp-server": { "command": "npx", "args": ["-y","boondmanager-mcp-server"] } } ``` ## Documentation ## What BoondManager MCP Server MCP server does BoondManager MCP Server connects MCP clients to the BoondManager API and makes business records available through agent-callable tools. It supports read and write operations across CRM, project management, finance, human resources, activity tracking, reporting, and administration. Main entities include candidates, resources, contacts, companies, opportunities, projects, invoices, orders, expenses, absences, actions, and products. Several major entities also expose focused tools for related tabs, such as projects, actions, opportunities, orders, invoices, timesheets, or expense reports. Operations depend on the domain. Available patterns include search and get, full CRUD, targeted create or delete operations, simulations, reporting searches, and document handling. Documents and CVs can be retrieved, created through several upload methods, or deleted. ## How it works The server communicates with MCP clients and calls the BoondManager API on their behalf. Tools return readable text, while search, create, update, and delete operations also provide structured MCP output when the client supports it. Search results use a compact collection shape with counts and items; create and update identify the affected entity; delete reports the entity ID and deletion status. Get operations remain text-based and return JSON that can be consumed by the client. MCP resources expose reference data without requiring a separate tool call. The available resource families include the current user profile, entity states, entity types, and action types. These dictionaries can help an agent interpret integer values such as an entity state or type. ## Setup and configuration The repository provides one-click installation links for Cursor and VS Code. The shown client configuration runs the package with `npx -y boondmanager-mcp-server`. The README also identifies dedicated installation procedures for LM Studio and Gemini CLI, and mentions Claude Desktop, Claude Cowork, Claude Code, and Goose as supported installation contexts. Authentication and instance configuration should therefore be checked in the repository’s installation documentation before deployment. ## Tools and capabilities BoondManager MCP Server MCP server includes tools for: - Searching and retrieving CRM entities and their related records. - Creating, updating, and deleting supported business records. - Managing projects, deliveries, purchases, orders, invoices, payments, and expenses. - Working with resources, candidates, contracts, absences, benefits, and timesheets. - Searching activity actions, validations, todolists, and reporting views. - Reading administration data such as users, agencies, business units, roles, calendars, webhooks, audit logs, and notifications. - Uploading documents or CVs by URL, local file, relay slot, or base64 with CV parsing. - Reading MCP dictionary resources for states, types, actions, and the current user. ## Limitations and notes The server’s capabilities depend on the permissions of the connected BoondManager user. The current-user resource includes profile, agency, and permission information, which can help determine access. Structured output is available only for the documented search, create, update, and delete operations; get tools return text containing JSON instead. Dictionary resources are useful only in clients that support MCP resource display. BoondManager MCP Server MCP server is suited to workflows that need broad BoondManager coverage, but the exact operation set varies by domain. Consult the generated tool catalogue for the complete list of tools, prompts, and resources. _Full upstream README: https://allmcps.com/mcp/boondmanager-mcp-server/readme_