delete_board
Removes a specified Umami board by its UUID, letting you clean up unused dashboards and keep analytics workspaces organized.
Instructions
Delete an Umami board
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes |
Removes a specified Umami board by its UUID, letting you clean up unused dashboards and keep analytics workspaces organized.
Delete an Umami board
| Name | Required | Description | Default |
|---|---|---|---|
| boardId | Yes |
Changes observed during successful MCP inspections.
v2.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it adds nothing beyond the verb. It does not state whether deletion is permanent or recoverable, whether the board must be empty, what permissions or ownership are required, or what happens to dashboards/links attached to the board.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four words with zero filler, which is structurally clean and front-loaded. But the brevity is under-specification rather than economical writing, so it does not earn a high score for sizing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an irreversible mutation tool with no annotations, no output schema, and an undocumented parameter. An agent lacks the warning context (permanence, side effects, prerequisites) required to call it responsibly, and the description supplies none of it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter with 0% schema description coverage, so the description needed to compensate and says nothing about boardId. The schema conveys only that it is a required UUID-formatted string; the description offers no hint about where to obtain it (e.g., list_boards or get_board).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Delete an Umami board' names a specific verb and resource, and 'Umami' adds a small amount of domain context. However, it is essentially a restatement of the name delete_board, and nothing distinguishes it from sibling delete operations (delete_report, delete_team, delete_link) beyond the noun itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus update_board or delete_website, no preconditions, and no exclusions. The agent must infer everything from the tool name and the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.