Skip to main content
Glama
L337-org

docker-mcp-server

by L337-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

buildx_prune

DestructiveIdempotent

Remove BuildKit cache entries to free disk space. Use filters or space limits to target specific cache, and check buildx_du first to see what will be deleted.

Instructions

Remove BuildKit cache entries.

Destructive: this tool always passes --force because no interactive prompt is available under MCP. Pair with buildx_du first to inventory what would be removed. Does not raise on a non-zero CLI exit (a missing buildx plugin or a timeout still raises) - inspect returncode/stderr in the result.

Args: all: Include internal/frontend images filters: Filter by attributes (e.g. {"until": "24h", "type": "exec.cachemount"}) reserved_space: Amount of disk to always keep (e.g. "10GB") max_used_space: Maximum disk space the cache may use (e.g. "20GB") min_free_space: Target amount of free disk after pruning (e.g. "5GB") builder: Override the active builder timeout_seconds: Subprocess timeout (default 600s)

Returns: dict: {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
allNo
builderNo
filtersNo
max_used_spaceNo
min_free_spaceNo
reserved_spaceNo
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.2.1
  2. Removedv2.1.4
  3. Changed3 schema fields changedv2.0.0
    • removedInput schema / properties / filter
      Removed value: -{
-  "default": null,
-  "type": "object"
-}
    • addedInput schema / properties / filters
      Added value: +{
+  "default": null,
+  "type": "object"
+}
    • removedInput schema / properties / keep_storage
      Removed value: -{
-  "default": null,
-  "type": "string"
-}
  4. First observedv1.9.0

TDQS

A4.8/5.0
Behavior5/5

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

The description goes well beyond the annotations by revealing that the tool always passes --force, does not raise on non-zero CLI exit (except for missing plugin or timeout), and returns a structured result dict. It also states destructive behavior directly, reinforcing the destructiveHint annotation without contradiction.

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

Conciseness5/5

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

The description is well-organized: critical safety warning first, then execution-behavior caveat, then a compact parameter list with examples, then the return shape. No redundant sentences or filler; every section earns its place.

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, complex CLI wrapper with no output schema, the description is complete: it covers all parameters, return values, error behavior, timeout defaults, and a safety recommendation to pair with buildx_du. Nothing needed for correct invocation is left unexplained.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates fully by explaining every parameter: all, filters with an example, reserved_space, max_used_space, min_free_space, builder, and timeout_seconds. This adds real meaning beyond the raw schema types and defaults.

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?

The description states a specific verb and resource: 'Remove BuildKit cache entries.' It also clearly distinguishes this from related tools like buildx_du by positioning this as the destructive counterpart and by naming the cache-specific scope.

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?

The description explicitly advises pairing with buildx_du first to inventory what would be removed, which is strong practical usage guidance. It also warns about the tool's exit-code behavior Rhino so the agent knows to inspect returncode/stderr, but it does not formalize when to choose this tool over image_prune or volume_prune.

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