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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that the data comes from the NTA official API and is authoritative, which is valuable context beyond the annotations. No contradictions. It does not cover details like rate limits or error behavior, but given the annotations, the description provides sufficient transparency.

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 with two sentences plus a bold note, front-loading the essential information. Every sentence adds value: identification of resource, output fields, source, and usage guidance. The bilingual text is efficient for a Japanese corporate lookup 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?

Despite having only one parameter and no output schema shown, the description covers the tool's purpose, data source, and reliability. Annotations already provide safety context. The tool is simple, and the description gives all necessary context for an agent to select 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 has 100% coverage with one parameter 'number' described in Japanese. The description adds an example ('7000012050002') and repeats the 13-digit requirement in both languages, reinforcing the format. This adds clarity beyond the schema, so it merits a score above the baseline of 3.

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 looks up Japanese corporate numbers (13 digits) and returns company name, address, kind, and status via the NTA official API. It explicitly names the resource and action, and the inclusion of Japanese text aids understanding. While there is a sibling 'houjin.lookup' without the Torify prefix, the description emphasizes the official namespace, though not explicitly distinguishing between them.

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 advises using this tool for authoritative company info, noting that corporate registry data cannot be recalled from model weights. This provides clear guidance on when to use it over relying on internal knowledge. However, it does not explicitly exclude other use cases or compare with siblings like 'houjin.lookup' or 'company.fullProfile', leaving some ambiguity.

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