boondmanager-mcp-server

Modifier un(e) opportunité

boond_opportunities_update

Idempotent

Update an existing opportunity by ID, modifying only the fields you provide while preserving others. Replace array fields as needed.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	ID de l'opportunité à modifier
`name`	No	Nom / titre
`note`	No	Description de l'opportunité (mappée sur /data/attributes/description)
`state`	No	État de l'opportunité
`poleId`	No	ID du pôle (relation pole)
`typeOf`	No	Type d'opportunité : ID numérique du dictionnaire setting.typeOf.project (ex: 1, 3), via boond_application_dictionary
`endDate`	No	Date de fin prévue (YYYY-MM-DD)
`agencyId`	No	ID de l'agence (relation agency)
`criteria`	No	Critères / compétences recherchées (texte libre). Alimente le matching de boond_workflow_candidats_pour_opportunite.
`companyId`	No	ID de la société cliente (relation company)
`contactId`	No	ID du contact associé (relation contact)
`startDate`	No	Date de début prévue (YYYY-MM-DD ou 'immediate')
`hrManagerId`	No	ID de la ressource responsable RH (relation hrManager)
`expertiseArea`	No	Domaine d'expertise : ID du dictionnaire setting.expertiseArea (via boond_application_dictionary)
`mainManagerId`	No	ID de la ressource responsable principal / commercial (relation mainManager)
`turnoverEstimatedExcludingTax`	No	Chiffre d'affaires estimé HT (montant)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No	Identifiant de l'entité créée/modifiée
`type`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.12.2Aug 14, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed16 schema fields changedv2.7.0Jun 19, 2026

addedInput schema / properties / agencyId

Added value: +{
+  "description": "ID de l'agence (relation agency)",
+  "type": "string"
+}

addedInput schema / properties / companyId

Added value: +{
+  "description": "ID de la société cliente (relation company)",
+  "type": "string"
+}

addedInput schema / properties / contactId

Added value: +{
+  "description": "ID du contact associé (relation contact)",
+  "type": "string"
+}

addedInput schema / properties / criteria

Added value: +{
+  "description": "Critères / compétences recherchées (texte libre). Alimente le matching de boond_workflow_candidats_pour_opportunite.",
+  "maxLength": 5000,
+  "type": "string"
+}

changedInput schema / properties / endDate / description

Previous value: -"Date de fin (YYYY-MM-DD)"New value: +"Date de fin prévue (YYYY-MM-DD)"

addedInput schema / properties / expertiseArea

Added value: +{
+  "description": "Domaine d'expertise : ID du dictionnaire setting.expertiseArea (via boond_application_dictionary)",
+  "type": "string"
+}

addedInput schema / properties / hrManagerId

Added value: +{
+  "description": "ID de la ressource responsable RH (relation hrManager)",
+  "type": "string"
+}

addedInput schema / properties / mainManagerId

Added value: +{
+  "description": "ID de la ressource responsable principal / commercial (relation mainManager)",
+  "type": "string"
+}

changedInput schema / properties / note / description

Previous value: -"Notes"New value: +"Description de l'opportunité (mappée sur /data/attributes/description)"

addedInput schema / properties / note / maxLength
```
Added value: +65000
```

addedInput schema / properties / poleId

Added value: +{
+  "description": "ID du pôle (relation pole)",
+  "type": "string"
+}

changedInput schema / properties / startDate / description

Previous value: -"Date de début (YYYY-MM-DD)"New value: +"Date de début prévue (YYYY-MM-DD ou 'immediate')"

changedInput schema / properties / state / description

Previous value: -"État"New value: +"État de l'opportunité"

addedInput schema / properties / turnoverEstimatedExcludingTax

Added value: +{
+  "description": "Chiffre d'affaires estimé HT (montant)",
+  "type": "number"
+}

addedInput schema / properties / typeOf

Added value: +{
+  "description": "Type d'opportunité : ID numérique du dictionnaire setting.typeOf.project (ex: 1, 3), via boond_application_dictionary",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "id": {
+      "description": "Identifiant de l'entité créée/modifiée",
+      "type": "string"
+    },
+    "type": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedv2.1.0May 30, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

La description va au-delà des annotations en décrivant la sémantique de mise à jour partielle ('Mise à jour partielle : seuls les champs fournis sont écrits, les autres sont laissés en place') et le comportement particulier des champs de type tableau ('remplacés et non fusionnés'). Elle signale aussi la réponse ('confirmation et fiche mise à jour'). Les annotations restent cohérentes, pas de contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

La description est structurée en sections : 'Quand', 'Plutôt que', 'Mise à jour partielle', 'Attention', 'Returns'. Chaque fragment apporte une information utile, le contenu est dense et lisible. Il n'y a pas de remplissage inutile, et le point clé de la mise à jour partielle est mis en avant tôt.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Pour un outil avec 16 paramètres, annotations et output schema, la description est suffisante : elle couvre le cas d'usage, l'alternative, le comportement précis (partiel, remplacement des tableaux), et le retour attendu. Les dimensions de validation (format, relations) sont déjà détaillées dans les descriptions du schéma. Le contexte apporté par la description est `perdu` aucun vide flagrant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Les 16 paramètres sont tous documentés dans le schéma (couverture 100 %), ce qui abaisse le besoin de description. La description ajoute une sous-couche importante : le principe de mise à jour partielle explique comment se comportent les paramètres non fournis (ils ne sont pas réinitialisés), et l'avertissement sur les tableaux complète les informations du schéma. Elle apporte donc une réelle plus-value sémantique pour tous les paramètres.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

La description commence par une action claire et spécifique : 'Met à jour un(e) opportunité existant(e), identifié(e) par son ID'. Elle nomme explicitement la ressource (opportunité) et le comportement (update, pas création). Elle différencie l'outil du sibling `boond_opportunities_create`, ce qui lève toute ambiguïté.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

La section 'Quand :' indique précisément dans quel contexte utiliser l'outil : 'pour modifier quelques champs d'un enregistrement déjà en base'. La section 'Plutôt que :' indique l'alternative appropriée : `boond_opportunities_create` si l'enregistrement n'existe pas encore. C'est un exemple parfait de guidage explicite.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server