Skip to main content
Glama

Delete a document or folder

doc_delete
Destructive

Remove a document, a directory or a whole folder. Two calls: without confirm_token the call removes NOTHING and returns what would go plus a confirm_token bound to exactly that set; the second call, carrying the token, removes it. Needs manager on everything removed. Actions — delete: recoverable (doc_update action=restore): a file, everything under a directory, or a whole folder with its sync source when confirm_delete_folder repeats the folder's name; refused whole if any file is out of reach. Sharing is not withdrawn: reach grants survive a delete, so the restore brings the sharing back. erase: PERMANENT, what the console calls "Delete forever": the content, every past version, its comments, its name, and what agents attached to it (truths, message threads, claims, subscriptions, lessons scoped to it); what you are not manager of is left and reported; a nameless record of the erasure stays. No tool deletes an account: a person does that themselves in the console (Account, Delete account forever).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeNoerase: the document's id, as returned beside its location — survives a rename or a move, so a citation written into a stored document keeps pointing at the right thing. Give this OR location, never both. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
actionYeswhat to do; each action takes the arguments its line names
locationNodelete: full path from the workspace root, e.g. "handbook/vendor/acme.md" (as printed by browse action=documents or search) · erase: full path from the workspace root, e.g. "handbook/vendor/acme.md". Give this OR node. A path is what a person reads; a node is what survives somebody reorganizing.
confirm_tokenNodelete: OMIT on the first call, which returns what would be deleted plus this token. Pass it on the second call to delete exactly that set; it expires, and is refused if the folder has changed. · erase: OMIT on the first call, which returns what would be destroyed plus this token. Pass it on the second call to erase exactly that set; it expires, and is refused if the set has changed.
idempotency_keyNoAny unique string you choose for this write, e.g. a UUID. If you retry the call with the same key and the same arguments, the first answer is returned and nothing is done twice. Reusing a key for a different request is refused. Keys are kept 24 hours.
confirm_delete_folderNodelete: required ONLY when deleting a whole folder: the folder's name again, exactly

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNothe answer as prose, for an action that answers in prose
actionYesthe action that answered

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true, readOnlyHint=false, idempotentHint=false; the description goes far beyond that. It discloses the confirmation handshake, token expiry and refusal-on-change behavior, that 'delete' is recoverable while 'erase' is permanent and strips versions/comments/agent attachments, that sharing grants survive, that partial erasures are reported, and that a nameless record remains. This is exactly the extra behavioral context an agent needs.

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?

Content is front-loaded (the core two-call mechanic comes first) and every clause carries meaning, but the prose is dense and clausal-heavy, with the delete/erase distinction and parameter rules interleaved. Effective, though slightly verbose for a definition.

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?

With an output schema present, return values need no explanation, and the description still covers permissions (manager on everything removed), side effects (sharing retained, dependent agent artifacts erased), irreversibility, and the recovery alternative. Nothing an agent needs to invoke this correctly appears missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description clarifies cross-parameter behavior the schema states only per-field: the two-call confirm_token flow, the node-OR-location exclusivity for erase (id survives rename/move), and the exact-name requirement of confirm_delete_folder. It adds useful intent beyond the already-detailed schema.

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?

The description names a specific verb (remove/delete) and its resources (document, directory, folder), then splits the operation into two distinct actions (delete vs erase) with sharply different semantics. It explicitly distinguishes itself from siblings by noting the recovery path (doc_update action=restore) and that no tool deletes an account. An agent can route to it without opening the schema.

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?

It spells out when each action applies, the mandatory two-call protocol (omit confirm_token first, pass it second), when confirm_delete_folder is required, and the explicit alternative for recovery. It also states an exclusion (account deletion is done in the console by the person). Both when-to-use and when-not are present.

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