Skip to main content
Glama

delete_document

DestructiveIdempotent

Remove a document from your study errorbook after reviewing its deletion impact and confirming. Keeps a minimal receipt; does not delete originals, backups, or external copies.

Instructions

执行本地级联删除。仅在用户明确要求删除且已看完整preview_document_deletion影响范围后调用,含整份混合导出;acknowledge_delete由Agent转述,不是独立认证。必须传当前摘要;有其他会话/远端执行时拒绝。中断会关闭服务,重连继续已授权恢复。保留最小回执;不删除输入原件、外部拷贝、备份或服务商数据,不保证SSD物理擦除。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_idYes
inventory_digestYes
acknowledge_deleteYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond them: what the cascade actually includes (the full mixed export), what survives (input originals, external copies, backups, provider data), the absence of SSD physical-erasure guarantees, interruption/reconnection behavior, and that only a minimal receipt is retained. This is exactly the extra material an agent needs for 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.

Conciseness4/5

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

A single dense paragraph, front-loaded with the action and the preconditions before the caveats. Nearly every clause carries non-redundant information, though the run-on packing of interruption behavior and non-deletion guarantees into one sentence slightly hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a local cascade delete with an output schema present, the description covers scope, preconditions, refusal conditions, and survivor-set caveats thoroughly, so return values need not be explained. The remaining gap is the undocumented meaning/derivation of document_id and inventory_digest, which the agent must infer.

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 0% across all three required params. The description compensates partially by stating inventory_digest must be current and by clarifying that acknowledge_delete is an agent-relayed flag rather than standalone authentication, but document_id is never explained and the digest's format/source is left implicit. Partial compensation, not full.

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 opens with a specific verb+resource ('执行本地级联删除') and immediately scopes it against the sibling preview_document_deletion by requiring that tool's output to have been reviewed first. An agent can distinguish this destructive cascade from preview_document_deletion and redact_document without opening any 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 states explicit preconditions (user must have requested deletion AND seen the full preview_document_deletion impact), explains that acknowledge_delete is agent-relayed rather than an independent authorization gate, and gives explicit refuse conditions when other sessions or remote executions exist. When-to-use and when-not-to-use are both covered.

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