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

With no annotations provided, the description carries the full burden and does well: it discloses that unresolved lookups are never charged, per-field evidence and confidence are returned, and nulls are honest. It also includes pricing. This goes beyond a simple 'look up company' statement and gives useful behavioral context.

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 compact with three focused sentences, front-loading the purpose and key benefits. It avoids unnecessary words. The only minor issue is the elliptical first sentence, but it remains efficient and readable.

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 annotations and no output schema, the description provides a reasonable overview but lacks explicit usage guidance and details on the output structure. It mentions evidence and confidence, but not the exact fields or format. It is adequate but not fully complete for a tool with this complexity.

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 only 33%, but the description adds meaning for the 'company' parameter by specifying it accepts name/domain/URL. However, 'country_hint' is not mentioned at all, and 'x_payment' is adequately described in the schema. The description partially compensates for low coverage but leaves country_hint ambiguous.

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 conveys that the tool takes a company name/domain/URL and returns a verified profile, referencing specific registries (GLEIF LEI, Japan NTA). This distinguishes it from sibling tools like jp_company_profile, though the grammar is slightly awkward without an explicit verb. It effectively communicates the core function.

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 implies usage for company verification and enrichment via primary sources, but it does not explicitly state when to use this tool versus alternatives like jp_company_profile or extract_url. It provides context (primary sources, registries) but lacks exclusionary guidance or alternative comparisons.

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