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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value beyond these by naming the data source (NTA), specifying the exact information retrieved, and disclosing the open-world caveat about closure data. It does not contradict annotations; it reinforces the openWorldHint with a concrete interpretation.

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?

Three short sentences with no filler. The primary retrieval purpose is front-loaded, followed by the critical caveat, then the routing to get_company_profile. Every sentence earns its place and the structure aids quick comprehension.

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 compensates by enumerating the returned data fields (formal name, location, closure info, exclusion info) and the required notice source and disclaimer. It also provides the key behavioral caveat and the relevant sibling alternative. For a one-parameter read-only tool, nothing essential 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?

Schema description coverage is 0%, so the description bears the burden. It does add some meaning by connecting the parameter to the NTA corporate number inquiry, implying corporate_number is the 13-digit corporate identifier. However, it does not explicitly describe the parameter's format or semantics; the schema's pattern and parameter name already convey most of this. For a single self-explanatory parameter, this is minimally acceptable but not a strong contribution.

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 names a specific verb ('取得します' / retrieves), a concrete resource (国税庁の法人番号照会 / NTA corporate number inquiry), and the exact fields returned: latest official name, location, closure information, and search exclusion information. It also differentiates itself from get_company_profile by explicitly excluding capital and employee data, making sibling discrimination 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 gives an explicit routing rule: for capital and employee counts, use get_company_profile instead. It also provides a critical usage instruction: absence of closure information must not be interpreted as the company being operational, and the notice's source and non-guarantee disclaimer must be shown to the user. This is actionable when-to-use and how-to-use guidance.

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