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

Beyond the readOnly/openWorld/idempotent annotations, it discloses that activity information is deliberately returned as not_fetched due to completeness concerns, that unregistered fields must be null or empty arrays, and that statusAvailability=not_provided must not be used to assert corporate status.

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 dense but every sentence earns its place: retrieval source, user-facing naming, returned fields, activity-data exclusion, sibling routing, and null/status handling. It is front-loaded with the primary action and then layers crucial caveats.

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?

For a read-only profile tool with no output schema, the description covers the essential operational details: what is returned, what is explicitly not returned, when to delegate to a sibling, and how to handle missing or uncertain data. No critical calling behavior appears 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 100%, so the schema already documents corporate_number and activity_limit well. The description reinforces that activity_limit is deprecated and irrelevant, but does not add substantial new parameter semantics beyond the schema.

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 states a specific verb and resource: retrieving public corporate basic information from METI's gBizINFO database using a corporate number. It explicitly distinguishes this tool from get_company_activities by stating which data belongs to each tool.

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 provides explicit routing guidance: activity-related data such as certifications, patents, and subsidies should use get_company_activities. It also clarifies that the activity_limit parameter exists only for backward compatibility and is not used here.

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