Skip to main content
Glama

Curated

Delete a list

delete_list
Destructive

Delete one of the person's lists for good. It disappears for them and for readers and cannot be brought back. Refused for Inbox. Only after the person asks to delete that exact list by name; offer archive_list when they may want it back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
listYesWhich list: slug, exact title, or id. Must match exactly one list or the call fails.
confirmTitleYesThe list's exact title, after the person confirms deleting it. A different title deletes nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, and the description goes beyond that by disclosing irreversibility ('cannot be brought back'), the blast radius (readers lose it too), a protected resource (Inbox), and the confirmation gate. That is exactly the extra context an agent needs before calling 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?

Three short sentences, front-loaded with the destructive outcome, then the exception, then the gating rule. Every sentence carries a distinct operational constraint with no filler.

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?

For a two-parameter destructive tool with full schema coverage and complete annotations, the description covers effect, irreversibility, exclusions, and preconditions; no output schema exists and none is needed to call it correctly.

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 coverage is 100% and both parameters are documented in the schema, including the exact-title match requirement for confirmTitle. The description reinforces the two-step confirmation workflow but adds no new syntax, format, or matching detail beyond what the schema states, so the baseline 3 applies.

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?

Names a specific verb (delete) and resource (one of the person's lists) and immediately scopes permanence and audience ('for good', 'for them and for readers'). It explicitly distinguishes itself from the sibling archive_list, which is the tool most likely to be confused with it.

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

Usage Guidelines5/5

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

Gives a hard precondition ('Only after the person asks to delete that exact list by name'), a named alternative with its selecting condition ('offer archive_list when they may want it back'), and an exclusion ('Refused for Inbox'). Nothing about when-to-use is left to inference.

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.

Resources