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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so the safety profile is covered. The description adds value beyond that by naming the data source (Japan Post data) and disclosing a result cap ('Returns up to 100 matches'), which the agent needs to interpret truncation. No auth, rate-limit, or ordering details.

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?

Front-loaded with the core purpose and the mode switch in the first two sentences, and the 100-match limit is placed where it matters. The full Japanese restatement roughly doubles the length, which is defensible for a Japanese-data tool but is pure duplication for a reader of one language.

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?

With no output schema, the description carries the return burden and does state what comes back (postal codes, up to 100 matches). It leaves unstated whether the response includes the matched address/town and whether multiple codes per town can be returned, which matters for a partial-match search.

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%, so the baseline is 3, but the description adds real semantics the schema does not carry: that `office_name` does not merely filter but switches the search to business-specific codes by name, and that `city` must be the formal municipality with the county name optionally dropped.

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?

States a specific verb and resource ('Find Japanese postal codes by prefecture, city and (optionally) part of the town name') and clearly delineates a second mode via `office_name` for business-specific codes (大口事業所個別番号). It never names the near-identical sibling `lookup_postal_code`, so an agent cannot tell from this text which of the two postal tools to pick.

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?

Gives concrete input preconditions ('the city must be the full municipality name, e.g. 札幌市中央区; the county name may be omitted') and explains the conditional branch that changes behavior when `office_name` is supplied. It stops short of any when-not-to-use guidance or an explicit alternative tool.

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