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

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

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

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.

• ⚠️ 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).

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

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

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.

• ⚠️ 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.

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

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

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

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.

• ⚠️ 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).

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

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

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.

• ⚠️ 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).

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

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

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.

• ⚠️ 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 avec filtres optionnels par candidat, ressource, contact ou société.

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.

Args:

• keywords (string, optional): Termes de recherche

• candidateId, resourceId, contactId, companyId (string, optional): Filtrer par entité liée

• page, pageSize: Pagination

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.

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.

Args:

• typeOf (number, requis): ID numérique du type d'action (dictionnaire setting.action.*, via boond_application_dictionary)

• title, text (string, optional): Titre et contenu de l'action

• startDate, endDate (string, optional): Dates ISO avec timezone (ex: 2026-06-05T10:00:00+0200)

• contactId | candidateId | resourceId | opportunityId | projectId (string, un requis): Entité de rattachement

• companyId (string, optional): Société, uniquement en complément d'un contactId

• positioningId (string, optional): Positionnement à lier — requis 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.

Args:

• id (string, requis): ID de l'action à modifier

• typeOf (number, optional): Nouveau type (ID numérique du dictionnaire setting.action.*)

• title (string, optional): Nouveau titre

• text (string, optional): Nouveau contenu / notes (remplace l'existant, pas d'ajout)

• startDate, endDate (string, optional): Dates ISO avec timezone (ex: 2026-06-05T10:00:00+0200)

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.

• ⚠️ 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.

Crée la feuille de temps (CRA) d'un mois pour une ressource.

Quand : pour ouvrir le CRA d'un couple (ressource, mois) qui n'existe pas encore. Plutôt que : boond_timesheets_search d'abord : l'API ne déduplique pas, et deux CRA peuvent coexister sur le même mois.

• term est le mois au format YYYY-MM — un CRA couvre un mois entier, pas une journée.

• Écriture non idempotente.

Returns : confirmation et fiche du CRA créé.

Récupère les feuilles de temps (times reports) d'une ressource par son ID, avec filtre optionnel par mois/année.

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.

Args:

• resourceId (string): ID de la ressource

• month (number, optional): Mois (1-12), défaut: mois courant

• year (number, optional): Année (ex: 2025), défaut: année courante

Returns: Liste des feuilles de temps de la ressource avec jours/heures et statut.

Recherche des feuilles de temps (CRA mensuels) dans BoondManager.

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.

Args:

• startMonth (string, requis): Mois de début YYYY-MM (ex: '2025-01')

• endMonth (string, requis): Mois de fin YYYY-MM (ex: '2025-03')

• keywords (string, optional): Mots-clés

• page (number): Numéro de page (défaut: 1)

• pageSize (number): Résultats par page (défaut: 30)

Returns: Liste des feuilles de temps correspondantes.

Récupère les informations détaillées d'une feuille de temps 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.

Args:

• id (string): Identifiant unique de la feuille de temps

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

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

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

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.

• ⚠️ 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 ou période.

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.

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.

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.

• ⚠️ 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 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.

Args:

• keywords (string, optional): Termes de recherche

• companyId, projectId (string, optional): Filtrer par entité liée

• page, pageSize: Pagination

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.

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.

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.

• ⚠️ 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.

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.

Recherche des livraisons (comptes rendus d'activite) dans BoondManager avec filtres par projet, societe et periode.

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.

Args:

• keywords (string, optional): Termes de recherche

• projectId, companyId (string, optional): Filtrer par entite liee

• startDate, endDate (string, optional): Periode (YYYY-MM-DD)

• page, pageSize: Pagination

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.

Récupère la fiche complète d'un(e) livraison (CRA) par son ID numérique.

Quand : après un boond_deliveries_search, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : boond_deliveries_search si l'ID n'est pas connu (cet outil n'accepte pas de nom).

• Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de boond_deliveries_search, jamais d'une supposition.

Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Recherche des demandes d'absence dans BoondManager.

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.

Args:

• keywords (string, optional): Termes de recherche. resourceId est converti en COMP.

• startMonth, endMonth (string, optional): Periode au format YYYY-MM.

• page, pageSize: Pagination

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.

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.

• state est soumis au workflow de validation BoondManager : la demande part dans son état initial, elle n'est pas validée par cet appel.

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

• ⚠️ 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.

Args:

• keywords (string, optional): Termes de recherche

• resourceId, projectId (string, optional): Filtrer par entité liée

• startDate, endDate (string, optional): Période (YYYY-MM-DD)

• page, pageSize: Pagination

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.

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.

Args:

• resourceId (string): ID de la ressource

• term (string): Mois ciblé (YYYY-MM)

• agencyId (string, optional): Forcer l'agence

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.

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.

• ⚠️ 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.

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.

• ⚠️ 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 ci-dessous sont convertis automatiquement en ces références.

Args:

• keywords (string, optional): Termes de recherche (références d'entités acceptées)

• candidateId, resourceId, opportunityId, companyId, contactId, productId (string, optional): Filtrer par entité liée (convertis en références keywords)

• page, pageSize: Pagination

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.

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.

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.

Args:

• id (string): ID du positionnement

• state (number, optional): État du positionnement (ID du dictionnaire setting.state.positioning)

• stateReasonTypeOf, stateReasonDetail (optional): Motif d'état (repliés en stateReason {typeOf, detail})

• startDate, endDate (string, optional): Dates au format YYYY-MM-DD (chaîne vide pour effacer)

• informationComments (string, optional): Commentaires (max 250 caractères)

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.

• ⚠️ 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éé.

Recherche des paiements / reglements dans BoondManager.

Quand : pour suivre les règlements enregistrés. Plutôt que : boond_provider_invoices_search pour les factures fournisseur et boond_purchases_search pour les engagements : un paiement est adossé à un achat, il ne le remplace pas.

Args:

• keywords (string, optional): Termes de recherche. Utiliser ACH, CSOC, PRJ selon la doc Boond pour filtrer par achat, societe ou projet.

• invoiceId, companyId (string, optional): Conserves pour compatibilite, transmis comme query params si fournis.

• startDate, endDate (string, optional): Periode (YYYY-MM-DD)

• page, pageSize: Pagination

Returns: Liste des paiements 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.

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.

Recherche des avantages (tickets restaurant, mutuelle, véhicule, primes...) dans BoondManager, avec filtre optionnel par ressource.

Plutôt que : boond_resources_advantages quand on part d'une ressource précise.

Args:

• keywords (string, optional): Termes de recherche

• resourceId (string, optional): Filtrer par ID ressource

• page, pageSize: Pagination

Returns: Liste des avantages 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.

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

Args:

• dictionaryType (string): Chemin dans la réponse (relatif à data). Exemples :

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

Récupère la fiche complète d'un(e) contrat par son ID numérique.

Quand : après un boond_contracts_search, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : boond_contracts_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_contracts_search, jamais d'une supposition.

Returns : JSON de l'entité (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_contracts_search 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.

• Le type de contrat est un ID entier du dictionnaire (boond://dictionary/typeOf/contracts), pas un libellé.

Returns : confirmation et fiche du contrat créé, avec son ID dans structuredContent.id.

Recherche des achats et sous-traitances dans BoondManager.

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.

Args:

• keywords, companyId, projectId: Filtres

• page, pageSize: Pagination

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.

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

Supprime définitivement un(e) achat 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 désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle.

• ⚠️ 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.

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.

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.

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

Args:

• category (string, requis): 'activity' | 'thread' | 'corporate'

• state (string, optional): 'new' | 'read'

• parentType (string[], optional): types de modules parents (ex: 'contract', 'global')

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.

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.

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.

Args:

• startMonth (string, requis): YYYY-MM (ex: '2025-01')

• endMonth (string, requis): YYYY-MM

• documentTypes (string[], optional): 'absencesReport' | 'timesReport' | 'expensesReport'

• validationStates (string[], optional): 'waitingForValidation' | 'validated' | 'rejected'

• resourceTypes (number[], optional)

• keywords (string, optional): préfixes 'TPS', 'EXP', 'ABS', 'COMP'

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.

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.

Télécharge le contenu d'un document BoondManager (CV de candidat/ressource, justificatif, contrat, facture...) par son ID.

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.

Le contenu est retourné en ressource MCP embarquée (base64 pour les binaires type PDF/DOCX, texte brut pour les fichiers texte). Taille max: 5 Mo — à n'utiliser que lorsque le contenu du fichier est réellement nécessaire (un CV en base64 occupe beaucoup de contexte).

Returns : le fichier en ressource MCP embarquée — blob base64 pour un binaire, text pour un mime texte. 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.