BoondManager MCP Server

Crée une demande d'absence (congés, RTT, maladie…) pour une ressource. Quand : pour poser une absence au nom d'une ressource identifiée par son ID. Plutôt que : `boond_absences_update` pour modifier une demande déjà déposée. - Le détail est porté par `absencesPeriods` ; si le tableau est omis, une période unique est déduite de `startDate`/`endDate`. - `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.

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.

Récupère la fiche complète d'un(e) demande d'absence par son ID numérique. Quand : après un `boond_absences_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_absences_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_absences_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Recherche des demandes d'absence dans BoondManager. 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<id>. - 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.

Met à jour une demande d'absence existante, identifiée par son ID. Quand : pour corriger les dates, le motif ou le commentaire d'une demande déjà déposée. Plutôt que : `boond_absences_create` si la demande n'existe pas encore. - Mise à jour partielle : seuls les champs fournis sont écrits. - `absencesPeriods` fait exception — le tableau fourni **remplace** l'intégralité des périodes existantes. Returns : confirmation et fiche mise à jour.

Récupère la fiche complète d'un(e) compte utilisateur par son ID numérique. Quand : après un `boond_accounts_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_accounts_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_accounts_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Liste et recherche les comptes utilisateurs de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) compte utilisateur à partir de son nom, ou pour énumérer les comptes utilisateurs existant(e)s. Plutôt que : `boond_accounts_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par compte utilisateur. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres.

Crée une nouvelle action (appel, email, RDV, note) dans BoondManager, rattachée à un contact, candidat, ressource, opportunité ou projet (relation dependsOn, obligatoire). Plutôt que : `boond_actions_update` pour compléter une action déjà enregistrée plutôt que d'en créer un doublon. 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.

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.

Récupère la fiche complète d'un(e) action par son ID numérique. Quand : après un `boond_actions_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_actions_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_actions_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Recherche des actions (appels, emails, RDV, notes) dans BoondManager 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.

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.

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.

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) agence par son ID numérique. Quand : après un `boond_agencies_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_agencies_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_agencies_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Liste et recherche les agences de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) agence à partir de son nom, ou pour énumérer les agences existant(e)s. Plutôt que : `boond_agencies_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par agence. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination sans effet : cette route renvoie toujours la table complète, `pageSize` et `page` sont ignorés par l'API — inutile de paginer, tout est déjà là.

Récupère les informations de l'utilisateur actuellement connecté à l'API BoondManager (profil, permissions, agence...). Quand : en début de session, pour connaître l'identité, l'agence et le périmètre du compte utilisé — donc ce que « mes données » désigne. Plutôt que : la ressource `boond://application/current-user`, identique et moins coûteuse ; et `boond_resources_search` pour quelqu'un d'autre que le titulaire du compte, cet outil ne prenant aucun paramètre. Returns: Données JSON de l'utilisateur courant.

Récupère un dictionnaire de référence BoondManager (états, types, pays, devises, langues, outils, expertises, ...). Quand : pour traduire un état ou un type BoondManager entre son ID entier et son libellé, avant de filtrer une recherche. Plutôt que : les ressources `boond://dictionary/*` pour les tables courantes (états, typeOf, pays, devises, langues) : même contenu par un `resources/read`, sans consommer un appel d'outil. Cet outil reste nécessaire pour les tables non publiées en ressource. L'API expose un seul endpoint `/application/dictionary` qui renvoie tout — le serveur le cache (TTL 1h, configurable via `BOOND_DICTIONARY_TTL_MS`) et extrait un sous-arbre par chemin dotté. 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 la fiche complète d'un(e) business unit par son ID numérique. Quand : après un `boond_business_units_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_business_units_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_business_units_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Liste et recherche les business units de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) business unit à partir de son nom, ou pour énumérer les business units existant(e)s. Plutôt que : `boond_business_units_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par business unit. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres.

Récupère la fiche complète d'un(e) calendrier par son ID numérique. Quand : après un `boond_calendars_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_calendars_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_calendars_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Liste et recherche les calendriers de BoondManager, par mots-clés et pagination. Quand : pour retrouver l'ID d'un(e) calendrier à partir de son nom, ou pour énumérer les calendriers existant(e)s. Plutôt que : `boond_calendars_get` si l'ID est déjà connu — la recherche ne renvoie qu'un résumé d'une ligne par calendrier. Returns : page de résumés (ID + libellé principal), plus `structuredContent.total` = nombre total côté BoondManager. Lecture seule. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination sans effet : cette route renvoie toujours la table complète, `pageSize` et `page` sont ignorés par l'API — inutile de paginer, tout est déjà là.

Récupère les actions (appels, emails, RDV, notes) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Liste des actions rattachées au candidat. Lecture seule.

Récupère les données administratives (pièces justificatives, documents contractuels, informations RH) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Bloc administratif du candidat, avec les ID de documents exploitables par `boond_documents_get`. Lecture seule.

Crée un(e) candidat dans BoondManager. Quand : pour ajouter un(e) candidat inexistant(e). Plutôt que : `boond_candidates_update` pour modifier un enregistrement existant, et `boond_candidates_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel.

Supprime définitivement un(e) candidat de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_candidates_get`. Plutôt que : `boond_candidates_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur.

Récupère la fiche complète d'un(e) candidat par son ID numérique. Quand : après un `boond_candidates_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_candidates_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_candidates_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Récupère les informations générales (coordonnées, adresse, état civil, photo, tags, source) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Bloc identité et coordonnées du candidat. Lecture seule.

Récupère les positionnements (placements du candidat sur des opportunités ou des projets) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Liste des positionnements du candidat. Lecture seule.

Recherche des candidats dans BoondManager avec filtres serveur. Plutôt que : `boond_resources_search` pour les collaborateurs internes — candidats et ressources sont deux référentiels distincts, et une personne recrutée cesse d'être trouvable ici. Cas d'usage courants : • **Mes candidats** sans connaître son propre ID : `perimeterDynamic: ["data"]`. Pour "candidats de l'équipe X" : `perimeterManagers: [<X_id>]` (utiliser `perimeterManagersType: "main"|"hr"` pour cibler Main vs HR Manager). • **États / types** : `candidateStates: [<id>]` (dictionnaire `setting.state.candidate`), `candidateTypes` (`setting.typeOf.resource`), `contractTypes`, `availabilityTypes`. IDs entiers issus du dictionnaire. • **Profil technique** : `tools: [<id>]` (OU; pour ET: `["#AND#", "1", "2"]`), `expertiseAreas`, `activityAreas`, `experiences`, `trainings`, `mobilityAreas`, `languages` (format `langueId|niveauId`). • **Sourcing** : `sources: [<id>]` (origine du candidat), `evaluations`. • **Période** : `period: "created"|"updated"|"available"|"withActions"|...` + `startDate`/`endDate`. • **Recherche par nom** : `keywords: "Dupont"` + `keywordsType: "lastName"` (ou firstName, fullName avec `"NOM#PRENOM"`, emails, phones, title, titleSkills…). Sans `keywordsType`, recherche par défaut dans le CV. • **Géolocalisation** : `coordinates: "lat,lon"` ou `location` + `geoDistance` (km, 5-200). Tri : `sort` + `order`. Returns : liste paginée des candidats. Utiliser `boond_candidates_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres.

Récupère le profil technique (compétences, expériences, formations, certifications, langues, CV) d'un(e) candidat, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu. Returns : Profil technique du candidat. Les ID de documents (CV) qui s'y trouvent alimentent `boond_documents_get`. Lecture seule.

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

Récupère les actions (appels, emails, RDV, notes) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des actions rattachées à la société. Lecture seule.

Récupère les contacts (interlocuteurs rattachés à la société) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des contacts de la société. Lecture seule.

Crée un(e) société dans BoondManager. Quand : pour ajouter un(e) société inexistant(e). Plutôt que : `boond_companies_update` pour modifier un enregistrement existant, et `boond_companies_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel.

Supprime définitivement un(e) société de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_companies_get`. Plutôt que : `boond_companies_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur.

Récupère la fiche complète d'un(e) société par son ID numérique. Quand : après un `boond_companies_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_companies_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_companies_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.

Récupère les informations générales (coordonnées, SIRET, site web, secteur, taille, tags) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Fiche signalétique de la société. Lecture seule.

Récupère les factures client d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des factures de vente adressées à la société. Ne pas confondre avec `boond_companies_provider_invoices` (achat). Lecture seule.

Récupère les opportunités commerciales d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des opportunités de la société. Lecture seule.

Récupère les bons de commande d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des bons de commande de la société. Lecture seule.

Récupère les projets d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des projets de la société. Lecture seule.

Récupère les factures fournisseur (factures reçues de la société en tant que prestataire) d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des factures d'achat. Ne pas confondre avec `boond_companies_invoices` (vente). Lecture seule.

Récupère les achats et la sous-traitance d'un(e) société, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_companies_get` pour la fiche de base, ou `boond_companies_search` si l'ID est inconnu. Returns : Liste des achats engagés auprès de la société. Lecture seule.

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.

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.

Récupère les actions (appels, emails, RDV, notes) d'un(e) contact, par son ID. Quand : pour ne charger que cette section, sans le reste de la fiche. Plutôt que : `boond_contacts_get` pour la fiche de base, ou `boond_contacts_search` si l'ID est inconnu. Returns : Liste des actions rattachées au contact. Lecture seule.

Crée un(e) contact dans BoondManager. Quand : pour ajouter un(e) contact inexistant(e). Plutôt que : `boond_contacts_update` pour modifier un enregistrement existant, et `boond_contacts_search` d'abord pour vérifier qu'il n'existe pas déjà. - Écriture réelle et non idempotente : deux appels identiques créent deux enregistrements (l'API ne déduplique pas). - Les ID de relations et les états/types sont des ID numériques BoondManager, à résoudre au préalable (recherches d'entités, `boond://dictionary/*`). Returns : confirmation, ID créé, et la fiche complète. `structuredContent.id` est réutilisable directement pour chaîner un appel.

Supprime définitivement un(e) contact de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_contacts_get`. Plutôt que : `boond_contacts_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur.

Récupère la fiche complète d'un(e) contact par son ID numérique. Quand : après un `boond_contacts_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_contacts_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom). - `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.