Skip to main content
Glama

delete_note

Destructive

Deletes a Notes app note by ID, moving it to Recently Deleted for recovery; previews by default with dry_run and verifies the title when provided.

Instructions

Delete a note by id → Recently Deleted (recoverable ~30 days). Destructive. Pass expect_title to verify the target before deleting (content-verify first). dry_run DEFAULTS TO TRUE — previews the note that WOULD be deleted (pointer, no mutation); pass dry_run=false to delete. Needs Automation access for Notes. id from notes / notes_all.

Input Schema

NameRequiredDescriptionDefault
idYes
dry_runNo
expect_titleNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark it destructive, but the description adds critical details beyond them: the delete is recoverable for about 30 days, dry_run defaults to true and performs no mutation, expect_title verifies the target, and Automation access is required. This is strong behavioral disclosure with no contradiction.

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 dense but carefully front-loaded, starting with the action and effect, then safety checks, dry_run semantics, permissions, and id source. Every sentence adds operational value, and the formatting makes the default dry_run behavior easy to spot.

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?

Given the destructive delete operation, three parameters, existing annotations, and an output schema, the description is complete enough for correct invocation. It covers recovery behavior, preview defaults, target verification, auth requirements, and where ids come from.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: id is sourced from notes/notes_all, dry_run defaults to true with preview semantics, and expect_title verifies the target before deletion. All three parameters are explained with behavior beyond their types.

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?

States a specific verb and resource: "Delete a note by id" and clarifies the effect by noting it moves to Recently Deleted. This clearly separates it from create_note, update_note, and other delete_* siblings by resource.

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

Usage Guidelines4/5

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

Gives clear operational context: use the id from notes/notes_all, verify with expect_title before deleting, and preview with dry_run because it defaults to true. It does not explicitly name when to avoid this tool versus update_note or other alternatives, so it is not a full 5.

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