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

Annotations only declare readOnlyHint=true, and the description adds substantial behavior beyond that: a possible 503 when the EDINET code master is unavailable, the full-width/half-width normalization rule, the exact → prefix → partial result ordering, and the empty-result contract. These are exactly the failure modes and matching semantics an agent needs to interpret odd responses.

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 core purpose and the input taxonomy are front-loaded in the opening clause, and nearly every sentence carries operative information about edge cases. The main inefficiency is the full Japanese paragraph, which restates the English content almost verbatim and roughly doubles the description length without adding new constraints.

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?

There is no output schema, and the description fills that role by naming the returned fields (names, listing status, fiscal year end, industry, symbolSource, classShareSymbol). Combined with the empty-result and 503 guidance, an agent has everything needed to call the tool and interpret both successful and empty responses.

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 50% — query is documented in the schema while limit is not — but the description compensates heavily for the query parameter by spelling out four accepted identifier types, the E02144 format, the 13-digit corporate number, the 2-character minimum name length, and 5-digit class-share handling. The undocumented limit is still self-evident from its default of 10 and 1–50 bounds, so the gap is minor.

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 the EDINET filer code of a company) and then enumerates exactly which inputs resolve to it: securities code, EDINET code (E02144), 13-digit corporate number, or company name. It also declares scope coverage (non-listed filers and funds) and the returned fields, so an agent knows precisely what this tool does versus the many get_* siblings.

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 strong conditional guidance: supplement lookup for TOKYO PRO Market / recent listings, 5-digit preferred shares returning the issuer with classShareSymbol set, and an explicit statement that [] is the correct answer for TOKYO PRO/Fukuoka/Sapporo-only companies that do not file with EDINET. It does not, however, contrast itself with the sibling search_company, leaving the agent to guess which lookup tool to prefer for name-based discovery.

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