boondmanager-mcp-server

Supprimer une action

boond_actions_delete

Destructive

Permanently delete an action from BoondManager after verifying the ID, with user confirmation to prevent accidental removal.

Instructions

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.

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.

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

Behavior5/5

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

Even though annotations already mark destructiveHint=true, the description adds critical context: the operation is irreversible with no API-side trash, a rights check can avoid a 403, and elicitation-capable clients will trigger user confirmation with structuredContent.deleted set to false on refusal. This goes well beyond the annotations without contradicting them.

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 well-structured with clear sections: core action, when to use, preferred alternative, safety notes, confirmation behavior, and return contract. Every sentence carries meaningful safety or routing information, and the irreversible warning is prominently placed.

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 mutation tool, the description covers all essential context: explicit user consent, ID verification, permission pre-check, irreversibility, conditional confirmation flow, and return-value semantics. There is no meaningful gap an agent would face when deciding whether and how to call this tool.

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 schema covers 100% of the single parameter with a description, so the baseline is 3. The tool description does not add new parameter syntax or meaning, though it sensibly advises verifying the ID before deletion via boond_actions_get, which is usage guidance rather than parameter semantics.

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 precise verb and resource: "Supprime définitivement un(e) action de BoondManager." It clearly states a permanent delete operation, which distinguishes it from related siblings like boond_actions_update and boond_actions_get without requiring the agent to infer anything.

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 says when to use it (only on explicit user request, after checking the ID with boond_actions_get) and when not to (prefer boond_actions_update for deactivating or changing state). It also points to boond_rights_get as a pre-flight permission check, giving the agent actionable routing and prerequisites.

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

Deploy Server