Skip to main content
Glama

delete_note

DestructiveIdempotent

Permanently removes a note by note ID after user confirmation, helping clear unwanted entries from a persistent local notebook.

Instructions

Permanently delete a note. Confirm with the user first.

Input Schema

NameRequiredDescriptionDefault
note_idYes

Output Schema

NameRequiredDescriptionDefault
deleted_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds value beyond them by stating the deletion is permanent and that user confirmation is required, which is exactly the behavioral context an agent needs before invoking a destructive tool.

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?

Two short sentences with zero waste: the operation is front-loaded and the confirmation requirement follows immediately. Nothing could be removed without losing meaning.

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

Completeness4/5

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

An output schema exists, so return values need not be explained, and annotations cover the destructive/idempotent profile. What is slightly missing is behavior on a nonexistent or already-deleted note_id, though idempotency is declared so the agent can infer safe retry semantics.

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?

Schema description coverage is 0%, so the single required parameter note_id is undocumented in both schema and description. However, the parameter is self-evident (an integer note identifier) and the description's scope word "note" aligns with it, so the gap is minor rather than harmful.

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

Purpose4/5

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

States a specific verb (delete), resource (note), and effect (permanently), so the agent knows exactly what the tool does and that it is irreversible. It does not explicitly name a sibling such as update_note to contrast with, but the destructive framing makes it distinguishable from the other note tools.

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

Usage Guidelines3/5

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

"Confirm with the user first" is a procedural constraint rather than a when-to-use rule, and there is no explicit guidance on when to choose delete_note over e.g. update_note. Usage is implied by the destructive nature of the operation rather than stated.

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