delete_fileSoft-delete a file from your Fulcra account while keeping earlier versions recoverable via restore_file.
Delete a file stored in the user's Fulcra account.
This is a soft delete: earlier versions of the file are kept and can be
restored with restore_file (find version IDs via list_files with
include_versions=true).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The full path of the file to delete. |
Changes observed during successful MCP inspections.
v1.18.7Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullv1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds the key mitigation: this is a SOFT delete, prior versions survive, and there is a documented restore path including how to find version IDs. That is exactly the kind of context annotations cannot convey and it materially changes how cautiously an agent treats this call.
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?
Two sentences, zero filler. The operational fact (soft delete) is front-loaded immediately after the one-line purpose, and the cross-references to restore_file and list_files are actionable rather than decorative.
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 single-parameter deletion tool with a destructive hint already declared, the description supplies the missing piece — reversibility and how to exercise it. No output schema is needed for a delete confirmation, and nothing an agent requires to call this safely is absent.
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 100% and the single 'path' parameter is already documented as 'The full path of the file to delete.' The description adds no further syntax guidance (root-relative vs absolute, leading slash, behavior on non-existent paths), so it neither compensates nor detracts — baseline 3.
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?
States a specific verb and resource ('Delete a file stored in the user's Fulcra account'), which cleanly separates it from siblings such as delete_records, delete_share, and archive_data_type. An agent knows exactly what is being removed and from where.
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?
The description establishes the recovery path — 'earlier versions of the file are kept and can be restored with restore_file' — and tells the agent how to obtain version IDs via list_files with include_versions=true. It doesn't state explicit exclusions (e.g., when to prefer delete_records), but the context is clear enough to pick correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.