reduce_recycle_bin
Restore a file from the recycle bin on a 1Panel server. Provide the file name to recover deleted items.
Instructions
Restore file from recycle bin
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Restore a file from the recycle bin on a 1Panel server. Provide the file name to recover deleted items.
Restore file from recycle bin
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it says almost nothing: it does not state where the file is restored to, whether an existing file at that path is overwritten, what permissions are needed, or whether the recycle bin is enabled. For a restore/mutation operation this is a significant gap.
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?
The description is a single short phrase with no wasted words, but it is under-specified rather than genuinely concise; there is no front-loaded guidance beyond the bare action.
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 restore operation with no annotations, no output schema, and a completely undocumented required parameter, the description should explain the target path, overwrite behavior, and error conditions. None of that is present.
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% and the single required parameter 'name' is never explained. The description does not clarify whether 'name' is the original filename, the recycle-bin entry name, or a full path, so it fails to compensate for the undocumented schema.
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 states a specific verb and resource ('Restore file from recycle bin'), so an agent can tell what the tool does. However, it draws no line between this tool and the closely related siblings list_recycle_bin, get_recycle_bin_status, and clear_recycle_bin, and the name 'reduce_recycle_bin' does not obviously match the 'restore' behavior described.
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?
There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools an agent should consider first (e.g., list_recycle_bin to find the file, get_recycle_bin_status to check the feature). The agent must infer the workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.