BoondManager MCP Server vs WalkerOS Flow

BoondManager MCP Server tools 238

• boond_candidates_searchRecherche des candidats dans BoondManager avec filtres serveur. Plutôt que : `boond_resources_search` pour les collaborateurs internes — candidats et ressources sont deux référentiels distincts, et une personne recrutée cesse d'être trouvable ici. Cas d'usage courants : • **Mes candidats** sans connaître son propre ID : `perimeterDynamic: ["data"]`. Pour "candidats de l'équipe X" : `perimeterManagers: [<X_id>]` (utiliser `perimeterManagersType: "main"|"hr"` pour cibler Main vs HR Manager). • **États / types** : `candidateStates: [<id>]` (dictionnaire `setting.state.candidate`), `candidateTypes` (`setting.typeOf.resource`), `contractTypes`, `availabilityTypes`. IDs entiers issus du dictionnaire. • **Profil technique** : `tools: [<id>]` (OU; pour ET: `["#AND#", "1", "2"]`), `expertiseAreas`, `activityAreas`, `experiences`, `trainings`, `mobilityAreas`, `languages` (format `langueId|niveauId`). • **Sourcing** : `sources: [<id>]` (origine du candidat), `evaluations`. • **Période** : `period: "created"|"updated"|"available"|"withActions"|...` + `startDate`/`endDate`. • **Recherche par nom** : `keywords: "Dupont"` + `keywordsType: "lastName"` (ou firstName, fullName avec `"NOM#PRENOM"`, emails, phones, title, titleSkills…). Sans `keywordsType`, recherche par défaut dans le CV. • **Géolocalisation** : `coordinates: "lat,lon"` ou `location` + `geoDistance` (km, 5-200). Tri : `sort` + `order`. Returns : liste paginée des candidats. Utiliser `boond_candidates_get` ou les outils d'onglets pour le détail. - `fields` : projection côté MCP, jamais transmise à l'API — remplace le résumé par les seuls attributs/relations listés (noms inconnus ignorés). À utiliser sur les grosses pages. - Pagination : `pageSize` 1–500 (défaut 30), `page` 1–100 — au-delà : refus, affiner les filtres.
• boond_candidates_getRécupère la fiche complète d'un(e) candidat par son ID numérique. Quand : après un `boond_candidates_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste. Plutôt que : `boond_candidates_search` si l'ID n'est pas connu (cet outil n'accepte pas de nom), ou `boond_find` pour résoudre un nom / un e-mail en ID. - `tab` cible un onglet précis (`information`, `technical-data`, `administrative`, `actions`…) ; sans `tab`, seule la fiche de base est renvoyée, pas la réunion des onglets. - Un ID inconnu remonte l'erreur BoondManager telle quelle — l'ID doit venir de `boond_candidates_search`, jamais d'une supposition. Returns : JSON de l'entité (attributs + relations) tel que renvoyé par l'API. Lecture seule.
• boond_candidates_createCré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.
• boond_candidates_updateMet à jour un(e) candidat existant(e), identifié(e) par son ID. Quand : pour modifier quelques champs d'un enregistrement déjà en base. Plutôt que : `boond_candidates_create` si l'enregistrement n'existe pas encore, ou `boond_find` pour résoudre un nom / un e-mail en ID. - Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place. - Attention aux champs de type tableau, qui sont **remplacés** et non fusionnés. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). Returns : confirmation et fiche mise à jour.
• boond_candidates_deleteSupprime définitivement un(e) candidat de BoondManager. Quand : uniquement sur demande explicite de l'utilisateur, et après avoir vérifié l'ID avec `boond_candidates_get`. Plutôt que : `boond_candidates_update` pour désactiver ou changer l'état d'un enregistrement sans le détruire — c'est presque toujours l'intention réelle. - `boond_rights_get` dit si l'utilisateur a ce droit sur l'enregistrement avant d'essayer (un 403 évité). - ⚠️ Irréversible, sans corbeille côté API. - Si le client MCP annonce la capacité `elicitation`, une confirmation est demandée à l'utilisateur final et un refus annule l'appel (`structuredContent.deleted: false` + `reason`) ; sinon la suppression part directement. Returns : `{ id, deleted, reason? }` — vérifier `deleted`, qui vaut `false` en cas de refus utilisateur.
• boond_candidates_technical_data_updateMet à jour le dossier technique (DT) d'un candidat : compétences, outils, langues, profils (activityAreas), secteurs (expertiseAreas), formation, diplômes, expérience, résumé. Quand : pour coder le dossier technique d'un candidat (profils, secteurs, outils, langues, expérience, formation). Plutôt que : `boond_candidates_update` pour l'onglet Information (coordonnées, disponibilité, mobilité, évaluation) ; `boond_resources_technical_data_update` pour un collaborateur interne. Mode 'merge' (défaut, recommandé pour automation) — enrichit sans rien écraser : • skills (CSV) : concatène les compétences absentes • tools / languages : ajoute les entrées dont la clé (slug outil / langue) est nouvelle, conserve le niveau existant pour les autres • expertiseAreas, activityAreas, diplomas : ajoute les items absents • title, summary, training, experience : remplis UNIQUEMENT si actuellement vides Mode 'replace' — remplace intégralement chaque champ fourni. Les champs non passés ne sont pas touchés. ⚠️ experience, training, expertiseAreas, activityAreas et tools prennent des IDs de dictionnaire (`setting.experience`, `setting.training`, `setting.expertiseArea`, `setting.activityArea`, `setting.tool`), jamais des libellés. Returns : confirmation, liste des champs envoyés mais non retrouvés dans la réponse de l'API (écriture ignorée par Boond), puis le DT mis à jour.
• boond_candidates_administrative_updateMet à jour l'onglet Administratif d'un candidat : nationalité, salaire souhaité (fourchette), salaire actuel, contrat souhaité, commentaires. Quand : pour renseigner nationalité, salaire souhaité ou contrat souhaité d'un candidat. Plutôt que : `boond_candidates_technical_data_update` pour les compétences et le parcours. Seuls les champs fournis sont envoyés. Données personnelles : n'écrire que ce que le candidat a communiqué (CV, entretien). Returns : confirmation, liste des champs non retrouvés dans la réponse de l'API, puis le bloc administratif mis à jour.
• boond_candidates_informationRé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.
• boond_candidates_technical_dataRé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.
• boond_candidates_administrativeRé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.
• boond_candidates_actionsRé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.
• boond_candidates_positioningsRé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.
• +226 more on the listing page

WalkerOS Flow tools

No tool names declared yet. Check the project README from the listing page.