verify_company法人番号（13桁・チェックディジット検証つき）から実在・商号・本店所在地・法人種別・閉鎖ステータスを返します。include_history=trueで商号変更等の履歴も返します。データ源: 国税庁法人番号システムWeb-API。
| Name | Required | Description | Default |
|---|---|---|---|
| include_history | No | 商号変更等の履歴を含める（既定false） | |
| corporate_number | Yes | 法人番号13桁（全角・ハイフン・空白は吸収） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the check digit validation, data source (National Tax Agency Web-API), and the optional history inclusion, which implies a read-only external lookup. However, it does not specify error handling, authentication requirements, or the exact return structure.
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 exactly two sentences, with the primary purpose front-loaded and the optional behavior and data source in the second sentence. Every word is informative, with no redundancy or filler.
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?
The tool has a small parameter set and no output schema, yet the description manages to enumerate the returned fields and mention the key option and data source. It lacks error behavior and response format details, which would be useful but not critical for this simple verification tool.
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?
Both parameters are already described in the schema with full coverage, so the baseline is 3. The description adds minor context by mentioning check digit validation for corporate_number and clarifying the effect of include_history, but these largely overlap with the schema descriptions.
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 the tool's function: it takes a 13-digit corporate number (with check digit verification) and returns existence, trade name, location, corporate type, and closure status. This specific verb+resource combination distinguishes it from siblings like resolve_company.
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 verifying a corporate number's existence but does not explicitly state when to prefer this tool over alternatives like resolve_company or get_company_profile. It lacks exclusions or conditional guidance, so the agent must infer the appropriate context.
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.