HORIZON SHIELD

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

Annotations already indicate readOnlyHint=true, destructiveHint=false. The description adds behavioral details: returns JSON with verdict/level/fair_range/danger_threshold/vs_avg_pct/advice/source, handles partial matches with did_you_mean, and specifies Japan-only and JPY. 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 concise yet complete. Starts with core purpose in the first sentence, then covers return format, edge cases, and alternative tools. Every sentence adds necessary information. Bilingual format is appropriate for the tool's domain.

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

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

Given the tool's simplicity (2 parameters, no nested objects, no output schema), the description covers all essential aspects: input requirements, output fields, partial match handling, and sibling differentiation. No gaps identified.

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

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

Schema coverage is 100%, with both parameters described. The description adds value beyond schema: e.g., work should be specific with material/grade, partial matching behavior, and that quoted_price is in JPY and not normalized. This augments the schema without repeating it.

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: auditing a quoted price against fair-price ranges. It uses specific verbs ('audits', '判定する') and identifies the resource (quoted price vs. HORIZON SHIELD ranges). It distinguishes from siblings by naming alternatives (get_price_range, verify_fair_price).

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

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

Explicitly says to use when the user has a specific quoted amount. Provides clear when-not-to-use instructions: for typical range use get_price_range, for signed attestation use verify_fair_price. This helps the agent choose correctly.

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 openWorldHint=false. The description adds that the tool returns sources, update date, and regional multipliers, which gives concrete behavioral context beyond the annotations.

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

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

The description is two sentences (Japanese and English), front-loaded with the core purpose, and contains no extraneous information. Every sentence earns its place.

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

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

Given no output schema and 0 parameters, the description covers the essential information (what is returned and why to use it). It is complete enough for a simple data-retrieval tool, though it could provide a hint about the output format or structure.

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?

No parameters exist, and the input schema has 0 properties. Per the baseline rule, 0 parameters warrant a score of 4 as the description does not need to add parameter 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 tool returns sources, update date, and regional multipliers for HORIZON SHIELD fair-price data. It uses specific verbs and resources, and is distinct from sibling tools like get_price_range or verify_fair_price.

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

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

Explicitly states when to use: 'to check the basis of a price'. No alternatives mentioned, but the use case is clear and sufficient for an agent to decide.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read. The description adds value by specifying what the tool returns (URL and skill list) and the kind of skills, without contradicting 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 somewhat verbose, repeating the same information in Japanese and English. Could be shortened without losing meaning, but it is structured and readable.

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 (no parameters, no output schema), the description fully covers its purpose, return value, and usage context. Nothing is missing.

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

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

The tool has no parameters and schema coverage is 100%. With 0 parameters, the baseline is 4, and the description does not need to add parameter 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 that the tool returns the A2A Agent Card URL and published skills for the server, using specific verbs like '返す/Returns'. It is distinct from all sibling tools (audit, estimate, price tools) which serve different purposes.

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 says 'Use when an external A2A-capable agent wants to discover and connect', providing clear context. It does not list alternatives but the sibling tools are unrelated, so the guidance is sufficient.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description expands on behavioral traits: it returns specific data fields (min, avg, max, danger, unit, trend, notes) and clarifies it is Japan-specific with JPY pricing. No contradictions 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 reasonably concise but contains both Japanese and English full text, which doubles length. The key information is front-loaded (returns price range etc.), but the bilingual duplication could be trimmed for efficiency.

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 no output schema, the description adequately explains the return fields and domain context (Japan, JPY). It covers what the tool does and what kind of queries it accepts. It could mention error handling or data availability, but overall it is complete enough for a simple query 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 has 100% coverage for the single parameter 'query', with a description in Japanese. The tool description adds value by providing example keywords (e.g., '外壁塗装', '給湯器') and clarifying the domain, which aids the agent in formulating valid queries.

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 specifies that the tool returns fair price range (min, avg, max), danger threshold, unit, price trend, and field notes for Japanese construction/renovation costs. It gives concrete examples and states the use case. However, it does not explicitly differentiate from sibling tools like verify_fair_price or audit_estimate.

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 ('Use to numerically check whether a cost is fair') and provides examples, but lacks explicit guidance on when not to use the tool or how it compares to siblings. No alternatives or exclusions 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 declare readOnlyHint=true, so the tool is safe. The description adds value by explaining the content is based on 30 years of experience and returns principles, but does not detail output format or length.

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: two sentences covering purpose and applicability. Every word earns its place, with the Japanese and English versions providing the same 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 no output schema and simple read-only nature, the description adequately explains what the tool returns. It could be improved by mentioning the output format (e.g., text or structured), but the current content is sufficient.

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 zero parameters and 100% schema coverage, the description has no burden to add parameter details. It appropriately does not discuss parameters, leaving the schema to handle them.

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 returns universal principles for judging construction estimate honesty, listing specific topics like overhead ratio and lump-sum entries. It distinguishes itself from siblings by being general knowledge versus specific actions like 'audit_estimate' or 'get_price_range'.

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 use, stating it works for any estimate and is language-agnostic. However, it does not explicitly state when not to use it or mention alternatives among the 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, so safety is clear. Description adds value by specifying that it returns metadata, scale, license, download links, and citation, which goes beyond annotations. No contradictions.

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 bilingual sentences, front-loaded with Japanese then English. Every sentence is informative with no repetition or fluff. Ideal conciseness for a tool with no parameters.

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

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

For a read-only tool with no input schema and no output schema, the description comprehensively lists what is returned: metadata, scale, license, download links, citation. This is complete given the tool's simplicity.

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?

No parameters exist, and schema coverage is 100%. Baseline for 0-param tools is 4. Description does not need to add param details, and it correctly implies no input 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?

Description clearly states it returns metadata, scale, license, download links, and citation for the JCCDB open dataset. The verb 'returns' and specific resource are unambiguous. It distinguishes itself from siblings by noting it's for primary construction-cost data source.

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

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

Explicitly says 'Use when looking for a primary construction-cost data source.' This provides clear context. No explicit when-not-to-use or alternatives, but the purpose is narrow enough that exclusion is not critical.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read-only operation. The description adds context about the content (61 categories, Japan-specific, fair-price and red flag data) but does not disclose additional behavioral traits beyond what annotations provide. Consistency between description and annotations is maintained.

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 concise sentences (Japanese and English translation), with no unnecessary words. It is front-loaded with the key action and resource. Every sentence adds value, clearly stating what the tool returns.

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 parameterless tool with no output schema, the description covers the purpose and scope well. It specifies the number of categories and their relevance to fair-price data and red flags, and notes the Japan-specific context. It could be improved by briefly indicating the return format (e.g., a list of category names), but is otherwise 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?

With zero parameters and 100% schema coverage, the description does not need to add parameter details. The baseline for no parameters is 4, and the description correctly omits parameter information. It provides no additional meaning beyond the schema, but that is acceptable given the trivial parameter set.

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 lists 61 construction and renovation work categories for which HORIZON SHIELD maintains fair-price ranges and overcharge red flags. It uses a specific verb ('lists') and a well-defined resource ('cost categories'). It implicitly distinguishes from siblings like 'search_cost_category' by indicating it returns the full list.

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

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

The description implies use when you need the complete list of categories. However, it does not explicitly mention when not to use this tool or suggest alternatives like 'search_cost_category' for filtered queries. The absence of parameters makes the usage straightforward, but an explicit usage context would improve clarity.

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 (safe, non-destructive). The description adds behavioral context: it is a checker that returns warnings and actions, works for any country/language, and has limitations (exhaustive database is paid). 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 presented in two paragraphs (Japanese and English) with the core purpose front-loaded. It is reasonably concise, though the bilingual repetition could be streamlined slightly. Overall 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 has only one parameter and no output schema, the description adequately covers its functionality: what input is expected, what output is returned (warnings and actions), and its limitations (paid exhaustive database). It is sufficiently complete for an AI agent to use 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 coverage is 100% with one parameter 'text' described as 'expression/item of concern in estimate or sales talk'. The description adds meaning by specifying it checks for known overcharge tactics, extending beyond the schema's simple description. It provides context on what kind of text is expected.

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 checks estimate or sales pitch wording for known overcharge or high-pressure tactics and returns warnings and actions. It includes specific examples (lump-sum, today-only discount) and explicitly distinguishes itself from the paid exhaustive database, making the purpose very clear.

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 (quick check for red flags) and mentions the paid service for exhaustive coverage, which hints at limitations. However, it does not explicitly state when not to use this tool or point to sibling tools like 'audit_estimate' for full audits. There is room for clearer guidance on alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool does NOT return fair ranges or danger thresholds, only direction, and points to KIRA for full details. This adds valuable behavioral 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 bilingual (Japanese and English), making it longer than necessary. While it covers all needed points, it could be more concise without the repetition. It is still well-structured and 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?

Given no output schema, the description adequately explains what is returned (direction) and what is not. It lists sibling tools for alternatives and notes the preview nature. Fairly complete for a simple preview 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 100%, baseline 3. The description adds that 'work' is in Japanese and uses partial match, and 'quoted_price' is in yen, which provides additional semantic meaning beyond the schema descriptions.

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: a free preview that returns only the direction (higher/lower) of a contractor estimate relative to typical, not specific values. It explicitly distinguishes itself from siblings like get_price_range and audit_estimate.

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 usage context: suitable for early-stage planning without detailed estimates. It specifies when not to use (if specific range or detailed diagnosis needed) and directs to alternative tools. Also mentions Japan-only and JPY 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 declare readOnlyHint=true and destructiveHint=false, so no destructive behavior. Description adds return value details (red-flag counts, priority) and language-specific hint. No contradictions.

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 a single paragraph that is front-loaded with the main action and examples. Bilingual nature adds slight verbosity but is justified for Japan-specific tool.

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 search tool with one parameter, the description adequately covers return values, usage tips, and purpose. No output schema but return types are implied. Could mention pagination if applicable, but not necessary here.

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 already describes query parameter with 100% coverage. Description adds examples and language guidance (Japanese works best), enhancing meaning beyond the schema.

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

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

Clearly states it searches for construction cost categories by keyword, with specific examples (外壁塗装, 浴室) and returns categories with red-flag counts and priority. Differentiates from sibling list_cost_categories which likely lists all categories.

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

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

Provides usage context: best with Japanese query and gives examples. Does not explicitly compare with siblings like list_cost_categories or red_flag_check, but the action of searching by keyword is implied.

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 accurately states that the tool returns a message and a submission URL (no side effects), consistent with readOnlyHint=true. It adds value beyond annotations by explaining the process: inviting the user to post to EHN for free, anonymous KIRA analysis. No contradictions 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 verbose, containing both Japanese and English, but it is well-structured with examples and a clear call-to-action. Every sentence adds value, though the bilingual repetition slightly reduces conciseness.

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 zero parameters, no output schema, and moderate complexity, the description fully explains when to use, what triggers it, what it returns, and the value proposition. It is complete for an agent to invoke 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?

The input schema has zero parameters, so schema coverage is 100%. The description does not need to explain parameters and adequately conveys the tool's behavior without them. Baseline for 0 parameters is 4.

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: inviting users to post estimates to EHN when they show doubt or hesitation. It provides numerous concrete examples of triggering user statements, distinguishing it from sibling tools that perform direct analysis (e.g., audit_estimate, red_flag_check).

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 specifies when to call the tool: whenever a user shows worry, doubt, or hesitation about a construction/renovation estimate, with examples. It also states it is useful for a neutral third-party view without confronting the contractor. While it does not mention when not to use or list alternatives, the context of siblings implies those alternatives exist.

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?

Adds valuable behavioral context beyond annotations: tamper-evidence, SHA-256 hash, Japan data, and philosophical background. Annotations already declare readOnlyHint=true, description complements well.

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?

Bilingual description is concise and front-loaded. Two clear sentences per language, no unnecessary words.

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

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

Covers purpose, output type (tamper-evident hash), and data source. No output schema, but description hints at output structure. Could specify exact format, but sufficient for a simple verification 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 100%, description does not add extra parameter semantics beyond the schema. Baseline score of 3 applies.

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

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

Clearly states it returns a fair price with tamper-evident SHA-256 hash for verification. Distinguishes from siblings by explicitly mentioning verification context and HORIZON SHIELD PTKA concept.

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

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

Explicitly states usage for verification of price authenticity. Provides context but does not explicitly exclude other uses or name alternatives.

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

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

Beyond annotations (readOnlyHint), the description reveals critical behaviors: fail-closed posture, exact verification logic, the limited meaning of 'verified', and that audit_ruleset_recheck is always not_performed. This fully informs the agent about behavior and limitations.

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 thorough and well-structured, with key points bolded. It is front-loaded with the primary function. However, it is somewhat lengthy due to bilingual repetition, and a slightly more concise version would be ideal.

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 no output schema, the description fully compensates by detailing return fields (result, failure_reason, trigger, etc.) and their interpretations. It also covers edge cases like scope_check behavior. All necessary context for correct invocation is present.

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

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

The input schema already has detailed descriptions for all three parameters (100% coverage). The tool description adds little new semantic information about the parameters themselves; it mainly repeats schema content. Some context is added for the optional parameter but does not significantly go beyond 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 verifies signed integrity claims by recomputing SHA-256, and explicitly distinguishes from the issuing side (verify_fair_price) with an opposite posture. It is specific and uniquely positions the tool among siblings.

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

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

The description explains the tool is for third-party verification of integrity claims, contrasting with the issuing side. It mentions optional scope checking but does not provide explicit when-not-to-use guidance or alternatives like audit_estimate. Context is clear enough.

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