Skip to main content
Glama

prune_images

Destructive

Remove dangling or unused container images to reclaim disk space. Use dry-run to preview images and reclaimable bytes before deletion.

Instructions

[WRITE][risk=high] Prune images (dangling by default). No undo.

dry_run LISTS the images that would be removed and the reclaimable bytes before doing anything.

Args: dangling_only: True (default) prunes only untagged images; False also prunes images unused by any container. 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
dangling_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the baseline is low. The description adds genuine context beyond them: the '[risk=high]' marker, the explicit 'No undo' reversibility warning, and the fact that dry_run enumerates removals plus reclaimable bytes before any change occurs.

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?

The safety banner is front-loaded on line one and the args list is scannable. There is mild redundancy in explaining dry_run twice (once in the prose, once under Args), but nothing is wasted at length.

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

Completeness4/5

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

With no output schema, the description is responsible for return semantics and does describe what dry_run returns (the list of images and reclaimable bytes). Combined with the destructive warning and full parameter semantics, an agent has nearly everything needed; only the target's accepted values remain unclear.

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 largely delivers: it documents all three parameters, gives defaults ('True (default)' for dangling_only, false for dry_run), and clarifies the semantic difference between untagged images and images unused by any container. The target parameter is only described as 'Target name from config', leaving its valid values unspecified.

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

Purpose4/5

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

The description states a specific verb and resource ('Prune images') plus the default scope ('dangling by default'), which is enough for an agent to distinguish it from list_images/dangling_images purely by intent. It stops short of explicitly naming siblings like dangling_images or prune_volumes, 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.

Usage Guidelines3/5

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

It explains the two modes of dangling_only (untagged only vs. unused by any container) and describes dry_run as the safe preview path, which implies when to use each. However, it never routes the agent to alternative tools (e.g. dangling_images to merely list untagged images) nor states prerequisites, so the guidance is implied rather than explicit.

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