system_prune
Remove all unused Docker data to free up server storage and resolve disk space issues.
Instructions
Docker system prune (remove all unused data)
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Remove all unused Docker data to free up server storage and resolve disk space issues.
Docker system prune (remove all unused data)
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries responsibility for behavioral disclosure. It does clearly state the destructive nature ('remove all unused data'), which is important context. But it omits specifics such as which Docker objects are affected, whether the operation is irreversible, and whether it could cause unintended data loss.
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 concise phrase with no redundant filler. It does, however, largely restate the tool name with only the vague parenthetical adding substance, so it is efficient but somewhat under-developed.
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 destructive, zero-argument tool with no annotations and no output schema, this description is too thin. An agent is not told what 'unused data' includes, what the blast radius is, whether the operation is reversible, or how it compares to the sibling cleanup_docker.
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?
The tool has zero parameters, so there is nothing for the description to document. Baseline of 4 applies because parameter semantics are not applicable.
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 uses a specific verb ('prune') and resource ('Docker system'), and the parenthetical 'remove all unused data' clarifies the action. However, it does not explicitly distinguish this from the sibling cleanup_docker, so it is clear but not fully differentiated.
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?
No guidance is given about when to use this tool instead of alternatives such as cleanup_docker. The description implies a Docker cleanup use case but provides no explicit context, exclusions, or preferred conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dray-supadev/easypanel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server