Skip to main content
Glama
Sign In
AIops-tools

container-host-aiops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

prune_volumes

Destructive

Remove unused Docker volumes to free disk space. Preview with dry_run; set all_unused to include named volumes, but removal cannot be undone.

Instructions

[WRITE][risk=high] Prune unreferenced volumes. No undo.

Docker removes only ANONYMOUS unused volumes by default (its behaviour since 23.0); named unused volumes survive unless all_unused is set. The dry_run preview is scoped by the same flag, so it describes the call you are about to make — and when scoped to the default it still reports the named unused volumes it will not touch (alsoUnusedNamed*) rather than hiding that space.

Args: all_unused: Also remove NAMED unused volumes (docker volume prune -a). Irreversible, and named volumes usually hold data someone meant to keep. dry_run: If True, list what would be removed + reclaimable bytes. target: Target name from config; omit for the default.

Input Schema

NameRequiredDescriptionDefault
targetNo
dry_runNo
all_unusedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.3
    • addedInput schema / properties / all_unused
      Added value: +{
+  "default": false,
+  "title": "All Unused",
+  "type": "boolean"
+}
  2. First observedv0.6.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: 'No undo', 'Irreversible', the Docker >=23.0 default behaviour, the warning that named volumes usually hold data someone meant to keep, and the detail that a default-scoped dry_run still reports named unused volumes via alsoUnusedNamed* rather than hiding them. The annotations (destructive=true, readOnly=false) are confirmed and substantially enriched.

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

Conciseness4/5

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

Front-loads the WRITE/risk/no-undo signal, then the behavioural nuance, then a clean Args block — every section earns its place and there is no filler. The middle paragraph is dense with parentheticals, but the information is load-bearing rather than decorative.

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

Completeness5/5

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

For a destructive, no-output-schema tool with 0% schema coverage, the description covers the risk profile, the flag-dependent scope of destruction, and what dry_run returns (removals plus reclaimable bytes). Nothing an agent needs to invoke this safely is missing.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the full burden, and it defines all three parameters: all_unused (remove NAMED unused volumes, irreversible), dry_run (list what would be removed plus reclaimable bytes), and target. target is only glossed as 'Target name from config; omit for the default', which is thinner than the other two, keeping this just short of a 5.

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

Purpose5/5

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

States a specific verb+resource (prune unreferenced volumes) with a scope qualifier and a risk flag up front. It clearly distinguishes itself from read-only siblings like list_volumes, inspect_volume, and dangling_volumes, which merely report the same space. An agent can tell what it does and what it does not touch 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.

Usage Guidelines4/5

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

Explains the crucial when-to-use nuance: Docker only prunes anonymous unused volumes by default, and named volumes survive unless all_unused is set, so the agent knows the flag changes the blast radius. It also explains how dry_run is scoped by the same flag. It stops short of naming sibling alternatives (e.g. dangling_volumes for inspection) as an explicit routing signal.

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

Deploy Server

Other Tools