livediagram

Delete a document or tab

delete_document

Destructive

Delete a document by moving it to the Trash, where it can be restored for 30 days (with restore_document, or from the Trash in the Explorer) before it is purged. With tabId, delete just one of its tabs, outright: tabs have no Trash. Confirm with the user first. A document must keep at least one tab.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "documentId": "<documentId>"
    },
    "name": "delete_document"
  }
}

Input Schema

Name	Required	Description	Default
`tabId`	No	Delete only this ONE tab instead of the whole document. A document must keep at least one tab, so deleting the last remaining tab is refused. A tab is deleted outright; it does not go to the Trash.
`documentId`	Yes	The document to delete (from find_documents / read_document).

Output Schema

Name	Required	Description
`tabId`	No	The deleted tab id (tab deletes).
`deleted`	Yes	Whether the document or one of its tabs was deleted.
`trashed`	No	True when the document went to the Trash.
`documentId`	Yes	The document id.
`restorableForDays`	No	Days the document can be restored with restore_document before it is purged.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond destructiveHint=true, the description discloses the crucial asymmetry: document deletion is reversible via Trash for 30 days, while tab deletion is permanent because tabs have no Trash. It also surfaces the validation rule (a document must keep at least one tab) and a confirmation requirement, which are exactly the facts 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 tight sentences: destination and reversibility first, the tabId exception second, safety instruction last. Every clause carries a distinct, actionable fact 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 destructive two-parameter tool, everything needed is present: outcome (Trash), reversibility window, restore path, the permanent-tab exception, the last-tab constraint, and a confirmation directive. An output schema exists, so return values require no explanation.

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%, and the description's tabId commentary (delete only this ONE tab, tabs have no Trash, last tab refused) largely restates what the schema already documents. It adds framing by contrasting the two deletion modes but no new parameter detail such as ID formats or lookup paths, so the baseline of 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?

The description states a specific verb plus resource (delete a document) and immediately distinguishes two distinct modes: whole-document deletion to Trash vs. single-tab deletion via tabId. The distinction from restore_document and the document/tab scope makes the tool's identity unambiguous.

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?

It gives clear operational context: use restore_document (or the Explorer Trash) to undo within 30 days, use tabId when only one tab should go, and confirm with the user first. It does not explicitly contrast against archive_document, which is the nearest sibling for a non-destructive alternative, so a small guidance gap remains.

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

All livediagram tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?