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

Annotations already indicate readOnlyHint=true, idempotentHint=true, openWorldHint=true. The description adds value by noting that 'government agencies may return registered=false — expected per Japanese tax law,' which is a behavioral disclosure 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?

The description is three sentences with no fluff. It front-loads the core functionality, includes a Japanese translation, provides usage guidance, and adds a behavioral note. 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?

With one parameter, 100% schema coverage, and presence of an output schema, the description is complete. It explains the return includes invoice status and corporate details, covers the expected behavior (registered=false), and gives a clear use case. No 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 coverage is 100% with one parameter described as 'インボイス番号（T + 13桁、例: T1180301018771）'. The description adds context by explaining the parameter is a T-number and how it is used in the composite call, including a Japanese example. This exceeds the schema alone.

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 it is a composite tool that takes a T-number and returns invoice registration status and corporate details. It uses specific verbs ('one-call composite') and distinguishes itself from siblings like torify_invoice.validate and torify_houjin.lookup by being a combined endpoint.

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 states when to use the tool: 'when an AI agent receives a T-number... and needs to validate both invoice compliance and company identity in one step.' It provides a clear use case but does not explicitly state when not to use it (e.g., if only one aspect is needed).

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