get_company_profile法人番号（13桁・チェックディジット検証つき）からgBizINFOの法人プロファイル（所在地・代表者・資本金・従業員数等）を、項目別の出典・最終取得日メタとあわせて返します。データ源: Gビズインフォ REST API v2（経済産業省）。
| Name | Required | Description | Default |
|---|---|---|---|
| corporate_number | Yes | 法人番号13桁（全角・ハイフン・空白は吸収。チェックディジット検証あり） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds value by disclosing check-digit validation and the inclusion of per-item source and retrieval date metadata. However, it does not mention error handling, rate limits, or explicitly confirm read-only status, leaving some behavioral aspects undisclosed.
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 two compact sentences. The first sentence delivers the core function and outputs, and the second provides the data source. Every word is informative, with no filler or unnecessary detail.
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 single-parameter, read-only lookup with no output schema, the description covers input requirements, data fields returned, metadata inclusion, and provenance. It lacks explicit failure scenarios, but given the simplicity and schema richness, there is enough context for an agent to use it correctly.
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?
The input schema already fully describes the parameter, including the 13-digit format, handling of full-width/hyphens/spaces, and check-digit validation (100% coverage). The tool description repeats these details without adding new semantic meaning, so a baseline of 3 is appropriate.
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 returns a gBizINFO corporate profile (location, representative, capital, employees) based on a 13-digit corporate number with check-digit validation. It uses a specific verb ('返します' - returns) and resource ('法人プロファイル'), which distinguishes it from sibling tools like verify_company or 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 the tool is for retrieving corporate profile data when a corporate number is available, but it does not explicitly state when to use it over alternatives or provide exclusions. Sibling tools such as verify_company and resolve_company are not differentiated, so the agent may not know which to pick.
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.