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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavior beyond that: it reveals the tool is 'a deterministic keyword table, not an LLM, so the same input always routes the same way', guarantees every reply carries verify and limits fields (and what they mean), and explains the non-answering behavior on excluded inputs. It contradicts nothing in the annotations and meaningfully enriches the safety/behavior profile.

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 critical information is front-loaded: purpose first, then USE WHEN/DO NOT USE, then behavioral disclaimers, then examples. However, the description carries a full English and a full Japanese section that restate the same content, nearly doubling the length. It is comprehensive but not tight – the bilingual duplication is structural waste that could be trimmed.

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 routing tool with four destinations, the description is complete: it enumerates all four routing directions, disposes of the exclusion cases, discloses the deterministic routing mechanism, and explains the output contract (verify/limits). An output schema exists to carry the return-value details, and the description covers everything an agent needs to decide whether to call this tool and what to expect.

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% – all four parameters (ask, ref, work, amount) carry their own descriptive text with format guidance. The description reinforces the primary entry pattern ('pass one sentence', 'single entry point') which maps to `ask`, but adds no new meaning beyond the schema. The schema's own hints (e.g., work '渡すと推測を挟まない') already carry the marginal semantics, so the baseline of 3 is correct.

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+resource ('Check whether a construction or renovation quote in JAPAN is fairly priced...') and names the exact scope of the routing tool: quote fairness, HORIZON SHIELD receipts, jidec: citations, contractor tactics, and verified contractors. It self-identifies as a 'single entry point' that routes to four directions, which distinguishes it from the list of siblings without needing to inspect any of their schemas.

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

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

Uses an explicit 'USE WHEN' block listing four specific trigger conditions, and a 'DO NOT USE WHEN' block giving four concrete exclusions (outside Japan, non-construction, already signed/paid, active emergency). It even states what happens in those excluded cases ('returns the appropriate outside destination instead, and says so'). This is model-quality routing guidance.

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