Skip to main content
Glama

delete_snapshot

DestructiveIdempotent

Delete an existing instance snapshot by instance ID and snapshot ID to remove stored snapshots from Contabo.

Instructions

Delete existing snapshot by id [DELETE /v1/compute/instances/{instanceId}/snapshots/{snapshotId}] Delete existing instance snapshot by id

Input Schema

NameRequiredDescriptionDefault
instanceIdYesThe identifier of the instance
snapshotIdYesThe identifier of the snapshot
x-trace-idNoIdentifier to trace group of requests.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the description's only remaining job is to add context, which it does not. It says nothing about whether the deletion is permanent, whether dependent snapshots/images are affected, or what the caller gets back. It repeats the title verbatim rather than supplementing it.

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

Conciseness2/5

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

The text is short but wastefully duplicated: 'Delete existing snapshot by id [DELETE /v1/...]' is immediately followed by 'Delete existing instance snapshot by id', which restates the same fact. The endpoint path is also already implied by the operation; the second sentence earns no place.

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?

With full schema coverage and rich annotations, the minimum is met, but for a destructive operation the description should mention permanence or consequences. An agent knows what to send but not what it is about to lose, which is the one gap annotations cannot close.

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 description coverage is 100%, with instanceId and snapshotId both documented inline, so the baseline applies. The description adds no format or constraint detail (e.g., that snapshotId is a string UUID or whether x-trace-id is optional), so it neither helps nor hurts.

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 ('Delete existing snapshot by id'), so an agent can tell it apart from update_snapshot, rollback_snapshot, or delete_image without reading the schema. It stops short of explicitly contrasting itself with the sibling that would be the closest wrong choice (rollback_snapshot).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance at all on when to use this versus rollback_snapshot or update_snapshot, no prerequisites, and no warning about irreversibility beyond what the destructiveHint annotation already says. The only usage signal is the implicit 'delete = removal'.

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