boondmanager-mcp-server

Supprimer un achat/sous-traitance

boond_purchases_delete

Destructive

Delete a purchase or subcontract record from BoondManager permanently. Use only after verifying the ID and confirming no payments are linked to it.

Instructions

Supprime définitivement un achat / sous-traitance 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 corriger un montant, une période ou un état — vérifier avec boond_payments_search (purchaseId) qu'aucun règlement n'y est adossé avant de détruire.

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Identifiant unique de l'entité BoondManager (numérique)

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`reason`	No	Présent quand la suppression n'a pas eu lieu (ex: refus utilisateur)
`deleted`	Yes

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

Changed4 schema fields changedv2.7.0Jun 19, 2026

changedInput schema / properties / id / description

Previous value: -"Identifiant unique de l'entité BoondManager"New value: +"Identifiant unique de l'entité BoondManager (numérique)"

removedInput schema / properties / id / minLength
```
Removed value: -1
```
addedInput schema / properties / id / pattern
```
Added value: +"^\\d+$"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "deleted": {
+      "type": "boolean"
+    },
+    "id": {
+      "type": "string"
+    },
+    "reason": {
+      "description": "Présent quand la suppression n'a pas eu lieu (ex: refus utilisateur)",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "deleted"
+  ],
+  "type": "object"
+}

First observedv2.1.0May 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the destructiveHint=true annotation, the description discloses irreversibility (no trash on the API side), the confirmation flow when elicitation is available, the possibility of refusal returning deleted:false, and the need to check the deleted field. This adds substantial value beyond annotations.

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

Conciseness4/5

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

The description is well-organized with clear sections (Quand, Plutôt que, warning, Returns) and front-loaded purpose. It is slightly longer than the minimum but each section earns its place by covering safety, alternatives, and return-value checking without excessive verbosity.

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 destructive tool with an output schema and annotations, the description is remarkably complete. It covers when to call it, prerequisites, alternatives, irreversibility, user-confirmation behavior, return-value interpretation, and the payment-check guard. No critical information for correct invocation is missing.

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

Parameters3/5

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

The input schema already provides 100% coverage for the single 'id' parameter, including its numeric pattern and description. The description only adds advice to verify the ID via boond_purchases_get, which is more usage guidance than parameter semantics. Baseline 3 is appropriate since the schema fully documents the parameter.

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: 'Supprime définitivement un achat / sous-traitance de BoondManager'. It clearly identifies the object and the destructive nature, and it is easily distinguishable from siblings like boond_purchases_update or boond_purchases_get.

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 explicitly states when to use it (only on explicit user request after verifying the ID with boond_purchases_get), when not to use it (prefer boond_purchases_update for corrections), and requires a prerequisite check with boond_payments_search to ensure no payments are attached. This is exemplary routing guidance.

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

Deploy Server