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

With no annotations, the description carries the full burden, and it does disclose real behavior: the data source (NTA published data), that cancelled and expired statuses are returned distinctly, and that non-discovery is not proof of invalidity. It still omits read-only framing, any auth or rate-limit notes for a 100-item batch, and per-item result shape.

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 action and its 100-item cap are front-loaded, and each following sentence contributes a distinct fact (data source, cancelled/expired distinction, non-discovery caveat, example). The input example at the end is the one redundant sentence given the schema already contains an example.

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 no output schema, the description must explain return semantics, and it covers the important part: cancelled vs expired are distinguished and misses are not definitive. It does not say what fields come back per number, whether results preserve input order, or how mixed found/not-found responses are shaped.

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?

There is a single parameter and schema coverage is 100%, with pattern ^T\d{13}$, maxItems 100, and an example already in the schema. The description's T+13-digit format note and JSON input example restate what the schema already provides, adding no new semantics.

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 opens with a specific verb and resource: batch lookup (一括照会) of qualified invoice issuer registration numbers in T+13-digit form, capped at 100. The word 一括 implicitly separates it from the single-number sibling verify_invoice_number, but no sibling is named, so the differentiation is left to inference.

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?

It states the batch scope and an explicit coverage exclusion — numbers belonging to sole proprietors (個人事業者) are not in the dataset, so a miss here must not be read as invalidity. That is genuine when-not guidance, but it never routes the agent to verify_invoice_number for single lookups or to the corporate siblings for name/address searches.

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