delete_document
Soft-delete a document. It will be hard-deleted after 30 days. Restoration is via the web UI within that window.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes |
Soft-delete a document. It will be hard-deleted after 30 days. Restoration is via the web UI within that window.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the soft-delete nature, the 30-day hard-delete policy, and the restoration path (web UI only). This is valuable behavioral context beyond what the schema shows. It doesn't mention permissions or side effects, but covers the core behavior well.
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?
Three short sentences, front-loaded with the key action. Every sentence earns its place—no filler or repetition. Structure is clear and scannable.
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?
For a simple tool with one parameter and no output schema, the description covers the essential behavioral aspects: soft delete, retention period, and restoration route. It doesn't specify the return value or error handling, but those are less critical given the simplicity. Missing return info is minor.
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 description coverage is 0%, so the description must compensate. It provides zero additional clarification about documentId beyond the name. The agent is left to infer it's a document identifier, which is trivial but still undocumented in the schema itself. A brief note that it's the ID from list_documents or get_document would add value.
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?
The description clearly states the verb 'Soft-delete' and the resource 'document', distinguishing it from update/get operations. It also adds a critical nuance (soft vs hard delete) that differentiates it from a simple 'delete'.
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?
While it doesn't explicitly name alternatives or when-not-to-use, the soft-delete semantics imply this is the non-destructive choice. The mention of restoration via web UI within 30 days gives practical context about the intended use case. It could be more explicit about picking this over a hypothetical permanent delete tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.