delete_doc

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

No annotations, so the description carries the full behavioral burden. It usefully defines what qualifies for deletion, but for a destructive tool it never states whether the deletion is permanent or reversible, what permissions are needed, or what happens to linked references.

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

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

Purpose and the key exclusion rule are front-loaded in two short sentences, followed by a compact args list. No filler, though the args list largely restates the schema's properties.

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

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

An output schema exists so return values need no explanation, and both parameters are covered. For a destructive operation with no annotations, the omission of reversibility/permission context is the only real gap.

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

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

Schema coverage is 0%, so the description must compensate, and it does: 'name' is documented as a document identifier, and 'category' is given as the location of the doc with the full enumerated set ('stacks', 'models', 'apis', 'platforms', 'custom') plus the 'custom' default. It only lacks guidance on name format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (delete) plus resource (technical fact sheet) with qualifying criteria (wrong, duplicate, or yanked). An agent can distinguish this from write_doc/get_doc 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit negative rule: 'Do not delete because a fact is old. Old-but-still-true model/API notes stay.' This is a real when-not constraint. It stops short of naming the alternative tool (e.g., write_doc to correct a stale-but-true note), so it is 4 rather than 5.

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