mcp

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

The description adds valuable behavioral context beyond annotations: it specifies default values (machine_type defaults to 'e2-medium', image defaults to 'debian-12'), provides post-execution guidance ('Proceed only if there is no error in response and the status of the operation is `DONE`'), and references a related tool for operation details. While annotations already indicate this is a destructive operation (destructiveHint: true), the description provides practical implementation details that aren't captured in 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?

The description is appropriately sized and front-loaded with the core purpose. Each sentence adds value: the first states what it does, the second covers required inputs and defaults, the third mentions optional parameters, and the fourth provides execution guidance and references to other tools. There's minimal redundancy, though it could be slightly more streamlined.

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 complexity (destructive creation operation with 8 parameters), the description provides excellent contextual completeness. It covers purpose, required inputs, default behaviors, optional parameters, execution conditions, and references to related tools. With both comprehensive annotations (including destructiveHint: true) and an output schema present, the description appropriately focuses on practical usage guidance rather than repeating structured information.

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?

With 100% schema description coverage, the schema already documents all 8 parameters thoroughly. The description adds some semantic context by explaining default behaviors for machine_type, image_project, and image_family, but doesn't provide additional meaning beyond what's in the well-documented schema. This meets the baseline expectation when schema coverage is complete.

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 specific action ('Create a new Google Compute Engine virtual machine (VM) instance') and distinguishes it from sibling tools like 'delete_instance', 'list_instances', or 'reset_instance'. It specifies the exact resource being created (VM instance) with no 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?

The description provides explicit guidance on when to use this tool versus alternatives: it mentions 'To get details of the operation, use the `get_zone_operation` tool' and implicitly distinguishes from read-only siblings like 'get_instance_basic_info' by being a creation tool. It also specifies prerequisites ('Requires project, zone, and instance name as input').

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 indicate destructiveHint=true, which aligns with the 'Delete' action. The description adds valuable context beyond annotations by specifying prerequisites ('Requires project, zone, and instance name as input'), success conditions ('no error in response', 'status DONE'), and a follow-up action recommendation ('use the get_zone_operation tool'). It does not contradict annotations, as destructiveHint=true matches the described deletion 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?

The description is front-loaded with the core purpose, followed by essential usage instructions and a tool alternative. Every sentence serves a clear purpose: the first defines the action and inputs, the second provides critical behavioral guidance, and the third offers a related tool reference. There is no wasted text, making it highly efficient and well-structured.

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 complexity (destructive operation with three required parameters) and the presence of annotations (destructiveHint=true) and an output schema (implied by context signals), the description is complete. It covers purpose, inputs, success criteria, and a follow-up action, addressing key agent needs without needing to detail return values (handled by output schema) or repeat annotation info.

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 all three parameters (project, zone, name) well-documented in the schema. The description mentions these parameters but does not add significant semantic details beyond what the schema provides (e.g., it doesn't explain format constraints or examples). Given the high schema coverage, a baseline score of 3 is appropriate as the description adds minimal extra parameter insight.

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 specific action ('Delete') and resource ('Google Compute Engine virtual machine (VM) instance'), distinguishing it from sibling tools like 'reset_instance', 'start_instance', or 'stop_instance' which perform different operations on the same resource type. It precisely identifies what the tool does without being vague or tautological.

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 explicit guidance on when to use this tool: 'Proceed only if there is no error in response and the status of the operation is `DONE` without any errors.' It also names an alternative tool ('get_zone_operation') for follow-up details, clearly differentiating usage contexts from other siblings like 'list_instances' or 'get_instance_basic_info'.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the exact information returned (name, ID, status, plan, type, resources, timestamps) and noting the required inputs, which provides useful context beyond annotations. No contradictions with annotations are present.

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 efficiently structured in two sentences: the first states the purpose and details returned, and the second specifies required inputs. Every sentence adds essential information with no wasted words, making it easy to parse and understand quickly.

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 complexity (a read-only, idempotent retrieval with 3 parameters), the description is complete. It covers purpose, returned fields, and required inputs. With annotations providing safety and behavioral hints, and an output schema existing (though not shown), the description adequately supplements structured data without redundancy.

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 each parameter (project, region, name) well-documented in the schema. The description mentions these parameters as required inputs but does not add significant meaning beyond what the schema already provides, such as format examples or usage nuances. Baseline 3 is appropriate given high schema 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 specific action ('Get basic information') and resource ('Compute Engine Commitment'), listing the exact fields returned (name, ID, status, etc.). It distinguishes itself from sibling tools like 'list_commitments' by focusing on retrieving detailed information for a single commitment rather than listing multiple commitments.

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 explicitly states when to use this tool: to get basic information about a specific Compute Engine Commitment. It mentions the required inputs (project, region, commitment name), which implies usage context. However, it does not explicitly state when NOT to use it or name alternatives like 'list_commitments' for broader queries.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds no behavioral traits beyond these annotations, such as rate limits, authentication needs, or error conditions. However, it doesn't contradict the annotations, so it meets the baseline for when annotations are comprehensive.

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 front-loaded with the core purpose in the first sentence, followed by essential input requirements. Both sentences are necessary and efficient, with no redundant or vague language, making it easy to parse quickly.

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 low complexity (a simple read operation), comprehensive annotations (covering safety and idempotency), 100% schema coverage, and the presence of an output schema (which handles return values), the description is complete enough. It clearly states what the tool does and its input requirements, leaving no critical gaps for the agent.

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 clear descriptions for each parameter (e.g., 'Required. Identifier. The disk name.'). The description mentions the required parameters but adds no semantic details beyond what the schema already provides, such as format examples or contextual usage. With high schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the specific action ('Get basic information') and resource ('Compute Engine disk'), and lists the specific data fields returned (name, ID, description, etc.). It distinguishes itself from sibling tools like 'list_disks' (which lists multiple disks) and 'get_disk_performance_config' (which focuses on performance metrics).

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 explicitly states when to use this tool ('Requires project, zone, and disk name as input'), which implies it's for retrieving information about a specific, known disk. However, it doesn't explicitly contrast when NOT to use it (e.g., vs. 'list_disks' for browsing or 'get_disk_performance_config' for performance data), though the specificity of required inputs provides strong implicit 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds context about required inputs (project, zone, disk name) but does not disclose additional behavioral traits like rate limits, authentication needs, or error conditions beyond what annotations imply.

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 efficiently structured in two sentences: the first specifies the tool's purpose and returned attributes, and the second states the required inputs. Every sentence adds value with no redundant information, making it front-loaded and easy to parse.

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 low complexity (3 simple parameters), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return values), the description is complete enough. It clearly defines the tool's scope and requirements without needing to explain behavioral details already covered by structured data.

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 clear documentation for all three parameters (name, zone, project). The description mentions these parameters as required but does not add meaning beyond what the schema already provides, such as format examples or contextual usage details.

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 specific action ('Get performance configuration') and resource ('Compute Engine disk'), listing the exact attributes returned (type, size, provisioned IOPS, etc.). It distinguishes itself from sibling 'get_disk_basic_info' by focusing on performance metrics rather than basic information.

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 explicitly states when to use this tool ('Get performance configuration of a Compute Engine disk') and mentions required inputs, but does not provide guidance on when not to use it or name specific alternatives among siblings (e.g., 'get_disk_basic_info' for non-performance data).

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 provide key behavioral hints (readOnlyHint: true, idempotentHint: true, destructiveHint: false), indicating safe, non-destructive operations. The description adds value by specifying the required inputs and the scope of information returned (e.g., 'basic information' including specific attributes like guest accelerators), which goes beyond the annotations. It does not mention rate limits or auth needs, but with annotations covering safety, this is acceptable.

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 front-loaded with the core purpose in the first sentence, followed by essential usage details in the second sentence. It is concise, with no wasted words, and every sentence provides necessary information (what the tool does and what inputs it needs), making it highly efficient.

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 moderate complexity, rich annotations (covering safety and idempotency), 100% schema coverage, and the presence of an output schema (which handles return values), the description is complete enough. It clearly defines the tool's purpose, required inputs, and scope of returned data, leaving no critical gaps for an AI agent to understand and invoke it 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?

The schema description coverage is 100%, with each parameter (project, zone, name) well-documented in the schema. The description mentions these parameters as required but does not add significant semantic details beyond what the schema provides (e.g., format examples or constraints). This meets the baseline score of 3 for high schema 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 action ('Get basic information') and the specific resource ('Compute Engine VM instance'), listing key attributes like name, ID, status, machine type, creation timestamp, and attached guest accelerators. It effectively distinguishes this tool from sibling tools like 'list_instances' (which lists multiple instances) or 'get_instance_template_basic_info' (which targets templates), making the purpose specific and well-defined.

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 explicitly states when to use this tool by specifying the required inputs (project, zone, and instance name), implying it's for retrieving details of a specific instance. However, it does not provide explicit guidance on when not to use it or name alternatives (e.g., 'list_instances' for multiple instances), which prevents a perfect score.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds no behavioral traits beyond this, such as rate limits, authentication needs, or error conditions. It does not contradict annotations, but offers minimal additional 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?

The description is appropriately sized with two sentences: the first states purpose and details, the second specifies input requirements. It is front-loaded with key information and avoids redundancy, though it could be slightly more streamlined by integrating the input note into the first sentence.

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 (3 required parameters, 100% schema coverage, annotations covering safety, and an output schema exists), the description is complete enough. It clearly states what it does and the required inputs, and with annotations and output schema handling behavioral and return details, no further explanation is needed.

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 all three parameters (project, zone, name) well-documented in the schema. The description mentions these parameters but adds no meaning beyond what the schema provides, such as format examples or usage nuances. Baseline 3 is appropriate given high schema 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 'Get' and the resource 'Compute Engine managed instance group (MIG)', specifying it retrieves 'basic information' including enumerated fields like name, ID, instance template, etc. It distinguishes from siblings like 'list_instance_group_managers' (which lists multiple MIGs) and 'get_instance_basic_info' (which targets instances, not MIGs), providing specific 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?

The description explicitly states 'Requires project, zone, and MIG name as input', providing clear context for when to use it (i.e., when you have these identifiers). However, it does not mention when not to use it or explicitly name alternatives like 'list_instance_group_managers' for broader queries, missing full sibling differentiation.

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 indicate read-only, non-destructive, and idempotent behavior, but the description adds value by specifying the required inputs (project and instance template name) and listing the types of information returned. It does not contradict annotations and provides useful context beyond them, though it lacks details like rate limits or auth needs.

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 front-loaded with the core purpose, followed by input requirements, all in two concise sentences with no wasted words. Every sentence directly contributes to understanding the tool's function and usage.

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 low complexity (2 parameters), high schema coverage (100%), rich annotations (read-only, idempotent, etc.), and presence of an output schema, the description is complete enough. It covers the purpose, key returned attributes, and input requirements, aligning well with the structured data without redundancy.

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 clear documentation for both parameters (name and project). The description mentions these parameters but does not add significant meaning beyond what the schema provides, such as format examples or usage tips. Baseline 3 is appropriate as the schema handles most of the parameter documentation.

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 specific action ('Get basic information') and resource ('Compute Engine instance template'), listing key attributes like name, ID, description, machine type, region, and creation timestamp. It distinguishes from siblings like 'get_instance_template_properties' by focusing on basic info rather than detailed properties.

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 explicitly states when to use this tool ('Requires project and instance template name as input'), providing clear context for its application. However, it does not specify when not to use it or name alternatives (e.g., 'list_instance_templates' for listing multiple templates), missing explicit exclusions or comparisons.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds value by specifying it 'Requires project and instance template name as input', which clarifies authentication/access needs beyond annotations. No contradiction with annotations.

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

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

The description is efficiently structured in two sentences: first states purpose with specific examples, second states requirements. Every word adds value with zero redundancy, making it easy to parse and front-loaded with key 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?

Given annotations cover safety profile (read-only, non-destructive), schema fully documents parameters, and output schema exists (implied by context signals), the description provides complete contextual information. It specifies what properties are retrieved and input requirements, which is sufficient for this tool's complexity.

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 both parameters well-documented in the schema. The description mentions 'Requires project and instance template name as input' but doesn't add meaningful semantic context beyond what the schema already provides. Baseline 3 is appropriate given high schema 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 'Get' and resource 'instance properties of a Compute Engine instance template', with a comprehensive list of specific property types included. It distinguishes from sibling tools like 'get_instance_template_basic_info' by specifying it retrieves detailed properties rather than basic info.

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 explicitly states 'Requires project and instance template name as input', providing clear prerequisites. However, it doesn't specify when to use this tool versus alternatives like 'get_instance_template_basic_info' or 'list_instance_templates', missing explicit sibling differentiation.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds useful context about required inputs ('Requires project, zone, and reservation name as input'), which complements the annotations. It doesn't contradict annotations and adds some operational context, but doesn't provide rich behavioral details beyond what annotations cover.

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 efficiently structured in two sentences: the first states purpose and scope, the second specifies required inputs. Every word serves a purpose with zero waste, and information is front-loaded appropriately.

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 that annotations comprehensively cover safety/behavioral aspects (read-only, non-destructive, idempotent), schema coverage is 100%, and an output schema exists, the description provides complete contextual information. It clearly states what the tool does, what information it returns, and what inputs are required, making it fully adequate for this tool's complexity level.

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 all three parameters (project, zone, name) well-documented in the schema. The description mentions these parameters but doesn't add significant semantic meaning beyond what the schema already provides. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Get'), resource ('Compute Engine reservation'), and scope ('basic info') with explicit listing of included fields (name, ID, creation timestamp, etc.). It effectively distinguishes this tool from sibling 'get_reservation_details' by specifying it provides 'basic info' rather than comprehensive details.

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 about when to use this tool ('Get Compute Engine reservation basic info') and implicitly distinguishes it from 'get_reservation_details' by specifying the scope. However, it doesn't explicitly state when NOT to use it or mention specific alternatives beyond the sibling tool distinction.

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, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by listing the specific types of details returned (e.g., machine type, guest accelerators, sharing settings), which provides context beyond annotations, though it does not mention rate limits or auth needs.

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 front-loaded with the core purpose, followed by a detailed list of returned details and input requirements in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized and structured.

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 complexity (detailed retrieval with 3 parameters), rich annotations (read-only, idempotent), and the presence of an output schema, the description is complete. It covers purpose, returned details, and input requirements, leaving output specifics to the schema, which is sufficient for agent understanding.

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 all parameters (project, zone, name) well-documented in the schema. The description mentions these parameters as required but does not add significant meaning beyond what the schema provides, such as format examples or constraints, aligning with the baseline for high schema 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 'Get' and resource 'Compute Engine reservation details', specifying it returns comprehensive details including name, ID, status, properties, commitments, and settings. It distinguishes from siblings like 'get_reservation_basic_info' by emphasizing detailed properties rather than basic information.

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 explicitly states 'Requires project, zone, and reservation name as input', providing clear prerequisites for usage. However, it does not specify when to use this tool versus alternatives like 'get_reservation_basic_info' or 'list_reservations', missing explicit sibling differentiation.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the scope ('zone operation') and listing the returned details (id, name, status, etc.), which helps the agent understand what information to expect. It doesn't contradict annotations, and the added context is useful beyond the structured data.

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: the first states the purpose and details returned, the second specifies required inputs. It's front-loaded with key information, has zero waste, and is appropriately sized for a simple retrieval tool. Every sentence earns its place by adding 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?

Given the tool's low complexity (a read-only, idempotent retrieval with 3 parameters), high schema coverage (100%), rich annotations, and presence of an output schema, the description is complete enough. It covers purpose, inputs, and returned details, aligning well with the structured data without needing to explain return values or behavioral traits extensively.

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 clear descriptions for all three parameters (name, zone, project). The description mentions these parameters ('Requires project, zone, and operation name as input') but doesn't add semantic details beyond what the schema provides (e.g., format examples or relationships). Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Get details of a zone operation' with specific attributes listed (id, name, status, etc.). It distinguishes from siblings by focusing on zone operations rather than instances, disks, or other resources. However, it doesn't explicitly contrast with potential similar tools like 'get_operation' (if existed), so it's not a perfect 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 implies usage by specifying required inputs (project, zone, operation name) and context (zone operation details). It doesn't provide explicit when-to-use guidance versus alternatives (e.g., when to use this over general operation tools or other get_* tools), nor does it mention prerequisites beyond the inputs. This leaves some ambiguity for the agent.

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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying required inputs (project and zone) and detailing the return format (including id, creation timestamp, etc.), which provides useful context beyond annotations.

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

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

The description is front-loaded with the core purpose, followed by input requirements and return details in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized and well-structured for quick comprehension.

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 low complexity (simple list operation), rich annotations (covering safety and idempotency), 100% schema coverage, and the presence of an output schema (implied by 'Has output schema: true'), the description is complete. It adequately explains purpose, inputs, and return format without needing to detail output values explicitly.

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 clear descriptions for both required parameters (project and zone). The description mentions these parameters but does not add significant meaning beyond what the schema provides, such as format examples or usage tips. Baseline 3 is appropriate given high schema 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 ('Lists') and resource ('available Google Compute Engine accelerator types'), distinguishing it from sibling tools like list_machine_types or list_instances by specifying the exact resource type. It provides specific scope details about what is being listed.

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 context by stating 'Requires project and zone as input', but does not explicitly guide when to use this tool versus alternatives like list_machine_types or list_instances. No exclusions or specific scenarios are mentioned, leaving usage context partially inferred.

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, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations by detailing the return content (e.g., 'reservation details including name, ID, status...') and specifying input requirements ('Requires project, region, and commitment name as input'), which helps the agent understand scope and data structure. No contradiction with annotations.

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

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

The description is efficiently structured in two sentences: the first states the purpose and return details, and the second specifies input requirements. Every sentence adds essential information without redundancy, making it front-loaded and appropriately sized for the tool's complexity.

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 complexity (list operation with specific input), rich annotations (readOnlyHint, idempotentHint), 100% schema coverage, and presence of an output schema, the description is complete enough. It covers purpose, return details, and input requirements, providing sufficient context for an agent to use the tool correctly without needing to explain return values (handled by output schema).

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

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

Schema description coverage is 100%, with each parameter (project, region, name) well-documented in the schema. The description mentions these parameters ('Requires project, region, and commitment name as input') but does not add significant meaning beyond what the schema provides, such as format examples or usage nuances. Baseline score of 3 is appropriate as the schema handles parameter documentation effectively.

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 specific action ('Lists reservations for a Compute Engine Commitment') and resource ('reservations for a Compute Engine Commitment'), distinguishing it from sibling tools like 'list_reservations' (general reservations) and 'get_commitment_basic_info' (basic commitment info). It provides precise scope by specifying it returns reservation details for a specific commitment.

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 implicitly provides context by specifying it requires 'project, region, and commitment name as input,' which helps differentiate it from tools like 'list_reservations' (likely broader) and 'get_reservation_basic_info' (likely single reservation). However, it does not explicitly state when to use this tool versus alternatives like 'list_reservations' or 'get_reservation_details,' missing explicit guidance on exclusions or comparisons.

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 key behavioral traits (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false), so the description's burden is lower. It adds value by specifying the details included in the output (e.g., name, ID, status) and the required inputs, but does not disclose additional aspects like rate limits, pagination behavior (implied by pageSize/pageToken but not explained), or authentication needs beyond what 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?

The description is appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose, output details, and input requirements without unnecessary elaboration. Every sentence adds value, and there is no redundant or verbose content.

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 moderate complexity (list operation with pagination), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return values), the description is largely complete. It specifies the resource type, scope, output details, and required inputs. However, it could improve by briefly mentioning pagination behavior or when to use versus siblings, slightly reducing 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%, with all parameters well-documented in the input schema (e.g., project as 'Project ID for this request,' region as 'The region of the commitments'). The description adds minimal semantics beyond this by mentioning 'Requires project and region as input,' but does not elaborate on parameter usage or constraints, aligning with the baseline score when schema coverage is high.

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 specific action ('Lists Compute Engine Commitments in a region') and resource ('Compute Engine Commitments'), distinguishing it from siblings like 'list_commitment_reservations' or 'list_instances' by focusing on commitments rather than other resource types. It explicitly mentions the scope ('in a region') and details included, making the purpose 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 clear context by specifying 'Requires project and region as input,' indicating prerequisites for use. However, it does not explicitly state when to use this tool versus alternatives like 'get_commitment_basic_info' (for single commitments) or 'list_commitment_reservations' (for related resources), leaving some ambiguity in sibling differentiation.

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 indicate read-only, non-destructive, and idempotent behavior. The description adds value by specifying the detailed fields returned (e.g., name, ID, status) and the pagination context implied by 'pageSize' and 'pageToken' in the schema, enhancing transparency beyond annotations without contradiction.

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

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

The description is front-loaded with the core purpose, followed by details and requirements in two concise sentences. Every sentence contributes essential information without waste, making it efficient and well-structured for quick understanding.

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 (list operation), rich annotations (read-only, idempotent), full schema coverage, and presence of an output schema, the description is complete. It covers purpose, returned details, and input requirements, leaving no gaps for the agent to invoke it 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 all parameters. The description mentions 'Requires project and zone as input', which aligns with the schema but adds no extra semantic details. Baseline score of 3 is appropriate as the schema handles parameter documentation effectively.

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 specific action ('Lists Compute Engine disks') and resource ('disks'), distinguishing it from siblings like 'list_instances' or 'list_snapshots'. It provides concrete details about what information is included for each disk, making the purpose unambiguous and differentiated.

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 stating 'Requires project and zone as input', which suggests when to use it (when you have those parameters). However, it does not explicitly mention when not to use it or name alternatives like 'get_disk_basic_info' for single-disk details, leaving guidance incomplete.

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 provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds that it 'Lists Compute Engine Images' and includes details about returned fields, which provides useful context beyond annotations, but doesn't mention pagination behavior 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?

Two sentences with zero waste - first sentence states purpose and return details, second states the required input. Perfectly front-loaded and appropriately sized for this tool's complexity.

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 that annotations cover safety profile (read-only, non-destructive, idempotent), schema fully documents parameters, and an output schema exists, the description provides adequate context. It could benefit from mentioning pagination behavior given the pageSize/pageToken parameters, but overall it's reasonably complete for a 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?

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description mentions 'Requires project as input' which reinforces the required parameter but adds no additional semantic meaning beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the verb ('Lists') and resource ('Compute Engine Images') with specific details about what information is returned. It distinguishes from siblings like 'list_instances' or 'list_disks' by specifying the resource type, though it doesn't explicitly contrast with other list_* tools.

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 mentions 'Requires project as input' which is a basic prerequisite, but provides no guidance on when to use this tool versus alternatives like 'get_disk_basic_info' or other list_* tools. There's no explicit when/when-not usage context or sibling tool comparisons.

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 provide key behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true), so the description's burden is lower. It adds useful context by detailing the extensive response fields (e.g., kind, type, mode, source), which helps the agent understand the output richness beyond just listing disks. However, it does not mention rate limits, authentication needs, or pagination 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?

The description is appropriately sized and front-loaded, starting with the core purpose and following with response details and input requirements. However, the long list of response fields could be slightly condensed (e.g., using 'such as' with key examples), and the double comma ('licenses,, interface') is a minor structural flaw.

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 complexity (list operation with detailed output), rich annotations (read-only, non-destructive, idempotent), 100% schema coverage, and the presence of an output schema, the description is complete enough. It effectively communicates the tool's purpose, scope, and output richness without needing to explain return values or safety aspects already covered by structured data.

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 clear descriptions for all three parameters (project, zone, name). The description adds minimal value by restating that these are required inputs, but does not provide additional semantic context (e.g., format examples, relationship between parameters) beyond what the schema already documents.

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 specific action ('Lists the disks attached to') and resource ('Compute Engine virtual machine (VM) instance'), distinguishing it from sibling tools like 'list_disks' (which lists all disks) or 'get_instance_basic_info' (which provides general instance details). It precisely defines the scope as attached disks for a 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 implies usage by specifying required inputs (project, zone, instance name) and the resource type (VM instance), but it does not explicitly state when to use this tool versus alternatives like 'list_disks' or 'get_instance_basic_info'. No exclusions or comparative guidance are 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds context about required inputs (project and zone) and details the returned fields, which is useful but not extensive behavioral disclosure. No contradiction with annotations.

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

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

The description is appropriately sized with two sentences: one listing the action and details returned, and another stating input requirements. It is front-loaded with the core purpose, but could be slightly more concise by integrating the input requirement into the first sentence.

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 complexity (list operation with pagination), rich annotations, and existence of an output schema, the description is mostly complete. It covers the purpose, returned details, and input requirements, though it lacks explicit guidance on pagination usage (pageSize and pageToken), which is a minor gap.

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 all parameters. The description mentions that project and zone are required, which is already in the schema, but does not add significant meaning beyond it. Baseline score of 3 is appropriate as the schema handles parameter documentation.

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 ('Lists') and resource ('Compute Engine managed instance groups (MIGs)'), and distinguishes from siblings like 'list_instances' or 'list_managed_instances' by specifying it's for instance group managers, not individual instances. It also details the specific information returned for each MIG.

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 stating it 'Requires project and zone as input,' which provides some context, but does not explicitly say when to use this tool versus alternatives like 'get_instance_group_manager_basic_info' (for a single MIG) or other list tools. No exclusions or clear alternatives are mentioned.

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 provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies the scope of returned details (name, ID, status, etc.), mentions pagination parameters (pageSize, pageToken) implicitly through the input schema context, and states the requirement for project and zone inputs. No contradiction with annotations exists.

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 efficiently structured in three sentences: first states purpose and scope, second provides usage guidance, third specifies input requirements. Every sentence adds value without redundancy, and it is front-loaded with the core functionality.

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 complexity (list operation with pagination), rich annotations (readOnly, idempotent, non-destructive), and the presence of an output schema, the description is complete. It covers purpose, differentiation from siblings, input requirements, and scope of returned data, leaving output details to the schema. No gaps are evident for effective tool selection and 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%, with all parameters well-documented in the schema. The description adds minimal parameter semantics beyond the schema, only mentioning that project and zone are required inputs. It does not provide additional context about parameter usage or relationships, so it meets the baseline of 3 for high schema 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 specific action ('Lists'), resource ('Compute Engine virtual machine (VM) instances'), and scope ('Details for each instance include name, ID, status, machine type, creation timestamp, and attached guest accelerators'). It explicitly distinguishes from siblings by stating 'Use other tools to get more details about each instance', which differentiates it from tools like get_instance_basic_info.

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 explicit guidance on when to use this tool vs alternatives: 'Use other tools to get more details about each instance' directs users to sibling tools for detailed information. It also specifies prerequisites: 'Requires project and zone as input', which helps the agent understand when this tool is applicable.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the details included in the output (name, ID, description, etc.) and the project requirement, which are not covered by annotations. It does not contradict annotations, as 'Lists' aligns with read-only 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?

The description is front-loaded with the core purpose in the first sentence, followed by additional details in a second sentence. Both sentences are necessary and efficient, with zero waste or redundancy, making it appropriately sized and well-structured.

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 low complexity (a list operation), rich annotations (covering safety and idempotency), 100% schema coverage, and the presence of an output schema (which handles return values), the description is complete enough. It provides purpose, output details, and input requirement, addressing all necessary contextual elements without over-explaining.

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 clear descriptions for all parameters (project, pageSize, pageToken). The description mentions 'Requires project as input,' which reinforces the required parameter but does not add significant meaning beyond the schema. Baseline score of 3 is appropriate as the schema adequately documents parameters.

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 specific verb ('Lists') and resource ('Compute Engine instance templates'), and distinguishes it from siblings by specifying the scope of details included (name, ID, description, machine type, region, creation timestamp). It explicitly differentiates from tools like 'get_instance_template_basic_info' which retrieves a single template.

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 stating 'Requires project as input,' which provides basic context for when to use this tool. However, it does not explicitly guide when to choose this tool over alternatives like 'get_instance_template_basic_info' (for single template details) or other list tools (e.g., 'list_instances'), nor does it mention exclusions or prerequisites beyond the project requirement.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds value by specifying the required inputs (project and zone) and detailing the return content (machine types with specific attributes like id, memory, accelerators, etc.), which goes beyond the annotations. No contradiction with annotations.

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

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

The description is appropriately sized with two sentences: one stating the purpose and requirements, and another detailing the return values. It's front-loaded with the core functionality, though the second sentence is a long list that could be slightly more structured.

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 complexity (simple list operation), rich annotations (readOnly, idempotent, etc.), 100% schema coverage, and presence of an output schema, the description is complete. It covers purpose, requirements, and return details, providing sufficient context without redundancy.

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 both parameters (project and zone) well-documented in the schema. The description mentions 'Requires project and zone as input' but doesn't add significant meaning beyond what the schema already provides, such as format examples or usage context. Baseline 3 is appropriate given high schema 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 specific action ('Lists') and resource ('available Google Compute Engine machine types'), distinguishing it from siblings like list_instances or list_accelerator_types. It provides a comprehensive scope of what's being listed.

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 explicitly states 'Requires project and zone as input' and implies usage for retrieving machine type details, but doesn't specify when to use this versus alternatives like list_instances or get_instance_basic_info. It provides clear context but lacks explicit comparison to sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the details returned (id, instance URL, instance status, and current action) and the required inputs, but does not disclose additional behavioral traits like rate limits, pagination behavior (implied by pageSize/pageToken but not explained), or authentication needs beyond what 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?

The description is two sentences, front-loaded with the core purpose and followed by details on returns and requirements. Every sentence earns its place by adding essential information without redundancy, making it appropriately sized and efficient.

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 complexity (list operation with pagination), rich annotations (covering read-only, idempotent, non-destructive), and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, required inputs, and return details, but could improve by briefly noting pagination behavior or sibling tool context, though not strictly necessary for adequacy.

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 all 5 parameters (project, zone, name, pageSize, pageToken) with clear descriptions. The description mentions the required parameters (project, zone, name) but does not add meaning beyond what the schema provides, such as explaining pagination usage or parameter relationships. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('Lists managed instances') and resource ('for a given managed instance group (MIG)'), distinguishing it from generic list tools like 'list_instances' or 'list_instance_group_managers' by specifying it's about instances within a MIG. It also mentions the detailed fields returned (id, URL, status, current action), making the purpose highly specific.

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 explicitly states when to use this tool ('Lists managed instances for a given managed instance group (MIG)') and provides prerequisites ('Requires project, zone, and MIG name as input'), giving clear context. However, it does not explicitly mention when not to use it or name alternatives (e.g., 'list_instances' for all instances vs. MIG-specific ones), which prevents a perfect score.

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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds that it 'Lists Compute Engine reservations' and mentions pagination parameters (pageSize, pageToken) which are in the schema, but doesn't provide additional behavioral context like rate limits, authentication needs, or what 'specific reservation required' means operationally.

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 appropriately sized with two sentences: the first states purpose and output details, the second states input requirements. It's front-loaded with the core functionality. However, the list of details could be slightly verbose, and there's some redundancy with schema 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?

Given that annotations cover safety/idempotency, schema coverage is 100%, and there's an output schema (though not shown), the description provides adequate context. It specifies the resource type, output details, and input requirements. The main gap is lack of differentiation from sibling tools, but otherwise it's reasonably complete for a listing operation.

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

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

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description mentions 'Requires project and zone as input' which restates what's in the schema, and lists details included in output but doesn't add meaningful parameter semantics beyond what the schema already provides. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the verb ('Lists') and resource ('Compute Engine reservations'), and specifies the scope of details included (name, ID, creation timestamp, etc.). However, it doesn't explicitly differentiate from sibling tools like 'list_commitment_reservations' or 'get_reservation_basic_info', which reduces clarity about when to choose this specific listing tool.

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

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

The description mentions 'Requires project and zone as input' which is a prerequisite, but provides no guidance on when to use this tool versus alternatives like 'list_commitment_reservations' or 'get_reservation_basic_info'. There's no explicit when/when-not usage context or comparison with sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds useful context beyond this by specifying the exact fields returned (name, id, status, etc.) and noting the project requirement, which helps the agent understand output format and prerequisites. No contradictions with annotations exist.

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

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

The description is efficiently structured in two sentences: the first states the purpose and output fields, and the second specifies the required input. Every sentence adds essential information without redundancy, making it front-loaded and easy to parse for an AI 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?

Given the tool's low complexity (a read-only list operation), rich annotations (covering safety and idempotency), 100% schema coverage, and the presence of an output schema (which handles return values), the description is complete. It adequately explains what the tool does, what it returns, and key inputs, leaving no significant gaps for the agent.

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 clear documentation for all three parameters (project, pageSize, pageToken). The description adds minimal value beyond the schema by mentioning 'Requires project as input', which reinforces the required parameter but doesn't provide additional syntax or format details. Baseline 3 is appropriate given the comprehensive 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 clearly states the specific action ('Lists snapshots') and resource ('in a project'), while distinguishing itself from siblings by specifying it provides 'basic information per snapshot' rather than detailed or filtered data. It explicitly lists the fields included (name, id, status, etc.), making the scope 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 implies usage context by stating it 'Requires project as input' and provides basic snapshot info, but it doesn't explicitly guide when to use this tool versus alternatives like list_disks or list_images. No exclusions or specific scenarios are mentioned, leaving usage decisions to inference from the tool name and data fields.

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 indicate this is a destructive operation (destructiveHint: true) and not read-only/idempotent. The description adds valuable behavioral context beyond annotations by specifying: 1) The need to check operation status ('Proceed only if there is no error in response and the status of the operation is DONE without any errors'), and 2) How to monitor the operation ('use the get_zone_operation tool'). This provides practical guidance that annotations alone don't convey.

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

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

The description is efficiently structured in three sentences that each serve distinct purposes: 1) States the core function, 2) Specifies required inputs, 3) Provides operational guidance. There's no redundancy or wasted words, and critical information appears first. The length is appropriate for a destructive operation that requires careful handling.

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 that this is a destructive operation with annotations covering safety aspects, the description provides excellent contextual completeness. It explains the action, prerequisites, success criteria, and monitoring approach. With an output schema present (as indicated in context signals), the description doesn't need to explain return values. It covers everything an agent needs to use this tool responsibly.

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?

With 100% schema description coverage, the input schema already fully documents all three required parameters (project, zone, name). The description mentions these parameters but doesn't add meaningful semantic context beyond what the schema provides. The baseline score of 3 reflects adequate but not enhanced parameter documentation.

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 specific action ('Resets') and target resource ('Google Compute Engine virtual machine (VM) instance'), distinguishing it from sibling tools like start_instance, stop_instance, and delete_instance. It provides a complete verb+resource combination that leaves no ambiguity about the tool's function.

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 about when to use this tool by specifying prerequisites ('Requires project, zone, and instance name as input') and follow-up actions ('To get details of the operation, use the get_zone_operation tool'). However, it doesn't explicitly state when NOT to use it or directly compare it to alternatives like restart_instance (if that were a sibling tool), though the sibling list shows only start/stop/delete as related instance management tools.

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

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

The description adds valuable behavioral context beyond annotations: it specifies the instance must be 'stopped' (a critical precondition not in annotations), mentions error handling ('Proceed only if there is no error'), and references the operation status check. While annotations already indicate destructiveHint=true, the description provides practical implementation details that help the agent use the tool correctly.

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 appropriately sized with three sentences that each serve distinct purposes: stating the tool's function, listing required inputs, and providing operational guidance. It's front-loaded with the core functionality. Minor improvement could be made by combining the second and third sentences for better flow.

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 this is a destructive mutation tool with comprehensive annotations (destructiveHint=true, etc.), 100% schema coverage, and an output schema exists, the description provides excellent contextual completeness. It covers preconditions (stopped instance), error handling, and references to related tools, making it fully adequate for the agent to understand and use 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 the schema already documents all 4 parameters thoroughly. The description mentions the parameters generically ('Requires project, zone, instance name and machine type as input') but doesn't add meaningful semantic context beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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 specific action ('Sets the machine type'), target resource ('for a stopped Google Compute Engine instance'), and scope ('to the specified machine type'). It distinguishes from sibling tools like 'start_instance' or 'reset_instance' by focusing on machine type configuration rather than power state changes.

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 instance must be 'stopped' before using this tool, which is important usage guidance. It also mentions using 'get_zone_operation' to check operation details, suggesting an alternative for monitoring. However, it doesn't explicitly state when NOT to use this tool or compare it to other machine-type related tools.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations already indicate this is a destructive, non-idempotent write operation, the description adds important implementation guidance: 'Proceed only if there is no error in response and the status of the operation is `DONE` without any errors.' This provides crucial operational context about error handling and completion checking that isn't captured in the structured annotations.

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

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

The description is appropriately sized with three sentences that each serve distinct purposes: stating the core function, listing required parameters, and providing operational guidance. It's front-loaded with the most important information and avoids unnecessary repetition. The only minor improvement would be slightly tighter phrasing.

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 that this is a destructive operation tool with comprehensive annotations, complete parameter documentation in the schema, and an output schema (implied by 'Has output schema: true'), the description provides excellent contextual completeness. It covers the core function, required inputs, operational constraints, and points to related tools for follow-up actions, making it fully adequate for agent decision-making.

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?

With 100% schema description coverage, the input schema already fully documents all three parameters (project, zone, name) with clear descriptions. The description mentions these parameters but doesn't add meaningful semantic context beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete.

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 specific action ('Starts') and resource ('Google Compute Engine virtual machine (VM) instance'), distinguishing it from sibling tools like 'stop_instance', 'reset_instance', or 'create_instance'. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

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 for when to use this tool (starting a VM instance) and explicitly mentions an alternative tool ('get_zone_operation') for checking operation details. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'reset_instance' or 'create_instance', which would have earned a perfect score.

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 indicate destructiveHint=true, but the description adds valuable behavioral context beyond annotations: it specifies success conditions ('Proceed only if there is no error in response and the status of the operation is `DONE` without any errors') and provides guidance on monitoring the operation via another tool. This enhances understanding of the tool's behavior and post-execution workflow.

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 efficiently structured in three sentences: purpose statement, input requirements, and operational guidance. Each sentence serves a distinct purpose with zero wasted words. The information is front-loaded with the core action, followed by practical implementation details.

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 that this is a destructive operation with annotations covering safety aspects, the description provides excellent completeness: it explains the tool's purpose, specifies input requirements, provides operational guidance for success verification, and references a related tool for monitoring. With an output schema present, the description appropriately focuses on usage context rather than return value details.

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?

With 100% schema description coverage, the input schema already fully documents all three parameters (project, zone, name). The description mentions these parameters but doesn't add meaningful semantic context beyond what's in the schema descriptions. The baseline score of 3 is appropriate when the schema carries the full parameter documentation burden.

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 the action ('Stops') and resource ('Google Compute Engine virtual machine (VM) instance'), clearly distinguishing it from siblings like 'start_instance', 'reset_instance', or 'delete_instance'. It provides specific verb+resource combination that leaves no ambiguity about the tool's function.

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 about when to use this tool by specifying prerequisites ('Requires project, zone, and instance name as input') and follow-up actions ('To get details of the operation, use the `get_zone_operation` tool'). However, it doesn't explicitly state when NOT to use it or provide direct alternatives among siblings like 'reset_instance' or 'delete_instance'.

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