BoondManager MCP Server

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.

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.

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.

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.

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<id> : 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.

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.

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.

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.

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.

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.

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.

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<id> / COMP<id> / CCON<id> / CSOC<id>) : 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.

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.

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`).

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.

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.

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 `<reference>_<agencyId>`. 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.

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.

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à.

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.

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.

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.

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.

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.

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.

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à.

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.

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.

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.

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.

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.

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.

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.

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.

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: [<X_id>]` (utiliser `perimeterManagersType: "main"|"hr"` pour cibler Main vs HR Manager). • **États / types** : `candidateStates: [<id>]` (dictionnaire `setting.state.candidate`), `candidateTypes` (`setting.typeOf.resource`), `contractTypes`, `availabilityTypes`. IDs entiers issus du dictionnaire. • **Profil technique** : `tools: [<id>]` (OU; pour ET: `["#AND#", "1", "2"]`), `expertiseAreas`, `activityAreas`, `experiences`, `trainings`, `mobilityAreas`, `languages` (format `langueId|niveauId`). • **Sourcing** : `sources: [<id>]` (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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.