BoondManager MCP Server

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: [<X_id>]`. • **États** : `states: [<id>]` (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<id>"`. 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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: [<X_id>]`. • **Contacts d'une société donnée** : utiliser `keywords: "CSOC<companyId>"` (préfixe CSOC + ID). Exemple : `keywords: "CSOC6420"` pour la société 6420. • **États / types** : `states: [<id>]` (dictionnaire `setting.state.contact`), `typesOf: [<id>]` (⚠️ 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.

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.

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

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.

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.

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.

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

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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<id> / PRJ<id>) : 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.

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.

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.

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

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.

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

Retire un drapeau d'un enregistrement — `DELETE /attached-flags?flag=&<entité>=` (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 }`.

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.

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.

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

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

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.

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

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.

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.

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.

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

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.

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.

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.