Skip to main content
Glama

retrieve_snapshot_list

Read-onlyIdempotent

List and filter all snapshots for a specific Contabo compute instance by name, page, size, or order to review available recovery points.

Instructions

List snapshots [GET /v1/compute/instances/{instanceId}/snapshots] List and filter all your snapshots for a specific instance

Input Schema

NameRequiredDescriptionDefault
nameNoFilter as substring match for snapshots names.
pageNoNumber of page to be fetched.
sizeNoNumber of elements per page.
orderByNoSpecify fields and ordering (ASC for ascending, DESC for descending) in following format `field:ASC|DESC`.
instanceIdYesThe identifier of the instance
x-trace-idNoIdentifier to trace group of requests.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the underlying GET endpoint and confirms filtering scope, but says nothing about pagination defaults, page-size limits, or ordering behavior despite exposing page/size/orderBy parameters.

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?

Two short lines, front-loaded with the core action and scope. The bracketed HTTP route is mildly redundant with the prose but does anchor the resource path clearly.

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?

No output schema exists, so the description carries some burden for explaining what comes back; it does not state that a paginated collection of snapshot objects is returned or whether results are instance-scoped only. Annotations and full schema coverage make it workable, but it is only minimally complete.

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%, so all six parameters including name substring filtering, paging, orderBy format and x-trace-id are already documented. The description adds no syntax or default-value meaning beyond the schema, so baseline 3 applies.

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 ('List snapshots') plus scope ('for a specific instance'), which distinguishes it from retrieve_snapshot and other snapshot tools. It does not name any sibling explicitly, but the instance-scoped listing is unambiguous.

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?

Usage is implied by 'List and filter all your snapshots for a specific instance' — the agent can infer this is the multi-item read rather than the single-item retrieve. There is no explicit when-to-use vs when-not guidance or mention of retrieve_snapshot as the single-record alternative.

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