Skip to main content
Glama

erase_org_doc

PERMANENTLY destroy a document or a folder — its content, every past version, its comments and its name. NOTHING brings it back; this is not delete_org_doc, which is recoverable. Use it only for a genuine erasure request (someone asking that their data be removed), and prefer delete_org_doc for ordinary tidying. TWO CALLS, ALWAYS: the first returns exactly what would stop existing plus a confirm_token and destroys NOTHING — show that to the person you are working for, get their answer, then call again with the token. Never confirm on their behalf. Requires OWNER: what you own is erased and what you do not is left and reported, so a folder can come back partly done. The audit record of the erasure survives on purpose.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeNothe 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.
tokenNoBearer token identifying the principal. Usually omitted — supplied by the transport (HTTP Authorization header or the server's AGENTLEFS_TOKEN env). Only pass this to override.
locationNofull 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_tokenNoOMIT on your first call — you get back what would be destroyed, plus this token. SHOW THAT TO THE PERSON YOU ARE WORKING FOR and get their answer before calling again with it.

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?

With no annotations, the description fully carries the behavioral burden. It discloses permanent irreversibility, the two-call destroy-nothing-first protocol, partial behavior for folders when ownership is mixed, and the intentional survival of the audit record. It also warns against confirming on the user's behalf.

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?

Dense but every sentence earns its place; the most critical fact (permanent destruction) is front-loaded, and each subsequent sentence adds a distinct operational constraint. The emphasis through caps and the explicit two-call rule makes the high-risk behavior impossible to miss.

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 destructive two-step operation with no output schema, the description covers the first-call return (preview plus confirm_token), the second-call token requirement, ownership side effects, and audit retention. Nothing an agent needs to call this safely is missing.

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 100%, so the baseline is 3. The main description reinforces the two-call confirm_token workflow and node-versus-location distinction, but most parameter-level meaning already lives in the schema. It adds workflow context without substantially new parameter semantics.

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 precise verb ('destroy') and resource ('document or folder'), enumerates the full scope (content, versions, comments, name), and explicitly distinguishes itself from recoverable delete_org_doc. An agent can tell exactly what this tool does and how it differs from siblings.

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?

Explicitly says to use it only for genuine erasure requests, to prefer delete_org_doc for ordinary tidying, and never to confirm on behalf of the user. It also states the OWNER prerequisite. This is model guidance for when-to-use versus alternatives.

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