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

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.

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.

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

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.

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 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 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: [<X_id>] (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: [<id>], resourceTypes: [<id>]. 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: [<toolId>, ...] (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 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) 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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

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

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

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

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.

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.

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

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

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.

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: [<X_id>] (combiner avec perimeterManagersType: "main"|"hr"). • États / types : opportunityStates: [<id>] (dictionnaire setting.state.opportunity), opportunityTypes: [<id>] (setting.typeOf.project). IDs entiers issus du dictionnaire. • Lié à une société/contact/candidat : utiliser keywords avec préfixes — "CSOC<id>" (société), "CCON<id>" (contact), "CAND<id>" (candidat), "COMP<id>" (ressource), "PROD<id>" (produit), "AO<id>" (opportunité). • Métier : activityAreas, expertiseAreas, tools, places (zones), durations, origins. • Positionnements : positioningStates: [<id>] 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 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) 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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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: [<X_id>]. • États / types : projectStates: [<id>] (dictionnaire setting.state.project), projectTypes: [<id>] (setting.typeOf.project). IDs entiers. • Société cliente : companies: [<companyId>] (filtre les projets rattachés à ces sociétés). • Lié à un contact / opportunité / contrat / ressource / produit : utiliser keywords avec préfixes — "PRJ<id>" (projet), "CSOC<id>" (société), "CCON<id>" (contact), "AO<id>" (opportunité), "CTR<id>" (contrat), "COMP<id>" (ressource), "PROD<id>" (produit), "MIS<id>" (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 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) 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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<id>, PRJ<id>) — 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 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) 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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

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.

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.

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.

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<id>, CSOC<id>, PRJ<id>, COMP<id>) 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<id>.

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

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.

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.

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

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.

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

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.

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.

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.

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

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 listés (noms inconnus ignorés). À utiliser sur les grosses pages.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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

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

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

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

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

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.

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

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

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.

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

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

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

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

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.

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

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.

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.

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.

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.

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.

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

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.

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

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

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

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.

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 listés (noms inconnus ignorés). À utiliser sur les grosses pages.

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.

Attache un document à une entité BoondManager à partir d'une URL (l'API BoondManager télécharge elle-même le fichier — aucun fichier local n'est lu).

Quand : pour attacher à une entité un fichier accessible par URL publique. Plutôt que : aucune alternative pour un fichier local : le serveur MCP ne lit jamais le disque, c'est BoondManager qui télécharge l'URL. Il faut donc d'abord héberger le fichier quelque part d'atteignable.

Cas d'usage typiques : attacher un CV à un candidat (parentType=candidateResume, parsing=true pour lancer l'analyse IA Boond), joindre un justificatif à une note de frais (expensesReport), un document à un projet/une société...

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.