contabo_images

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

Annotations only supply destructiveHint/readOnlyHint; the description adds non-obvious operational context — writes are rejected unless the server is started with CONTABO_ENABLE_WRITES=1, and delete is explicitly tagged [DESTRUCTIVE]. It does not describe return payloads, pagination, or auth requirements, so there is still some gap. The stated READ-ONLY default is a deployment gating note rather than an outright contradiction of readOnlyHint=false, since it also documents that write operations exist.

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

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

Front-loaded with the resource and the one-operation rule, then a clean scannable operation list, then the escalation pointer to contabo_reference. Every line carries information; only the read-only-server sentence is slightly verbose relative to the rest.

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

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

For a multi-operation oneOf tool with no output schema, the description covers the full operation surface, the write-gating behavior, the destructive operation, and where to find parameter detail. Return values and per-operation success/failure behavior are unaddressed, but the essential call-time information is present.

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

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

Schema description coverage is 100%, so the per-operation schemas already document every field, and the description explicitly delegates parameter detail to contabo_reference. It adds structural value by stating that each operation has its own parameter set validated per operation, but no field-level semantics beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names the resource (standard and custom images) and enumerates six concrete operations with a specific verb+object for each (list, create, get, update, delete, stats). An agent can tell exactly what this tool covers and how it differs from siblings like contabo_snapshots or contabo_instances.

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

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

It states the routing rule up front ('Choose exactly one operation') and that each operation has its own validated parameter set, plus a clear pointer to contabo_reference for full parameter documentation. It gives no guidance on when to prefer this tool over a sibling or which sibling handles adjacent image tasks, so it stops short of explicit when/when-not coverage.

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