Skip to main content
Glama
csakaszamok
by csakaszamok

delete_sandbox_image_version

Destructive

Deletes a specific sandbox image version from the p9m registry by sandbox name, app, and digest, so you can remove obsolete image versions and free registry space at weekly garbage collection.

Instructions

Delete a version of one of the sandbox's images from the p9m registry

The app name is URL-encoded when it has slashes (team%2Fapi for /team/api). An index takes its platform manifests with it; the space comes back at the weekly garbage collection. HTTP DELETE /sandboxes/{name}/registry/{app}/{digest}

Input Schema

NameRequiredDescriptionDefault
appYes
nameYes
digestYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.1

TDQS

B3.4/5.0
Behavior3/5

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

The destructiveHint annotation already signals that this is a destructive operation. The description adds valuable consequences: deleting an index also removes platform manifests, and space is reclaimed only at weekly garbage collection. It still omits permissions, irreversibility, and error behavior.

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 deletion purpose is front-loaded and the supporting notes are compact. The HTTP path line is useful rather than wasteful, though the description could be slightly tighter.

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

Completeness3/5

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

For a destructive operation with no output schema and undocumented parameters, the description covers key cascade and cleanup behavior. It still leaves gaps around permissions, failure cases, and whether the deletion is immediate or reversible.

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

Parameters3/5

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

Schema coverage is 0%, so the description must carry parameter semantics. It explains URL-encoding for the app parameter and maps name/app/digest through the HTTP path, but does not fully define digest format or clarify that name is the sandbox name.

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?

States a specific verb and resource: deleting a version of a sandbox image from the registry. It is distinguishable from list_sandbox_images, but does not explicitly contrast with siblings.

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?

The deletion context is implied clearly, and the note about index manifests and garbage collection adds useful behavioral guidance. However, it does not explicitly say when to use this versus alternatives or when deletion should be avoided.

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