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

Annotations already declare readOnlyHint=true, but the description adds real context beyond that: the server rejects write operations until started with CONTABO_ENABLE_WRITES=1, and parameter sets are validated per operation. That is meaningful behavioral disclosure for a tool whose name alone doesn't reveal the enforcement mechanism.

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?

The read-only caveat and the operation-selection rule are well front-loaded, but the 16-line operation list largely restates the const values already present in the oneOf schema and pads every line with the redundant '(audit)' suffix. Functional, but not tight.

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 16-way discriminated union with no output schema, the description gives the agent the operation roster, the selection rule, the read-only constraint, and a pointer to contabo_reference, which is enough to invoke it correctly. Missing pagination behavior and a sense of what an audit entry contains, but those are minor given the absent output schema.

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 schema already documents page, size, dates, orderBy, and per-operation identifiers; baseline is 3. The description adds only structural guidance about the discriminated union ('one operation, its own parameter set') and defers detailed semantics to contabo_reference, adding little beyond the schema itself.

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?

States a specific resource ('Contabo audit logs for every resource type') and enumerates the 16 covered resource types, which lets an agent separate it from sibling management tools like contabo_instances or contabo_firewalls. The retrieval verb is only implied ('audit logs', repeated 'List history'), not stated directly in the opening, but the scope is unambiguous.

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?

Tells the agent to 'Choose exactly one operation' and that each operation has its own validated parameter set, and routes to contabo_reference for full docs. It never states when to use this audit-log tool rather than the live-resource siblings, so the agent must infer that this is retrospective history rather than current state.

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

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

Annotations are coarse (a single destructiveHint=true across 14 heterogeneous operations), and the description genuinely refines them by tagging the three delete/bulk-delete operations as DESTRUCTIVE per operation. It also discloses a behavioral constraint the annotations cannot express: writes are rejected unless the server is started with CONTABO_ENABLE_WRITES=1. It does not cover auth requirements, rate limits, or pagination defaults.

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?

The overall purpose, the read-only gate, and the operation count rule are front-loaded ahead of the enumeration, which is the right ordering. The operation list is long but each line is load-bearing for a discriminated mega-tool, though some entries are near-redundant ('...by ip address' repeated across PTR operations).

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 14-operation multiplexed tool with no output schema, the description covers operation discovery, destructive flagging, and the write gate, and it explicitly delegates full parameter documentation to contabo_reference. What is missing is any hint about return shape or pagination semantics for the list operations, which the absent output schema would otherwise force the description to carry.

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%, and the schema itself carries per-operation property descriptions, so the baseline is 3. The description adds only the meta-claim that parameters are validated per operation and defers detail to contabo_reference; it contributes no field-level meaning beyond the schema.

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 opens with the resource domain (DNS zones, records, PTR records) and then enumerates all 14 operations with specific verb+resource phrasing, so an agent can map an intent like 'delete a PTR record' to an operation name without opening the schema. It is clearly distinguishable from siblings such as contabo_domains and contabo_reference.

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 selection rule explicitly ('Choose exactly one operation; every operation has its own parameter set') and routes parameter questions to contabo_reference. However, it never says when to prefer this tool over the neighbouring contabo_domains tool, so the guidance covers operation choice but not tool choice.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, but the description adds meaningful context beyond that: the server is currently read-only and writes are rejected until CONTABO_ENABLE_WRITES=1, and it marks the specific operations carrying destructive semantics. That runtime gate and per-operation risk labeling are genuinely useful and not derivable from the annotations.

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?

Purpose and the read-only caveat are front-loaded, followed by a scannable operation list, which fits a dispatcher tool. The 18-line enumeration is dense but each line earns its place by flagging operation name and destructive status; structure is sound with minimal waste.

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?

Given a router with no output schema and 100% schema coverage, the description supplies what an agent needs: operation inventory, destructive flags, the write-gate caveat, and a pointer to contabo_reference for parameters. The cross-tool dependency for parameter docs is the only mild gap, but the schema itself is fully described.

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 parameter. The description only states that parameters are validated per operation and defers full documentation to contabo_reference, adding no syntax or format detail itself. Baseline 3 is appropriate 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 precisely ("Contabo domains and contact handles") and enumerates all 18 operations, so an agent knows exactly what scope this tool covers versus siblings like contabo_dns or contabo_instances. It is clear but not maximally differentiated — it doesn't state what distinguishes domain handling from, e.g., DNS management.

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 gives the key routing rule ("choose exactly one 'operation'; every operation has its own parameter set") and flags which operations are destructive, which is real guidance for a dispatcher. However, it offers no when-to-use / when-not-to-use framing against sibling tools, leaving the choice between this and other Contabo tools implied rather than stated.

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

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

Beyond the coarse readOnlyHint=false / destructiveHint=true annotations, the description discloses a runtime gate (write operations are rejected until CONTABO_ENABLE_WRITES=1) and granularizes destructiveness to specific operations ([DESTRUCTIVE] on delete and unassignInstance). The 'runs READ-ONLY' phrasing sits in tension with readOnlyHint=false, but since it is explicitly qualified as a default-state gate and the write operations are all enumerated, it reads as added context rather than a literal contradiction.

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 dispatch rule, then a scannable bulleted operation list, then the read-only note and the reference pointer. Each block earns its place, though the read-only paragraph could be tightened slightly.

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 nine-operation dispatcher with no output schema, the description covers the dispatch model, every operation's intent, per-operation destructiveness, the write gate, and where to find parameter docs. The main residual gap is that it never describes return shapes or pagination behavior for the list/get operations, which the absent output schema leaves undocumented.

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 baseline is 3; the description earns above baseline by telling the agent that parameters are operation-specific and validated per operation, and by pointing to contabo_reference for full parameter documentation. It does not itself explain syntax of key fields (page/size/orderBy), so it adds structural rather than syntactic meaning.

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 a specific resource (Contabo firewalls and their rules) and enumerates nine concrete operations, each a clear verb+resource pair (create, list, delete, get, update, updateRules, assignInstance, unassignInstance, listPresetRules). An agent can tell this apart from contabo_instances, contabo_snapshots, or contabo_privateNetworks purely from the resource scope and operation list.

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 explains the dispatch contract ('choose exactly one operation; every operation has its own parameter set') and routes the agent to contabo_reference for parameter docs, and it flags delete/unassignInstance as destructive. However it gives no sequencing guidance (e.g. list first to obtain firewallId before delete/get) and no explicit when-not-to-use or alternative-selection rules, leaving the per-operation choice implied by the labels alone.

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

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.

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), it discloses the server-level read-only default, the env flag that unlocks writes, and per-operation destructive flags (shutdown, resetPassword, cancel). This is meaningful operational context that the annotations alone do not convey.

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?

The purpose and read-only warning are front-loaded, and the operation list is a clean bulleted enumeration with terse, well-formed entries. It is necessarily long for a 16-operation multiplexer, so nothing is really wasted, but the volume is non-trivial.

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 complex oneOf multiplexer with no output schema, the description explains the operation-dispatch model, the read-only gate, destructive flags, and where to find parameter docs. Return-value behavior is never addressed, but that is acceptable given no output schema and the delegation to contabo_reference.

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% and each operation branch documents its own parameters, so the schema carries the semantic burden. The description only notes that params are validated per operation and defers detail to contabo_reference, which is marginal but appropriate value-add; baseline 3 applies.

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 a specific resource ('Contabo compute instances (VPS/VDS)') and enumerates all 16 supported operations, so the agent immediately knows this is the instances-management surface. It is clearly distinct from siblings like contabo_firewalls, contabo_snapshots, and contabo_dns.

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 gives the key dispatch rule ('Choose exactly one operation; every operation has its own parameter set') and routes parameter discovery to contabo_reference. It flags the read-only server gate (CONTABO_ENABLE_WRITES=1) and marks three operations DESTRUCTIVE, giving clear usage context, though it never states explicit when-not-to-use conditions relative to sibling tools.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true; the description adds context the annotations cannot carry, namely that the running server is read-only by default and rejects writes until an environment flag is set, and it flags 'cancel' as [DESTRUCTIVE]. That is meaningful behavioral disclosure beyond the annotation booleans, though it does not describe permission scoping or reversibility per operation (e.g. upgrade's no-downgrade rule is left to the schema).

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-loads the scope and the read-only constraint before the operation list, and every bullet maps to a real operation rather than padding. It is longer than a single-line tool description but the length is justified by eight distinct operations, with only minor redundancy between the header sentence and the operation list.

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?

There is no output schema, so return values are undescribed, and pagination/filter behavior for list and listDataCenters is left implicit. Against that, the description routes the agent to contabo_reference for the full parameter documentation and flags the one destructive operation, which is enough for correct operation selection.

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 parameters are already well documented in the schema and the baseline is 3. The description contributes the structural insight that each operation has its own validated parameter set and defers full parameter docs to contabo_reference, but adds no per-field meaning of its own.

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?

Names the specific resource (Contabo S3-compatible object storages and data centers) and enumerates all eight operations with a distinct verb each (list, create, get, update, upgrade, stats, cancel, listDataCenters). An agent can tell this apart from siblings like contabo_instances or contabo_firewalls purely from the resource name and the operation inventory.

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?

Gives an explicit selection rule ('Choose exactly one operation') and a critical activation constraint (write operations are rejected unless the server is started with CONTABO_ENABLE_WRITES=1), plus a pointer to contabo_reference for parameter docs. It does not name when to prefer a sibling tool, so it stops short of a 5.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, so the safety profile is already partly covered; the description adds material context beyond that by disclosing the CONTABO_ENABLE_WRITES=1 runtime gate that causes write operations to be rejected. It also flags which specific operations are destructive. It does not cover auth requirements, rate limits, or side effects such as what happens to attached instances when a network is deleted.

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 compact bulleted operation list, then the reference pointer. Structure is easy to scan. The operation bullets largely restate the operation names, which is mild redundancy, though it does help navigate a oneOf-heavy schema.

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 dispatcher with no output schema and a heavily branched oneOf input, the description covers operation selection, the write gate, destructive markers, and where to find parameter docs. Return values and list pagination are not described, but parameter semantics are well covered by the schema. Adequate overall, with minor gaps around results and pagination behavior.

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%, and the description explicitly defers parameter detail to contabo_reference rather than repeating it, which is reasonable but adds no semantic value of its own. The only param-related statement is meta-level ('every operation has its own parameter set (validated per operation)'). 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 ('Contabo private networks (VPC)') and enumerates all seven operations with distinct verbs (list, create, update, get, delete, assignInstance, unassignInstance). Sibling tools cover disjoint resources (firewalls, instances, DNS, etc.), so no ambiguity arises. An agent can tell exactly what this tool does without opening the schema.

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 gives clear operating instructions: 'Choose exactly one operation', notes that each operation has its own validated parameter set, and explicitly tags delete and unassignInstance as [DESTRUCTIVE]. It also routes the agent to contabo_reference for parameter documentation. It stops short of stating when this tool should be preferred over alternatives, but the siblings cover different resources so there is little genuine alternative to disambiguate.

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

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

Annotations declare readOnlyHint=true, so safety is already covered; the description adds substantive behavioral detail beyond that, namely the two operating modes and exactly what content each returns (types, required fields, enums, defaults, descriptions, exact input JSON Schema). It stops short of noting any limits on output size or pagination, but it is well above the annotation baseline.

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?

Two sentences, zero filler, with the core purpose front-loaded before the usage instructions. Every clause carries information.

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?

There is no output schema, so the description must cover return content, and it does, enumerating the fields returned in full-documentation mode. For a two-parameter, read-only lookup tool this leaves nothing an agent needs missing.

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 both parameters are already documented in the schema, including the note that omitting operation lists all operations. The description restates the same domain/domain+operation combination rather than adding syntax, format, or naming rules, so the baseline 3 is appropriate.

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 states a specific resource (documentation for every Contabo MCP operation) and a specific action (list operations or fetch full parameter docs), making it clearly distinct from all sibling tools, which are the actual operation tools. An agent can immediately tell this is the meta/discovery tool rather than an action tool.

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 gives explicit mode-based usage: pass a domain to enumerate operations, pass domain + operation for full parameter docs. That is clear context for how to invoke it, though it never explicitly says to call this before the sibling operation tools or when not to use it.

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

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

Annotations already flag readOnlyHint=false and destructiveHint=true, and the description adds genuinely new context beyond them: the server runs read-only by default and rejects writes until an env flag is set, and delete is explicitly marked [DESTRUCTIVE]. That gating behavior is exactly the kind of trait an agent could not infer from the annotations alone.

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?

The text is tight and front-loaded: mode constraint first, then a scannable bulleted operation list, then the pointer to contabo_reference. Every sentence carries information and the destructive marker is inline where the agent will see it.

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 five-operation tool with a complex oneOf schema and no output schema, the description gives enough to select and invoke the right operation and to know writes are gated. It could have stated which operations are affected by the read-only mode and what the delete returns, but the coverage is adequate given 100% schema description density.

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 parameter definitions (name, value, type, secretId filters) are already fully documented in the schema, including the password regex. The description adds no parameter-level detail of its own and instead defers to contabo_reference, which is the expected baseline when the schema carries the load.

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 precisely (Contabo secrets covering SSH keys and passwords) and enumerates the five supported operations, so an agent knows exactly what domain this tool covers. It does not differentiate against named siblings such as contabo_reference, but the resource scope is unambiguous.

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 governing usage rule ('Choose exactly one operation'; parameters validated per operation) and adds a critical runtime constraint: writes are rejected unless the server started with CONTABO_ENABLE_WRITES=1. It also routes the agent to contabo_reference for full parameter documentation. There is no explicit when-to-use-vs-alternative guidance, but no sibling tool competes for this resource.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=true; the description adds materially more, disclosing that the server is READ-ONLY by default and that write operations are rejected unless started with CONTABO_ENABLE_WRITES=1, plus tagging delete and rollback as [DESTRUCTIVE]. It does not explain the effect of a rollback on current instance state, which is the one behavioral trait an agent would most want spelled out.

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, then the read-only constraint, then a scannable per-operation list where destructive entries are tagged inline. It is well organized with no filler, though the trailing pointer to contabo_reference is the only place parameter expectations are set and could be folded closer to the list.

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 six-operation dispatch tool with no output schema, the description covers the essential agent needs: the operation catalog, the exactly-one-operation contract, per-operation parameter sets, the write gating, and a pointer for deeper parameter docs. Nothing required to select and invoke a valid operation is absent.

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 schema already documents instanceId, snapshotId, name, description, pagination and ordering with length limits. The description only asserts that parameter sets are validated per operation and delegates detail to contabo_reference, adding routing value but no semantic detail beyond the schema; the high-coverage baseline of 3 is appropriate.

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 opening line names a specific resource (Contabo instance snapshots) and the operation list supplies a concrete verb for each mode (list/create/get/update/delete/rollback), so an agent knows exactly what the tool does. It does not explicitly differentiate itself from the nearest sibling, contabo_images, which also manages instance artifacts, so it falls short of a 5.

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 dispatch contract ('Choose exactly one operation; every operation has its own parameter set') and routes the agent to contabo_reference for full parameter documentation, which is clear usage context. What is missing is when-not-to-use guidance, i.e. why an agent would pick a snapshot operation over related tools like contabo_images or contabo_instances backup flows.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description adds genuinely new context: the server is gated read-only until CONTABO_ENABLE_WRITES=1, and delete/deleteAssignment are marked [DESTRUCTIVE]. It doesn't say what delete cascades to (tag vs. its assignments) or whether changes are reversible, so not a 5.

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-loads the resource and the operation-selection rule, then uses a scannable operation list; the read-only warning is placed before the list where it matters. The operation lines are terse and earn their place, with only minor redundancy against the schema.

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 nine-operation dispatcher with no output schema, the description covers routing, safety flags, the write-enable gate, and where to find full parameter docs. Missing detail on what destructive operations actually remove and their side effects keeps it from a 5.

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% and the oneOf variants already document each operation's parameters, so the baseline is 3. The description repeats the per-operation parameter-set structure and defers detail to contabo_reference rather than adding new parameter semantics.

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?

Opens with the specific resource ('Contabo tags and tag assignments') and enumerates all nine operations with a one-line action each, so an agent knows exactly what the tool covers. It does not explicitly contrast itself with siblings such as contabo_reference or contabo_instances, keeping it short of a 5.

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?

States the selection rule clearly ('Choose exactly one operation') and flags which operations are destructive, plus the runtime condition (writes rejected unless CONTABO_ENABLE_WRITES=1). It lacks explicit when-to-prefer-this-over-alternatives guidance, but the operation routing and safety context is clear.

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

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

Beyond the annotations it tags the three cancel operations as [DESTRUCTIVE] and documents the CONTABO_ENABLE_WRITES=1 gate that governs whether write operations execute. There is mild tension with readOnlyHint=false since it headlines 'READ-ONLY', but it also explicitly discloses that writes exist and can be enabled, so it does not outright contradict the annotation.

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?

The selection rule, the read-only/write-gate caveat, and the reference pointer are front-loaded before the operation table. The 14-line list is long but each line carries selector information; the only waste is the tautological per-operation glosses ('List check', 'Get check').

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 14-operation polymorphic tool with no output schema, the definition covers operation enumeration, destructive flags, and the write gate, and explicitly delegates field-level detail to contabo_reference. The main remaining gap is that an agent must make a second call to learn required parameters per operation.

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% and the schema itself encodes per-operation required fields via oneOf, so the baseline is 3. The description adds only meta-level semantics ('each operation has its own parameter set, validated per operation') and defers all field-level meaning to contabo_reference, which is honest but not additive.

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 domain (troubleshooting checks, check collections, remedies) and enumerates all 14 concrete operations, so an agent can tell this apart from siblings like contabo_instances or contabo_audits. It never opens with a clean verb+resource statement, but the operation list compensates and the scope is unambiguous.

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 gives the key invocation rule ('Choose exactly one operation'; per-operation parameter validation) and routes to contabo_reference for full parameter docs. However, it offers no guidance on when to pick troubleshooting checks over other sibling tools, and no when-not conditions — the per-operation one-liners ('List check', 'Start check') are implied usage at best.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true) the description adds genuinely valuable context: the server rejects writes unless started with CONTABO_ENABLE_WRITES=1, and it flags each destructive operation inline with [DESTRUCTIVE]. It does not explain what a destructive call actually destroys, nor permission/auth requirements, so it stops short of a 5.

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?

The size is justified by 23 operations, and the key facts (resource scope, read-only gating, one-operation rule) are front-loaded before the enumeration. The operation list is terse and scannable, though a few entry descriptions are near-tautological (e.g. 'list: List users').

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?

Given 23 operations and no output schema, the definition covers purpose, the read-only default, destructive flags, and where to find parameter docs. It is complete enough to invoke correctly, with only the sibling-routing and destructive-impact details left implicit.

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 schema already documents every parameter per operation. The description adds only structural insight (one operation per call, per-operation validation) and defers detail to contabo_reference, which matches the baseline 3 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 opening line names a concrete resource domain (users, roles, accounts, object-storage credentials) and the operation list makes the tool's scope unambiguous. It does not, however, differentiate itself from overlapping siblings such as contabo_objectStorage or contabo_secrets, so an agent must infer the boundary itself.

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 gives clear operating instructions: choose exactly one 'operation', params are validated per operation, and it routes the agent to contabo_reference for full parameter documentation. What is missing is explicit when-to-use-this-vs-sibling routing, e.g. when to pick this over contabo_objectStorage for credential tasks.

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

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

Beyond the annotations, it discloses that the server is READ-ONLY by default and that write operations are rejected until CONTABO_ENABLE_WRITES=1 — critical operational context an agent would otherwise miss. It also flags unassign as [DESTRUCTIVE] and notes per-operation parameter validation. It stops short of saying what happens to the VIP after unassign (detached vs released).

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-loads the two things that matter most (one-operation rule, read-only gating) before the bulleted operation list, and every sentence carries information. Minor waste and a copy error in the unassign description ('Unassign a VIP to a VPS' instead of 'from') keep it from a 5.

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 oneOf multiplexed tool with no output schema, this covers the essentials: what the tool is, how to select an operation, the destructive/default-read-only constraints, and where to find parameter details. Return-value behavior is not described, but that is acceptable given the absent output schema.

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 schema already documents every field, and the description adds no syntax or format meaning for any parameter. It does explicitly offload parameter documentation to contabo_reference, which is helpful routing but not parameter semantics itself. Baseline 3 applies.

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 identifies the resource (Contabo virtual IPs / VIPs) and enumerates the four concrete operations (list, get, assign, unassign) with a one-line gloss of each. An agent knows exactly what surface this tool covers. It loses a point because the opening line mostly restates the tool name and the tool is not explicitly differentiated from siblings like contabo_instances or contabo_firewalls.

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 structural rule for use ('Choose exactly one operation') and routes the agent to contabo_reference for per-operation parameter documentation, which is genuinely useful for a multiplexed tool. What's missing is guidance on when a caller would want assign vs get vs list, though the operation names are largely self-explanatory.

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