Exoscale MCP by usefulapi

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds value by disclosing the response payload (size, block size, state, attached instance, encryption, labels, snapshots), which matters given there is no output schema. It omits auth/permission context, but the read semantics are clear.

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 compact sentences, front-loaded with the resource and its returned fields, ending with the endpoint. No wasted words.

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?

With no output schema and no nested objects, the field enumeration usefully tells the agent what a call returns. Parameter and safety information is already covered by schema and annotations, leaving only minor gaps such as error behavior for invalid ids.

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 coverage is 100% with only two parameters, both fully documented in the schema (id pattern, zone enum and default). The description adds no parameter-level meaning, 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?

States a specific verb (fetch details) and resource (one block storage volume), then enumerates the fields returned and cites the underlying endpoint. The singular 'one' cleanly distinguishes it from the sibling exoscale_list_block_storage_volumes.

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?

The description implies a single-resource lookup by id, which contrasts implicitly with the list sibling, but it never explicitly says when to use this versus exoscale_list_block_storage_volumes or states any prerequisite (e.g., needing a known id). Usage is inferable rather than spelled out.

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=true and destructiveHint=false, lowering the bar. The description adds only the endpoint mapping (GET /dns-domain/{id}), which is structural rather than behavioral. No info on auth, errors, or what happens for missing IDs.

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?

Extremely concise, two fragments, front-loaded with the resource. Zero 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?

For a simple read-only GET, the description is adequate but doesn't cover the response shape (no output schema) or error behavior. An agent has enough to call it, but limited context.

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 coverage is 100% with a detailed pattern and description for the id parameter. The description adds nothing beyond what the schema provides. 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?

States a specific verb+resource: retrieving details of one DNS domain. The sibling 'exoscale_list_dns_domains' is implied by 'one' vs list, but not named explicitly. Still clearly distinguishable.

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?

Usage is implied by the singular 'one DNS domain' vs the list sibling, but no explicit when-to-use or when-not guidance is provided. Minimum viable.

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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the returned field list and HTTP method, but does not disclose error behavior, authentication requirements, or rate limits, which would be the remaining useful behavioral context.

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 with zero waste. The purpose and returned fields are front-loaded, and the trailing endpoint reference is compact and informative.

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 simple read-only retrieval tool with full schema coverage and annotations that carry the safety profile, this description is sufficient. It tells the agent what the tool does, what it returns, and the underlying endpoint, with no output schema needed to supplement it.

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 the id pattern and the zone enum/default are already documented in the schema. The description adds no additional meaning about parameter usage or format beyond what the schema provides, making the baseline 3 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 verb and resource ('Details of one elastic IP') and explicitly scopes it to a single resource, which cleanly separates it from the sibling exoscale_list_elastic_ips. It also names the exact fields surfaced (address, CIDR, family, description, health check, labels), so an agent knows precisely what this tool returns.

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?

Usage is implied by the singular scope and the 'GET /elastic-ip/{id}' endpoint, but there is no explicit guidance on when to choose this over exoscale_list_elastic_ips or other exoscale_get_* tools. No prerequisites, exclusions, or alternative-selection criteria are 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral detail beyond that: the cloud-init user-data is never returned, and it names the underlying endpoint GET /instance/{id}, which helps the agent understand scope and side-effect-free retrieval.

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 compact sentences, front-loaded with the returned field set followed by the negative disclosure and the endpoint. Every clause carries information and nothing is redundant.

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?

With no output schema, the description carries the burden of describing return contents, and it does so by enumerating state, type, template, disk size, networks, security groups, elastic IPs and snapshots, plus the explicit exclusion of user-data. Only minor gaps remain (e.g., error/not-found behavior), which are non-critical for a read tool.

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 the id (UUID) and zone (with default 'zone chosen at login') are fully documented in the schema. The description adds only the {id} path fragment, which does not extend the schema's meaning; 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 verb (retrieves details) and a single, well-defined resource (one compute instance), then enumerates the fields returned. 'One compute instance' cleanly distinguishes it from exoscale_list_instances and other get_* siblings without ambiguity.

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?

Usage is only implied: the singular 'one compute instance' plus the required id parameter signal that this fetches a single known instance. There is no explicit statement of when to prefer this over list_instances or when it should not be used, so the agent must infer the routing.

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=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the underlying endpoint (GET /instance-type/{id}) and the shape of the payload (family, size, CPUs, GPUs, memory, zones), which is more than the annotations provide.

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 compact sentences with the field inventory front-loaded and the endpoint appended as confirmation. No filler or redundancy; 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?

With no output schema, the description usefully previews the returned fields, which is the main thing an agent would otherwise have to guess. It omits any mention of error behavior (e.g., invalid or unknown id in a given zone), a minor gap for a simple read tool.

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 the id pattern/format and the zone enum with its default are already documented in the schema. The description contributes nothing about parameters, which is the expected baseline 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?

States a specific verb+resource (retrieve one instance type) and enumerates the fields returned. The singular 'one instance type' implicitly distinguishes it from exoscale_list_instance_types, but it never names that sibling explicitly, so differentiation is left to inference.

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?

Usage is only implied: 'one instance type' suggests a lookup-by-id after a list call, but there is no explicit statement of when to use this versus exoscale_list_instance_types or how to obtain a valid id. No prerequisites or exclusions are given.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds async-operation context, the status set, and the zone-matching constraint, which are useful beyond the structured fields.

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?

Three tight sentences: purpose and possible states first, usage/zone constraint second, endpoint last. No wasted text.

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 simple read-only lookup with full schema descriptions and safety annotations, the description supplies the missing behavioral context (async statuses and zone scoping). It does not explain polling behavior or the full response shape, but the statuses are the key return values.

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 id and zone. The description adds a meaningful constraint for zone—use the same zone as the call that created the operation—which goes beyond the schema's login-default framing.

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 verb and resource: get the state of an asynchronous operation, with enumerated states (pending, success, failure, timeout). It is clearly distinguishable from sibling get_* tools, none of which return operation status.

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 when to use it (after start, stop, or reboot) and the key prerequisite (same zone as the creating call). It does not name when-not to use it or an alternative tool, so it falls 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 already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds real context beyond that: the call is scoped to the API key's own organization and it exposes billing-relevant fields (balance, currency). No pagination, rate-limit, or error behavior is discussed.

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?

A single front-loaded sentence that names the resource first, then the fields, then the endpoint. Every element is relevant, though the trailing 'GET /organization.' is API-doc residue that adds little for an agent.

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?

With no output schema, the description compensates by enumerating the returned fields (id, name, address, country, balance, currency), which is exactly what an agent needs. For a zero-parameter read tool the definition is essentially complete; only usage rationale is 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument call and adds nothing misleading about inputs.

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 the specific resource (the Exoscale organization) plus scope ('of the API key') and enumerates the returned fields, so an agent can distinguish it from sibling GET tools for instances, volumes, quotas, etc. It lacks an explicit verb in the description body (the title supplies 'Get'), which keeps it just 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?

The description never says when or why to call this tool versus any alternative; it only describes what is returned. There is no sibling overlap to disambiguate, so the risk is low, but no usage guidance is actually provided.

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=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds value by disclosing the return content ('usage and limit') in the absence of an output schema, plus the underlying GET /quota/{entity} route, though it says nothing about error or auth behavior.

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?

Three short clauses, zero filler, with the core purpose front-loaded and the alternative-tool hint following immediately. Every fragment earns its place.

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 single-parameter read tool with no output schema, the description supplies what the response contains (usage and limit) and how to obtain the required entity name. Only minor gaps remain, such as hierarchy or invalid-entity 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 single parameter is already documented with the same 'instance' example, so the description adds no meaning beyond the schema. Baseline 3 applies when the schema does all the work.

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 precisely what is returned (usage and limit) for a specific resource (one quota entity) and names the example entity 'instance'. It also implicitly distinguishes itself from the sibling exoscale_list_quotas by framing that tool as the source of entity names.

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?

Explicitly routes the agent to exoscale_list_quotas to discover valid entity names, which is the key prerequisite. It stops short of stating when not to use this tool or what happens for an invalid entity, but the primary usage path 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context the annotations do not: the conditional "when the API includes them" warns the agent that rules may be absent from the response, which prevents misinterpreting an empty rules array.

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?

One front-loaded sentence carrying the return-shape information, followed by the REST endpoint mapping. The trailing "GET /security-group/{id}" is arguably redundant with the tool name but is short and harmless.

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?

With no output schema, the description correctly compensates by enumerating the return fields and their sub-fields, which is exactly what an agent needs to plan parsing. Missing only pagination/error behavior and any note on the zone parameter's default.

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 id and zone are documented in the schema itself. The description adds no format or constraint detail beyond that, so the 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?

States a specific verb and resource ("Details of one security group") and enumerates the returned fields (description, external sources, rules with protocol/ports/network/direction). It distinguishes itself from the plural sibling exoscale_list_security_groups implicitly via "one security group", though it does not name that sibling explicitly.

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?

The singular scope implies lookup-by-id usage versus the list sibling, but there is no explicit when-to-use guidance, no statement of prerequisites (zone selection), and no exclusion of alternatives. Usage is inferable but not 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?

Annotations already declare readOnly=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds one behavioral note beyond that — 'OIDC settings (no secrets)' — which usefully signals redaction, but it says nothing about auth, rate limits, or missing-cluster behavior.

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 field inventory in a single tight sentence, with the REST path appended. The path is somewhat redundant with the tool name, keeping it just short of 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?

With no output schema, the description's field enumeration usefully tells the agent what comes back, and the '(no secrets)' caveat sets expectations. It is largely complete for a one-parameter read, though it omits pagination/error behavior that a full 5 would touch.

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 coverage is 100% with both parameters (id, zone) fully documented in the schema, so the schema carries the load. The description adds no syntax, format, or zone-selection meaning beyond it, which is the baseline-3 case.

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 verb ('Details of one') and resource (SKS cluster), and enumerates the exact fields returned (version, state, level, CNI, add-ons, OIDC settings, endpoint, node pools). The word 'one' cleanly distinguishes it from the sibling exoscale_list_sks_clusters.

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?

Usage is only implied by the singular 'one SKS cluster' versus the sibling list tool; there is no explicit statement of when to use this versus exoscale_list_sks_clusters or any prerequisite/zone guidance. Adequate but with a clear gap.

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=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds essentially nothing behavioral beyond restating the REST path 'GET /template/{id}' — no note on error behavior for unknown ids, zone defaulting, or caching.

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 short fragments with no filler; the field inventory is front-loaded and the endpoint path trails as a compact reference. Slightly terse but every token 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 listing the returned fields (name, family, version, default user, size, boot mode, checksum, zones) usefully compensates by telling the agent what it will receive. Missing only where the tool fits relative to list_templates for a fully complete picture.

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%: both 'id' (UUID pattern) and 'zone' (enum with login-default note) are fully documented in the schema. The description adds no extra meaning, so the 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 verb+resource (get a single template) and enumerates the fields returned, making it easy to distinguish from the sibling exoscale_list_templates by scope ('one template'). It does not call out that sibling by name, so it stops short of full sibling differentiation.

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?

Usage is only implied: the agent must infer it should call this when it has a template id and needs full details rather than a list. No explicit when-to-use, prerequisites, or alternative (e.g. list_templates) is given.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that results are aggregated per line with named fields and names the underlying GET endpoint, but says nothing about pagination behavior beyond what the schema already documents or about any rate/latency characteristics.

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 short sentences, front-loading the resource and scope, followed by the endpoint reference. No filler or redundancy.

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 does useful work by outlining the fields returned per line (product, variable, quantity, unit). Pagination and period formatting are handled by the schema. Minor gaps remain, such as whether values are monetary or units of measure and whether totals are included.

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 coverage is 100% and each parameter (limit, offset, period) is fully documented in the schema, including the YYYY-MM pattern and next_offset usage. The description adds no parameter-level meaning beyond that, so the baseline of 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?

States a specific resource (aggregated usage report for the organization over one month) and enumerates the returned line fields (product, variable, quantity, unit), plus the backing endpoint. It is clearly distinct from siblings like exoscale_get_quota or exoscale_get_organization, though it never explicitly contrasts itself with them.

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?

The description says what the report covers but gives no guidance on when to call it versus alternatives (e.g. quota vs usage report) and no prerequisites or exclusions. Usage can only be inferred from the resource name.

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=true and destructiveHint=false, so the safe-read profile is covered. The description adds what a caller gets back (name, size, state, attachment, encryption, snapshots), which is useful, but it discloses nothing about pagination behavior, defaults, or rate limits.

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?

Compact and front-loaded: the resource and its per-zone scope lead, then the returned fields. The trailing 'GET /block-storage.' restates the obvious from the tool name and is mild filler.

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?

With no output schema, the description helpfully lists the fields returned and the zone scope, which is enough for a simple list tool whose parameters and safety profile are already covered by schema and annotations. Only pagination semantics and sibling routing are 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 all four parameters (zone, limit, offset, instance_id) are fully documented in the schema, including defaults and the next_offset pattern. The description only restates the zone scoping and adds nothing about the other parameters, so the 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?

States a specific verb ('List') and resource ('block storage volumes'), scoped to a zone, and enumerates the returned fields. It is clearly distinct from the singular exoscale_get_block_storage_volume, though the description never names that sibling explicitly, leaving differentiation to the natural read of the verb.

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?

There is no when-to-use guidance, no statement of when this is preferable to exoscale_get_block_storage_volume, and no mention of prerequisites or pagination intent. The zone scoping is stated but purely as a fact, not as usage direction.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful 'DNS is the same in every zone' scoping fact and the endpoint, but says nothing about pagination behavior or how large result sets behave, which the schema only hints at ('The API itself returns whole lists').

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 compact sentences, front-loaded with the action and result shape, with the zone-scoping caveat immediately after. Nothing is wasted and nothing is buried.

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's enumeration of returned fields (id, unicode name, creation date) is genuinely load-bearing, and annotations plus the schema cover safety and pagination parameters. Minor gap: it does not characterize result volume or typical pagination needs for a list endpoint.

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 limit and offset are fully documented in the schema itself, including default values and the next_offset convention. The description adds no parameter guidance, so the 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?

States a specific verb ('List'), resource ('DNS domains (zones)'), plus the fields returned (id, unicode name, creation date) and the underlying endpoint (GET /dns-domain). This clearly distinguishes it from the singular exoscale_get_dns_domain and from exoscale_list_dns_records.

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?

Usage is implied by the 'List' verb and the explicit note that 'DNS is the same in every zone', which usefully tells the agent no zone parameter is required. However, it never names the alternative exoscale_get_dns_domain for a single domain or exoscale_list_dns_records, nor states any when-not-to-use condition.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the concrete API path (GET /dns-domain/{domain-id}/record), but says nothing about ordering, pagination behavior, or result size beyond what the schema already documents, so it only modestly exceeds 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?

Three compact sentences, front-loaded with the purpose and returned fields, then the dependency, then the endpoint. No filler and nothing duplicated unnecessarily.

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?

With no output schema, the description usefully enumerates the record fields returned and points to the sibling that supplies the domain id. It does not mention pagination semantics (limit/offset/next_offset) in prose, though the schema covers them, leaving a small gap for a list endpoint.

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 all three parameters (domain_id, limit, offset) are documented in the schema with patterns, bounds, and defaults. The description lists returned fields rather than parameter meaning, adding no syntax or format detail 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.

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

States a specific verb and resource ('List the records of one DNS domain') and enumerates the returned fields (name, type, content, TTL, priority). The 'one DNS domain' scoping clearly separates it from the sibling exoscale_list_dns_domains.

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?

Explicitly tells the agent to use exoscale_list_dns_domains to obtain the required domain_id, which resolves the main prerequisite for calling this tool. It stops short of stating when-not to use it or how it relates to other record-level operations, so it lands below full marks.

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=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context by disclosing the returned field set and the underlying REST call (GET /elastic-ip), which helps an agent understand what a call yields even absent an output 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?

Two compact sentences, front-loaded with the action and scope, with no filler. The trailing 'GET /elastic-ip' is mildly redundant for a listing tool but serves as a useful API mapping, so waste is minimal.

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?

With no output schema, the enumeration of returned fields is the most valuable thing this description could supply and it does so. It omits any mention of pagination or response ordering, which the schema partially covers via limit/offset, so it is nearly complete rather than fully complete.

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 zone, limit and offset are already fully documented in the schema; the 3 baseline applies. The phrase 'of a zone' reinforces the scoping role of the zone parameter but adds no syntax, defaults or format detail 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 states a specific verb (list) and resource (elastic IP addresses) scoped to a zone, and enumerates the fields returned (description, address family, health-check settings, labels). It is clearly distinct from exoscale_get_elastic_ip by virtue of listing versus fetching a single resource, though it never names that sibling explicitly.

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?

Usage is implied by 'list... of a zone' — an agent can infer this is the enumeration counterpart to exoscale_get_elastic_ip. However, there is no explicit statement of when to prefer this over the get variant, nor any prerequisite or exclusion guidance.

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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying GET /instance call and the returned field set, but says nothing about pagination looping (limit/next_offset) or rate limiting, so it only adds moderate context.

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 tight sentences: the scope/operation first, the returned fields second, the raw endpoint last. Every clause earns its place with no redundancy.

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 enumerating the returned fields in the description is genuinely necessary and it is done well. The only omission is restating the pagination/next_offset loop, which the schema already documents, so this is nearly complete.

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%, with limit, offset, ip_address and the zone enum all documented in the schema, so the baseline is 3. The description reinforces the zone scope ("of one zone") but adds no format or syntax detail beyond what the schema already provides.

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 verb (List) plus resource (compute instances), scopes it to one zone, and enumerates the fields returned (id, name, state, instance type, template, IP addresses, security groups). This clearly distinguishes it from the singular exoscale_get_instance and from other list_* siblings.

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?

"Call once per zone for a full inventory" gives concrete invocation guidance and implies the zone-by-zone pattern. It does not explicitly name the alternative (exoscale_get_instance for a single instance) or state exclusions, so it falls 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the HTTP endpoint (GET /instance-type) and the shape of the returned records, but says nothing about pagination behavior, result ordering, or completeness of the list.

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 verb and resource, then the returned fields, then the endpoint. Nearly every clause earns its place, though the trailing 'GET /instance-type' is marginal value for an agent that already knows the tool is a list operation.

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?

With no output schema, the description usefully enumerates the fields each instance type carries, which is exactly what the missing output schema would have provided. Combined with the annotations and the fully documented parameters, an agent has enough to call this correctly.

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 fully documents zone, limit and offset (including defaults and next_offset usage). The description adds no parameter semantics of its own, 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?

States a specific verb ('List') and resource ('compute instance types') and even enumerates the returned fields (family, size, CPUs, GPUs, memory, zones). This clearly separates it from the single-resource sibling exoscale_get_instance_type. It stops short of naming that sibling, so it is clear but not sibling-differentiating.

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?

There is no when-to-use or when-not-to-use guidance and no mention of the alternative exoscale_get_instance_type. Nothing tells the agent when listing is preferable to fetching a single type, or how zone filtering should factor in.

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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: the scope is the whole organization and each entry carries both usage and limit, plus the HTTP endpoint (GET /quota). It does not discuss pagination behavior beyond what the schema already documents.

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?

One compact sentence plus the endpoint, with the resource scope front-loaded. Nothing is wasted, though the trailing 'GET /quota' is redundant detail rather than actionable guidance.

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?

With no output schema, the description appropriately characterizes the return value (per-resource usage and limit, with examples), which is what the agent needs to interpret results. Only the distinction from exoscale_get_quota is left unaddressed.

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 both parameters (limit, offset) are fully documented in the schema, including defaults and the next_offset pattern. The description adds no parameter-level detail beyond that, so the 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 states a specific resource — the organization's resource quotas — and clarifies the return content: current usage and limit per resource, with examples. It is clear what the tool does, but it does not distinguish itself from the sibling 'exoscale_get_quota', which an agent could easily confuse it with.

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?

There is no guidance on when to use this tool versus the closely related exoscale_get_quota or exoscale_get_organization. The agent must infer that 'list' means all resources rather than one, which the description never states.

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 the safe read-only profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds value beyond that by disclosing the returned fields and the conditional behavior that rules appear only 'when the API includes them', plus the underlying GET endpoint.

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?

A single compact sentence that front-loads the verb and resource, then adds return-field detail and the endpoint. No padding, though the trailing 'GET /security-group' is marginally redundant.

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 read-only list tool with full schema coverage and no output schema, the description usefully compensates by naming the returned fields and the conditional rules behavior. Only the lack of explicit alternative routing keeps it short of full completeness.

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 zone, limit, offset and visibility are all documented in the schema. The description only echoes the zone scope and adds no format or paging detail beyond what the schema already provides, so 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?

States a specific verb (List) and resource (security groups), scopes it to a zone, and enumerates the fields returned (id, name, description, external sources/firewall rules). It is distinguishable from the get_security_group sibling by the list-vs-get verb, though it does not name that sibling explicitly.

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?

Usage is implied by the list semantics and the zone scoping, but there is no explicit when-to-use guidance and no mention of the alternative get_security_group tool for fetching a single group. Adequate but leaves routing to inference.

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 and destructiveHint=false, so the safety profile is covered. The description adds that results are scoped per zone and lists returned fields, but doesn't disclose pagination behavior (limit/offset semantics) or the API endpoint caveat that the API returns whole lists despite limit/offset parameters.

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?

Single efficient sentence that front-loads the verb/resource and then enumerates returned fields, followed by the endpoint. No wasted words; slightly dense but appropriate.

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 list tool with annotations covering safety and full schema coverage, the description is adequate. It lacks pagination guidance and the 'API returns whole lists' nuance that would help an agent call it correctly across pages. No output schema, so return-field enumeration is a plus but not a substitute for behavioral detail.

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 coverage is 100%, so the schema fully documents zone, limit, and offset including defaults and enum values. The description adds no parameter-specific detail beyond 'of a zone', so 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?

States a specific verb (List) and resource (SKS clusters) and enumerates the returned fields. It distinguishes from exoscale_get_sks_cluster by saying 'clusters' (plural list) but doesn't explicitly contrast the singular get sibling.

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?

Usage is implied by 'List the SKS clusters of a zone' — the zone parameter scopes the query. However, no explicit guidance on when to use this vs exoscale_get_sks_cluster or the other list_* tools, and no mention that it requires a zone context.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a useful behavioral hint that the public list is long and should be filtered or paged, but says nothing about auth requirements, rate limits, or what the paging cursor looks like. Given the annotated baseline, adding one relevant trait merits a 3.

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?

Three compact sentences with the resource and returned fields front-loaded, followed by the paging advice and the HTTP endpoint. Every sentence carries information, though the trailing 'GET /template' is marginal for an agent that already has structured parameters.

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?

With no output schema, the description usefully enumerates the returned fields, and the filter/paging guidance covers the main operational concern for a 5-param list call. Zone defaulting, limit bounds, and visibility semantics are left to the schema, which is acceptable since coverage there is complete. Nothing critical is missing for correct invocation.

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 all five parameters are already documented, including zone default, limit range/meaning, offset next_offset hint, family example, and visibility enum. The description only reiterates 'filter by family or page with limit/offset' without adding format or edge-case meaning beyond the schema. 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?

States a specific verb and resource ('List the compute templates (OS images) of a zone') and enumerates the fields returned (name, family, version, default user, size, visibility). It effectively distinguishes itself from the singular exoscale_get_template sibling by scoping to zone-level listing. It stops short of explicitly naming that sibling, which keeps it at 4 rather than 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?

Provides a concrete reason to use the filters ('The public list is long: filter by family or page with limit/offset'), which is genuine usage guidance. However, it never states when to prefer this over exoscale_get_template or other list tools, and offers no exclusions. Adequate but leaves alternative-selection to inference.

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 cover the safety profile (readOnlyHint=true, openWorldHint=true, destructiveHint=false). The description adds genuine value beyond them: the underlying API path (GET /zone), the fact that the response carries API and object-storage endpoints, and the domain fact that resources are pinned to exactly one zone.

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?

Three short sentences, front-loaded with what is listed, then what the response contains, then the API route. Every sentence earns its place and nothing is padded.

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 zero-parameter, read-only list tool with no output schema, the description covers the essentials: what is returned (zones with their endpoints) and the domain constraint that resources belong to one zone. Minor gaps such as pagination or ordering are not disclosed, but they are unlikely to matter for a small, fixed zone list.

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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The schema is empty and fully covered; no parameter semantics are missing.

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?

Specific verb+resource ('List the Exoscale zones') with a parenthetical gloss clarifying what a zone is, plus the exact payload contents (API and object-storage endpoints). It is trivially distinguishable from every sibling, which operate on instances, volumes, DNS, etc.

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?

No explicit when-to-use or when-not statement, but usage is strongly implied by the sentence 'Compute, storage and network resources live in one zone each,' which tells the agent zones are the geographic anchor for resource placement. There is no alternative zone-listing tool to route away from, so the omission is minor.

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 destructiveHint=true and idempotentHint=false, but the description goes further by spelling out the consequence ('running services restart and unsaved data in memory is lost') and the async operation model requiring polling via exoscale_get_operation. This adds real behavioral value beyond the structured hints.

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?

Four short clauses, front-loaded with the write semantics and risk, then the async pattern and endpoint. No sentence is padding.

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, and the description compensates precisely by stating that an operation is returned and how to poll it. Combined with the data-loss warning, an agent has everything needed to call and follow up on this tool correctly.

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 the id pattern and the zone default ('the zone chosen at login') are already fully documented in the schema. The description adds no parameter-level detail, so the 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 gives a specific verb (reboot) and resource (a running compute instance), and the 'running' qualifier distinguishes it from siblings like exoscale_start_instance and exoscale_stop_instance. It even names the HTTP endpoint, removing any ambiguity about the operation.

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 implies the instance must be running and directs the agent to poll the result with exoscale_get_operation, which is useful context. However, it never explicitly contrasts when to reboot versus stop/start, nor states prerequisites or exclusions, leaving the usage decision largely to inference.

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?

Goes well beyond the annotations (readOnly=false, idempotent=true, destructive=false) by disclosing that billing resumes, that the response is an operation needing polling via exoscale_get_operation, and the underlying PUT /instance/{id}:start call. These are exactly the side-effect and workflow details an agent needs before mutating.

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 'WRITE:' to signal mutation, then packs scope, cost implication, and the required follow-up call into a single tight block with no filler.

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?

No output schema exists, but the description explains the return value (an operation) and the exact next step (poll with exoscale_get_operation), covering the agent's full workflow. Nothing needed to call this correctly is 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 coverage is 100%, so both the id and zone parameters are already documented in the schema, and the description only echoes {id} in the REST path. No added meaning beyond the schema, which is the expected baseline.

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 verb (start) and resource (compute instance) and narrows the scope with 'stopped', 'normal boot, no rescue profile'. This clearly separates it from siblings exoscale_stop_instance and exoscale_reboot_instance without needing their schemas.

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?

The precondition 'stopped compute instance' tells the agent when the call is valid, and 'no rescue profile' excludes a variant. It does not explicitly name the alternatives (stop/reboot) or state what to do if the instance is already running, so guidance is clear but not fully closed.

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 destructiveHint=true and idempotentHint=false, and the description adds real consequence detail on top: running services go down and the public IP may change unless it is an elastic IP. It also discloses the asynchronous return (an operation to poll) and the underlying PUT endpoint, which is exactly the extra context annotations cannot carry.

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?

Three tight sentences, front-loaded with the write marker and the core action, followed by consequences and the follow-up call. No sentence is filler.

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?

With no output schema, the description correctly explains that the return is an operation and names the tool to poll it with, plus the destructive side effects. Nothing an agent needs to invoke and follow through on this call is 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% (id UUID and optional zone with default both documented in-schema), so the baseline is 3. The description adds no syntax or format information for the parameters beyond what the schema already provides.

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 verb (stop) and resource (compute instance) and prefixes the write nature with 'WRITE:', making the operation type immediately legible. An agent can distinguish it from exoscale_start_instance and exoscale_reboot_instance purely from the verb+resource.

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?

The description says what to do afterward ('poll it with exoscale_get_operation'), which is useful workflow guidance, but it never states when to stop vs reboot vs start, nor any preconditions (e.g. already-stopped instances). Usage is implied by the verb rather than explicitly framed.

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