agentleFS

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

Name	Required	Description
`node`	No	erase: 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.
`seat`	No	the seat token identity_write action=take_seat gave you; pass it on every call while you drive that agent
`action`	Yes	what to do; each action takes the arguments its line names
`location`	No	delete: full path from the workspace root, e.g. "handbook/vendor/acme.md" (as printed by browse action=documents or search). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · 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.
`acting_as`	No	an agent identity below you (its id, from identity_write action=spawn) to make this one call as, with that agent's narrower access; for a helper whose session signs in as its person
`confirm_token`	No	delete: 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_key`	No	Any 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_folder`	No	delete: required ONLY when deleting a whole folder: the folder's name again, exactly

Output Schema

Name	Required	Description	Default
`text`	No	the answer as prose, for an action that answers in prose
`action`	Yes	the action that answered

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / seat

Added value: +{
+  "description": "the seat token identity_write action=take_seat gave you; pass it on every call while you drive that agent",
+  "maxLength": 64,
+  "type": "string"
+}

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / acting_as

Added value: +{
+  "description": "an agent identity below you (its id, from identity_write action=spawn) to make this one call as, with that agent's narrower access; for a helper whose session signs in as its person",
+  "type": "string"
+}

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / location / description

Previous value: -"delete: 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."New value: +"delete: full path from the workspace root, e.g. \"handbook/vendor/acme.md\" (as printed by browse action=documents or search). A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · 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."

AddedOct 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say destructive/not idempotent; the description goes far beyond by explaining that the first call destroys nothing, that delete is recoverable while erase wipes versions, comments, names and agent-attached artifacts, that sharing survives, that partial permission failures are reported rather than aborted, and that manager rights are needed on everything removed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, but the body is a single dense block of em-dash and semicolon chained clauses that is hard to parse at a glance. Almost every clause carries information, but the structure could be broken into shorter sentences or a delete/erase split for faster scanning.

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 an 8-parameter destructive tool with an output schema, it covers the confirmation lifecycle, permission prerequisites, recoverability, sharing persistence, partial-failure behavior, and the erase aftermath. An agent has everything needed to call it correctly without guessing.

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 the per-parameter descriptions already spell out node vs location, confirm_token semantics and confirm_delete_folder. The prose largely restates that structured content, adding only the behavioral consequence of an expired/changed token, so baseline 3 is appropriate.

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?

Opens with a specific verb and resource ('Remove a document, a directory or a whole folder') and immediately distinguishes the two modes of the tool (delete vs erase) so an agent can tell it apart from doc_update and doc_create. The scope is unambiguous and front-loaded.

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 states the two-call protocol (omit confirm_token, then pass it), the condition selecting it ('refused if the folder has changed'), when confirm_delete_folder is required, and routes recovery to doc_update action=restore and account deletion to the console. When-to-use and when-not-to-use are both stated rather than inferred.

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

All agentleFS tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?