Delete a watch
delete_watchStop and delete a watch. Free.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| key | Yes | Your Ledgerbell API key (from create_api_key) |
delete_watchStop and delete a watch. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| key | Yes | Your Ledgerbell API key (from create_api_key) |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint=true annotation already flags this as a destructive operation, so the description's job is smaller. It adds two pieces of real context the annotation lacks: that the operation halts the watch first ('Stop and delete') and that it costs nothing ('Free'). It says nothing about irreversibility, auth requirements, or failure modes beyond what the annotation covers.
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?
Two short, front-loaded sentences with no filler; the mutation verb leads and the cost note trails. It is efficient, though the extreme brevity borders on under-specification rather than pure conciseness.
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?
For a destructive, irreversible-looking operation with two required parameters and no output schema, the description omits the most important detail: what deleting a watch destroys and whether it can be undone. The undocumented 'id' parameter is also unaddressed, so an agent lacks enough to invoke confidently.
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?
Schema coverage is only 50%: the 'key' parameter is documented in the schema, but 'id' — the watch identifier — has no description anywhere. The description does not compensate at all, adding no guidance on what form 'id' takes or where to find it. With sub-80% coverage the burden was on the description and it does not meet it.
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?
'Stop and delete a watch' gives a specific verb pair and resource, so the agent knows exactly what happens. It does not distinguish itself from siblings like add_watch or list_watches, but those are self-evidently complementary. Clear but undifferentiated.
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 statement of when to use this versus list_watches or test_watch, and no prerequisites or exclusions. 'Stop and delete' hints at the use case but leaves the agent to infer everything else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.