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

With no annotations, the description carries the full burden of behavioral disclosure. It only mentions that zone defaults if not provided and that tags are optional. It does not disclose mutation side effects, idempotency, authentication requirements, or provisioning behavior, leaving significant gaps for a create operation.

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 description is exceptionally concise and well-structured: a single opening line followed by a bullet-style list of parameters with brief explanations. No words are wasted, and the most critical information (what the tool does) is front-loaded.

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?

The description adequately documents the parameters and notes the default zone behavior, but lacks broader context such as how to obtain an image_id, what instance types are valid, or what happens after creation. With an output schema present, return values are covered, but usage context and behavioral details are 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 description adds meaning beyond the bare schema by providing examples for instance_type and zone, explaining the zone default behavior, and noting tags are optional. While 'name' and 'image_id' descriptions are largely tautological, the overall coverage compensates for the 0% schema description coverage.

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 clearly states the verb+resource combo 'Create a new compute instance,' which unambiguously identifies the tool's function and distinguishes it from sibling tools like list_instances, delete_instance, and start_instance. The purpose is explicit and matches the tool name.

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 usage—when you want to create a new compute instance—but provides no explicit guidance on when to use this vs alternatives, no exclusions, and no prerequisites. It is a basic statement of intent rather than helpful contextual usage 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?

With no annotations, the description must disclose behavioral traits, but it only reveals the region default behavior ('If not provided, uses default region'). It does not mention permissions, side effects, idempotency, or error conditions, which is a significant gap for a mutating tool.

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 description is compact and well-organized with a clear one-line purpose followed by a concise Args list. Every line adds value—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?

For a simple create operation, the description covers the core purpose and all parameters. The output schema exists, so return values are not the description's responsibility. However, it omits any high-level context (e.g., relationship to instances or network isolation), leaving minor gaps.

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?

Despite 0% schema coverage, the description compensates by explaining each parameter: name, region with concrete examples, and tags as optional. The note about region defaulting adds behavioral meaning beyond the schema's bare type definitions.

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 uses a specific verb+resource pair ('Create a new private network') that clearly distinguishes it from sibling tools like list_private_networks or instance operations. No other tool in the sibling list creates a private network, so the purpose 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios such as 'when setting up a network for instances' or contrast with list_private_networks, leaving the agent to infer usage solely from the 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?

No annotations are provided, so the description must disclose behavioral traits, but it only says 'Delete an instance' and lists parameters. It does not mention permanence, irreversibility, or potential impact on associated resources, which are critical for a destructive operation.

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 description is brief and structured with an Args section, making it easy to scan. Each sentence earns its place and there is 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?

The description covers parameter meanings and the zone default, and an output schema exists so return values need no explanation. However, it misses important contextual details for a delete tool, such as irreversibility or failure scenarios, making it only partially 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 0%, but the description fully defines both parameters. instance_id is explained as 'The ID of the instance to delete', and zone provides an example ('fr-par-1') and explains default behavior ('If not provided, uses default zone'), adding value 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 explicitly states 'Delete an instance', a specific verb-resource pair that clearly identifies the tool's function. It distinguishes itself from sibling tools like get_instance, start_instance, and stop_instance by the unique delete action.

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 gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., instance should be stopped) or situations where deletion might be inappropriate. Usage is only implied by the verb 'delete'.

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?

No annotations are provided, so the description carries the transparency burden. It states the tool 'gets detailed information', which implies a read-only operation, but it does not disclose behaviors like error handling when the instance does not exist, or any authorization requirements. The output schema helps, but the description itself is minimal.

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 description is compact and front-loaded with the core purpose in the first sentence. The argument details are minimal and useful, avoiding unnecessary repetition of schema metadata. No fluff is present.

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-instance retrieval tool with an output schema, the description plus schema cover the essential semantics. The zone default behavior is clarified. It lacks some detail like potential not-found behavior, but overall it is sufficiently complete for a simple get 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?

The description explains both parameters beyond the schema: instance_id is identified as the ID of the instance to retrieve, and zone is described with a concrete example ('fr-par-1') and a note about defaulting. The schema itself has no descriptions for properties, so this added meaning is essential and well done.

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 starts with 'Get detailed information about a specific instance', using a specific verb ('Get') and resource ('instance'). It clearly distinguishes from sibling tools like list_instances, which lists all instances rather than retrieving one specific instance.

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 clearly implies this tool is for retrieving a single instance by ID, contrasting with list_instances which would list many. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.

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?

No annotations are provided, so the description must carry the transparency burden. It only says 'detailed information' without disclosing the read-only nature, potential error conditions, or any side effects, leaving significant gaps.

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 description is concise and front-loaded, using a standard Args structure with no filler or redundancy. Every sentence adds value.

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 getter, the description covers the essential parameters and default region behavior. The output schema exists to document return values, so that is not a gap. However, it lacks any mention of errors or prerequisites.

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 description clarifies 'cluster_id' and gives concrete examples and default behavior for 'region', which the schema leaves unspecified. This adds meaningful meaning beyond the bare field names.

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 clearly states a specific verb ('Get') and resource ('Kubernetes cluster'), narrowing to 'detailed information.' It naturally distinguishes from sibling 'list_k8s_clusters' by focusing on a single cluster.

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 context is clear: this tool retrieves a specific cluster by ID, and the region default is explained. However, it does not explicitly contrast with list_k8s_clusters or state 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?

Describes default zone behavior and arch filtering, which adds context beyond the tool name. However, with no annotations, it doesn't disclose whether the operation is read-only, any rate limits, or authentication requirements. The description carries the full burden for behavioral disclosure, but for a simple listing tool, the behavior is fairly 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?

The description is two sentences plus a succinct argument list. It is front-loaded with the main purpose and every line provides useful information without rambling.

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 the tool's simplicity (2 optional parameters) and presence of an output schema, the description adequately covers purpose and parameter behavior. It doesn't need to describe return values because the output schema exists, and no annotations are needed for a straightforward list 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?

The description fully explains both parameters, including the zone example and default behavior, and the architecture filter values and default. This compensates for the 0% schema description coverage, adding value beyond the schema's type/default only.

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?

Clearly states the tool lists available instance images, distinguishing it from sibling list_instances by naming the resource. Uses specific verb 'List' and resource 'instance images'.

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 parameter defaults and filtering options but does not explicitly state when to use this tool versus alternatives like list_instances or when not to use it. The intended use is implied by the name and description.

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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals that listing is scoped to a zone and the default zone behavior, and 'List' implies a read operation. However, it does not mention pagination, authentication, or other operational caveats.

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 description is brief and front-loaded: the first sentence captures the core purpose, followed by a clear args block. Every word contributes value without 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?

The tool has one optional parameter and an output schema, so return values do not need explanation. The description adequately covers the only parameter and scope, though a brief note about pagination or read-only semantics would make it 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?

The schema only defines zone as an optional string with a null default. The description adds real meaning by providing example zone values and stating that the default zone is used when omitted, which is essential for correct invocation.

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 clearly states 'List all compute instances in a Scaleway zone' with a specific verb, resource, and scope. It distinguishes itself from siblings like get_instance (single instance) and create_instance/delete_instance (mutations).

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 when to use it: to list all compute instances in a zone. It mentions the zone parameter and its default behavior, but does not explicitly contrast with alternatives like get_instance or state exclusions.

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?

No annotations are provided, so the description carries the burden of disclosing behavior. It discloses the default region behavior, which is useful, but it does not explicitly mention that the operation is read-only/safe, nor does it address pagination or authentication. The non-destructive nature is implied by 'List', but not stated.

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 description is extremely concise: a single functional sentence plus a one-line param explanation. It front-loads the purpose and wastes no words, making it easy to scan and understand.

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 the tool's simplicity (one optional parameter, output schema exists) and the presence of an output schema, the description covers the essential behavior. It could mention pagination or relationship to 'get_k8s_cluster', but these are not critical for a basic list operation. Overall, adequate for the 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?

The schema only declares 'region' as a string/null with a default, but the description adds meaning by giving example values ('fr-par', 'nl-ams') and explaining behavior when omitted. This compensates for the 0% schema description coverage and clarifies the parameter's purpose.

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 clearly states the operation ('List'), the resource ('Kubernetes clusters'), and the scope ('in a Scaleway region'). It distinguishes itself from sibling 'get_k8s_cluster' by indicating 'all' clusters rather than a single one.

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 usage by saying 'List all', but it does not explicitly name alternatives like 'get_k8s_cluster' for retrieving a single cluster. It provides helpful context about the region parameter (default behavior), but no exclusion or when-not-to-use 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?

No annotations, so the description must carry the behavioral burden. It states the tool lists private networks and the default region behavior, but fails to disclose read-only nature, pagination, or any expected response characteristics beyond existence of 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?

Extremely concise and front-loaded. The key action and scope are in the first sentence, and the parameter detail is compact and useful 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?

Given the tool's simplicity, presence of an output schema, and the parameter's explaination, the description is largely sufficient. It slightly misses explicit when-to-use context, but for a straightforward list operation it covers the essentials.

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 description adds meaningful semantics to the 'region' parameter with concrete examples (fr-par, nl-ams) and default behavior, compensating for the schema's 0% description coverage.

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?

Clearly states 'List all private networks in a Scaleway region' with a specific verb and resource. Unambiguously differentiates from sibling create_private_network and aligns with the tool name.

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 no guidance on when to use this tool versus alternatives. It does not mention that this is the read-only counterpart to create_private_network, nor any scenario-based advice.

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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the action without mentioning side effects (e.g., booting, potential errors if already running, permissions required, or asynchronous behavior). This is a significant gap for a state-changing operation.

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 description is concise and front-loaded with the purpose, followed by a compact, well-structured Args section. Every sentence contributes value without 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?

For a simple two-parameter tool with an output schema, the description covers the core purpose and parameters. However, it lacks behavioral context (prerequisites, error cases, execution behavior) that would be needed for a complete understanding, especially given the absence of annotations.

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?

Although schema description coverage is 0%, the description's Args section fully explains both parameters: instance_id is the ID to start, and zone is an optional Scaleway zone with a default. This adds clear meaning beyond the bare schema field names.

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 clearly states 'Start a stopped instance,' using a specific verb and resource. It distinguishes from sibling tools like stop_instance and create_instance by specifying the action and the target state (stopped).

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 provides clear context that the tool is for starting stopped instances, implying when to use it. However, it does not explicitly mention alternatives or exclusions (e.g., 'use create_instance for new instances'), 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?

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Stop a running instance' without covering side effects, reversibility, asynchronous nature, required permissions, or what happens if the instance is already stopped. This is a significant gap for a state-changing operation.

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 description is concise and well-structured: a single purpose sentence followed by a compact args list. No redundant information exists; every sentence serves a clear function, and it front-loads the main action.

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 tool with an output schema and only two parameters, the description covers the essential purpose and parameter semantics. It does not mention preconditions like 'instance must be running' or post-conditions, but these are not critical for invocation given the output schema exists. It is adequate but could add a note about idempotency or errors.

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 input schema has no property descriptions (0% coverage), but the description explicitly explains both parameters: instance_id as the ID of the instance to stop, and zone with an example and default behavior ('If not provided, uses default zone'). This fully compensates for the schema's lack of descriptions and adds practical guidance.

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 uses a clear verb ('Stop') and resource ('a running instance'), making it unambiguous. It is distinct from sibling tools like start_instance, delete_instance, get_instance, and list_instances, all of which serve different actions.

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 usage through the name and action, but there is no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference sibling tools like start_instance for the opposite operation.

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