verify_invoice_number適格請求書発行事業者の登録番号（T+13桁）から登録有無・登録年月日・取消/失効を返します。on_dateで基準日時点の有効性判定、include_history=trueで公表履歴も返します。入力は登録番号のみ（氏名等による検索は提供しません）。データ源: 国税庁適格請求書発行事業者公表システムWeb-API。
| Name | Required | Description | Default |
|---|---|---|---|
| on_date | No | 基準日 YYYY-MM-DD（指定時はその日時点で登録が有効だったかを as_of で返す） | |
| include_history | No | 公表履歴（新規登録・変更・取消・失効）を含める（既定false） | |
| registration_number | Yes | 適格請求書発行事業者登録番号（T+13桁。Tなし13桁・全角・ハイフン空白は吸収） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data source (国税庁適格請求書発行事業者公表システムWeb-API), the return content (registration status, date, cancellation/expiration), and the effect of optional parameters. It does not mention error handling or rate limits, but the core behavior is transparent and the official source adds trust.
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 three sentences long, front-loaded with the core function, and every sentence adds value: what it does, how options work, what is not supported, and the data source. No fluff or redundant restatement.
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 tool with three parameters and no output schema, the description covers the essential aspects: purpose, input constraint, behavior of options, and data source. It does not specify the exact response field names or structure, but it names the kinds of data returned. This is sufficiently complete for an agent to select and invoke the tool effectively.
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 all three parameters are already documented in detail. The description adds a high-level constraint (input must be a registration number only) but does not materially extend the parameter syntax or format beyond what the schema already provides. The baseline of 3 is appropriate since the schema does the heavy lifting.
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 states a specific verb and resource: it verifies a qualified invoice issuer registration number and returns registration status, registration date, and cancellation/invalidation. It also distinguishes from siblings by explicitly noting that search by name is not provided, making it clear this tool is for number-based verification only.
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 clear context for when to use this tool—when you have a registration number—and explicitly states an exclusion: search by name is not supported. It does not name alternative sibling tools, but the when-not guidance is strong and the parameter behaviors for on_date and include_history are explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are clearly distinct (resolve_company vs verify_company vs verify_invoice_number). get_company_profile and verify_company both take corporate numbers and return company info, which could cause confusion, but their descriptions clarify different data sources and purposes.
Five of six tools follow a consistent verb_noun snake_case pattern (get_company_profile, verify_company, resolve_company, verify_invoice_number, normalize_address). jp_calendar deviates as a noun-only name, but the overall convention is readable and predictable.
Six tools is well within the 3-15 range for a focused corporate verification API. Each tool addresses a specific aspect (profile lookup, verification, name resolution, invoice verification, address normalization, business day calculations) without redundancy or bloat.
The set covers core corporate verification workflows: name-to-number resolution, number verification, detailed profile retrieval, invoice registration status, and address normalization. Minor gaps exist (e.g., no batch lookup or search by partially known number), but these are not critical for the stated purpose.