Skip to main content
Glama

Propose dashboard deletion

report_propose_dashboard_deletion
Read-onlyIdempotent

Read the revision needed to delete a dashboard after approval. Deletes nothing.

Input Schema

NameRequiredDescriptionDefault
dashboardIdYesDashboard ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2.8/5.0
Behavior3/5

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

The description usefully reinforces the annotations by stating "Deletes nothing", confirming the readOnly/non-destructive profile rather than contradicting it. However, it omits the substantive behavior an agent needs: what the returned revision contains, whether it expires, and how it is subsequently consumed by the deletion tool.

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?

Two short sentences with no filler, and the non-destructive guarantee is placed prominently. The first sentence is slightly cryptic in its phrasing ('Read the revision needed to delete'), but nothing is wasted.

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

Completeness2/5

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

For a tool whose whole purpose is to mediate an approval workflow, the description leaves the workflow unexplained: no output schema exists, yet the return value ('revision') and its role in the deletion flow are never described. An agent would know not to delete via this tool but would not know how to complete the task.

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?

There is a single parameter with 100% schema description coverage, so the schema already carries its meaning. The description adds nothing about dashboardId beyond what the schema provides, which is the expected baseline for a fully documented single-parameter tool.

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

Purpose3/5

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

The description gives a verb ("Read") and object ("the revision needed to delete a dashboard"), which roughly matches the 'propose deletion' title, but it never explains what a 'revision' is or how the proposal relates to the sibling report_delete_dashboard. An agent can tell this is not the actual deletion, but not precisely what it produces.

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

Usage Guidelines2/5

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

The phrase "after approval" hints that this is a post-approval step, but there is no explicit guidance on when to call this versus report_delete_dashboard, who approves, or what to do afterwards. The alternative tool is never named despite being an obvious sibling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.