boondmanager-mcp-server

Créer un(e) produit

boond_products_create

Create a new product in BoondManager. Verify the product does not already exist to avoid duplicates, then get the new product ID and complete record in response.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Nom du produit
`note`	No	Description du produit
`state`	No	État du produit
`taxRate`	No	Taux de TVA (%)
`reference`	No	Référence du produit
`unitPrice`	No	Prix unitaire HT

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#"

Changed1 schema field changedv2.7.0Jun 19, 2026

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

Behavior4/5

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

Annotations already communicate readOnlyHint=false and idempotentHint=false, but the description adds real behavioral value by warning that two identical calls create two records because the API does not deduplicate. It also discloses that relationship/state IDs must be pre-resolved to numeric BoondManager IDs, which is useful operational context beyond the annotations.

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?

The description is compact, front-loaded with purpose, and uses clear structural markers ('Quand', 'Plutôt que', bullets, 'Returns'). Every sentence serves a distinct purpose: usage routing, non-idempotence warning, ID-resolution guidance, and return-value chaining. There is no filler.

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?

For a create tool with an output schema and 100% parameter schema coverage, the description covers all critical context: what it creates, when to call it, what to call instead, side effects, parameter ID semantics, and how to use the returned ID for chaining. Nothing essential for correct invocation is missing.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics by explaining that states/types are numeric BoondManager IDs to be resolved beforehand via entity searches or boond://dictionary/*. This clarifies how to correctly populate the state parameter beyond the schema's simple 'État du produit' label.

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?

The description opens with a specific verb and resource: 'Crée un(e) produit dans BoondManager.' It also explicitly contrasts itself with boond_products_update and boond_products_search, so an agent can immediately tell this tool creates a new product rather than modifying or finding one.

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?

The description clearly states when to use it ('pour ajouter un(e) produit inexistant(e)') and provides explicit exclusions: use boond_products_update for existing records and boond_products_search first to verify the product does not already exist. This is concrete routing guidance with no ambiguity.

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

Deploy Server