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

No annotations are provided, so the description carries the full burden. It discloses that the tool analyzes source code and returns comprehensive analysis including source code, dependencies, and usage examples. However, it does not mention read-only behavior, potential errors (e.g., property not found), or any limitations (e.g., network access). For a read-only analysis tool, the lack of explicit safety disclosure is a slight gap.

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

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

The description is concise and well-structured with separate sections for Args and Returns. Every sentence adds value: main purpose, parameter details, and return overview. No fluff or redundancy.

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

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

Given the tool has an output schema (not shown) and two parameters with exhaustive description coverage, the description is mostly complete. It doesn't explain behavior for invalid property names or missing versions, but the Args section is thorough. Slightly more context on edge cases would push it to 5.

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

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

With 0% schema description coverage, the description fully compensates. It explains property_name with concrete examples (HVAC_STEERING_WHEEL_HEAT, SEAT_MEMORY_SELECT) and android_version with all supported values, default, and context (e.g., 'first vHAL introduction'). This adds meaning far beyond the bare schema field names.

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

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

The description clearly states the tool's purpose: to analyze Android source code and show how a vHAL property is implemented, including source code, file locations, and usage examples. This is a specific verb+resource+scope and differentiates from siblings like summarize_vhal (which likely summarizes) and lookup_android_source_code (which likely looks up generic source code).

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: use when you need detailed implementation analysis of a vHAL property. However, it does not explicitly state when to prefer this over alternatives like summarize_vhal or generate_vhal_implementation_code, nor does it provide exclusions. The arg descriptions give some context (e.g., default Android version), but no when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the nature of the operation (discovery/analysis) and its return value, implying it is read-only and non-destructive. However, it does not detail potential external dependencies, rate limits, or that no side effects occur, which for a discovery tool might be less critical but still leaves some ambiguity.

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

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

The description is extremely concise and well-structured. It opens with a one-sentence summary, followed by clearly labeled 'Args' and 'Returns' sections. Every sentence adds value, with no repetition or filler.

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

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

The tool's purpose and interface are simple (one parameter, clear output). The description sufficiently explains what the tool does, what input is expected, and what the output covers. The presence of an output schema further reduces the need for detailed return documentation. Minor gap: it doesn't explicitly situate the tool in a workflow, but that is not essential for this simple tool.

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

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

The input schema provides only the parameter name and type with no description. The tool description compensates effectively by explaining that the parameter accepts either a property name or a category, and gives concrete examples ('SEAT_MEMORY_SELECT', 'SEAT_MEMORY', 'HVAC_BASIC'). This meaningfully extends the schema beyond the bare type definition.

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 function with a specific verb ('Discover') and a well-defined resource ('related properties, dependencies, and implementation order for vHAL properties'). It distinguishes itself from sibling tools like generate_vhal_implementation_code and validate_vhal_property_request by focusing on exploration and analysis rather than generation or validation.

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

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

The description gives clear context on when to use the tool: when you need to understand relationships and ordering for vHAL properties. It provides concrete examples of acceptable inputs (property names or categories). However, it does not explicitly mention when not to use it or directly contrast with alternatives, so it stops short of a 5.

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

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

With no annotations, the description carries the transparency burden. It explains what is produced (files, configurations, tests, documentation) and that the return includes a summary and guide. However, it does not disclose potential side effects, prerequisites (e.g., AAOS source tree access), or whether files are written versus returned as text.

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 long but well-structured with clear Args and Returns sections. It front-loads the core purpose and each parameter gets exactly one line. No redundant sentences; every detail earns its place given 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?

For a 14-parameter generator with an output schema, the description covers all inputs and states the return value. It misses minor constraints like validation rules or interactions between parameters, but the output schema and the detailed arg list provide sufficient context for correct invocation.

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

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

The description lists every parameter with a short explanation and concrete examples (e.g., `HVAC_STEERING_WHEEL_HEAT`, `0x15400A03`). This fully compensates for the sparse schema which has no property descriptions. It adds clarity on formats, defaults, and relationships (e.g., enum_values for INT32 properties).

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

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

The description opens with a specific verb and resource: 'Generate complete VHAL property implementation code for Android Automotive OS (AAOS).' It clearly distinguishes this from sibling tools like analyze, validate, or summarize by focusing on generation. The scope ('from scratch') further defines its role.

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 states the tool is used when a new VHAL property must be implemented from scratch, which is clear context. It does not explicitly exclude alternatives or name them, but the purpose and inputs make the intended usage obvious given the sibling list.

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

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

No annotations are present, so description must carry the burden. It discloses output format ('structured, professional PR description'), includes itemized content, and notes the result is 'ready to copy-paste'. It does not describe side effects or limitations, but for a text generation tool 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?

Description is appropriately sized for 17 parameters, with a clear first sentence and structured Arg/Returns sections. Each line adds value; no fluff.

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?

Combined with schema and output schema context, the description provides sufficient information for correct invocation. It covers purpose, all parameters, and return value. No obvious gaps.

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

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

Schema description coverage is 0%, but description provides an Args section with each parameter, including type examples, optionality, and context. This fully compensates for the schema's lack of descriptions and adds meaning.

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

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

Description uses specific verb 'Generate' and identifies resource 'pull request message for VHAL property implementation'. Clearly distinguishes from sibling tools that focus on code generation, validation, or analysis.

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?

Description implies tool is used when a copy-paste-ready PR message is needed for VHAL property implementation. It does not explicitly discuss alternative tools or exclusions, but the context is clear enough for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it returns 'Detailed information about the source code location and content', but does not explicitly state that it is read-only or disclose any potential side effects or prerequisites, leaving some ambiguity.

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

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

The description is compact with a clear structure: a one-sentence purpose, an Args section with examples, and a Returns line. 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?

For a simple two-parameter lookup tool with an output schema, the description covers the purpose, parameters, and return behavior adequately. The existence of an output schema means detailed return structure need not be repeated, and the description suffices.

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 provides basic types and defaults but no descriptions (0% coverage). The description compensates by giving keyword examples ('SEAT', 'HVAC', 'vehicle properties') and clarifying that category is a focus area with default 'vhal', adding meaningful context beyond the schema.

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

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

The description states 'Lookup Android source code for a given keyword' which clearly identifies the verb (lookup) and resource (Android source code), and provides examples of keywords. It distinguishes from siblings such as generate_vhal_implementation_code and analyze_vhal_implementation, which focus on generation and analysis rather than lookup.

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 does not provide any guidance on when to use this tool versus its siblings, such as discover_related_properties or summarize_vhal. It simply states what it does without mentioning alternatives or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only restates the purpose and return type, without mentioning side effects, limitations, read-only nature, or how the summary is generated. The agent cannot infer whether this is a safe, idempotent lookup or if it has any side effects.

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 short and front-loaded with the main action, and the Args/Returns structure helps readability. However, the Returns line is largely redundant with the opening sentence, so it could be trimmed further. Overall, it is appropriately concise.

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 sits among seven sibling tools and has only one parameter, the description is under-specified. It does not clarify what qualifies as a useful question, what the output summary looks like, or how it differs from analysis/validation/generation tools. The presence of an output schema reduces some burden, but it is not visible here, and the description fails to offer sufficient guidance.

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

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

Schema coverage is 0%, so the description must compensate, but it only restates the parameter as 'Question about vHAL implementation'. This adds little meaning and no examples, constraints, or formatting details. The description provides only marginal value over the raw schema title.

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?

Clear action verb 'summarize' with target 'vHAL implementation', and it states that it returns relevant information from Android documentation. However, it does not explicitly differentiate from sibling tools like analyze_vhal_implementation or lookup_android_source_code, so it stops short of a 5.

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

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

The phrase 'based on a question' implies usage when the agent needs to summarize vHAL details, but there is no explicit guidance on when not to use this tool or how it compares to alternatives. No exclusion criteria or alternative suggestions 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains the decision logic (checking against Android 16 and recommending either existing or VENDOR_ property) and mentions the naming convention. It doesn't explicitly confirm read-only behavior, but the advisory nature is clear.

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

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

The description is long but well-organized with an intro, Args list, and Returns. The arg details are necessary given the schema lacks descriptions, and the structure makes it easy to parse. It earns a 4 rather than 5 due to some redundancy (e.g., repeating 'default' values).

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 complexity (14 parameters, no annotations) and the presence of an output schema, the description covers the essential aspects: purpose, decision logic, parameter semantics, and a high-level return description. It lacks only minor details like potential errors or prerequisites, which would make it fully complete.

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

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

The description provides a detailed Args section covering all 14 parameters with types, defaults, and examples (e.g., property_name example, property_type enum values). This fully compensates for the 0% schema description coverage and adds meaning far beyond the bare 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 tool's function: validate a vHAL property request and recommend either using an existing Android property or creating a new VENDOR_ property. This specific verb+resource combination distinguishes it from sibling tools that generate code or summarize sources.

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

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

The description implies when to use this tool: when validating a vHAL property request against Android best practices and Android 16. It provides clear context but does not explicitly state exclusions or mention alternative tools, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses source URL validation, confidence scoring, alternative source suggestions, and transparency about cached vs. live data. While it doesn't discuss error handling or side effects, the disclosed behaviors are substantial for a read/analysis tool.

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

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

The description is structured with a summary, bullet-list of features, and an Args/Returns section. It is somewhat verbose but well organized; each section earns its place, and key information is front-loaded.

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

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

The description provides a complete picture: it explains the enhanced features, parameter semantics, and return value description. Given the output schema exists, the return description is bonus content. Missing details like rate limits are not critical for this read tool.

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

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

Schema coverage is 0%, and the description compensates by explaining all three parameters: question, include_source_validation, and max_sources_to_check, including defaults. This adds meaningful semantics beyond the bare schema and is exactly the kind of compensation needed.

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 provides an enhanced vHAL summary with source validation and transparency, listing specific features such as confidence scoring and citations. This is a specific verb+resource and distinguishes it from the sibling summarize_vhal tool, which likely lacks validation.

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 use when enhanced summaries with source validation and transparency are needed, providing clear context. However, it does not explicitly compare to alternatives like summarize_vhal or state when not to use this tool, so it lacks explicit exclusions or alternative mentions.

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