normalize_address日本の住所を正規化し、都道府県／市区町村／町字（大字・町名＋丁目）に分解して町字ID（アドレス・ベース・レジストリ）を解決し、郵便番号と照合します（不一致は不一致として明示）。【v1の粒度と限界】分解は町字（大字・丁目）まで。街区符号・住居番号・地番・小字・京都の通り名は解析対象外で、未解析部分は残余文字列としてそのまま返します（推測補完なし）。データ源: アドレス・ベース・レジストリ町字マスター（デジタル庁）＋日本郵便郵便番号データ（ローカルマスター駆動・政府API停止の影響なし）。
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | 日本の住所文字列（郵便番号含み可。全半角・漢数字/算用数字・旧字体の表記ゆれ可） | |
| postal_code | No | 郵便番号を別引数で渡す場合に指定（住所文字列内の記載より優先して照合） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It is exceptionally transparent about limitations (parsing only up to town level, not street numbers or Kyoto street names), states that unmatched portions are returned as residual strings, and notes that postal code mismatches are explicitly indicated. It also cites data sources, giving users confidence in its reliability.
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 well-structured and appropriately sized. It opens with the core action, then clearly delineates limitations using a labeled block, and ends with data sources. Every sentence provides valuable information, and the use of headers (【v1の粒度と限界】) makes it easy to scan. 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 description covers the main functionality, limitations, and data sources, and gives hints about output behavior (residual string, mismatch flag). However, without an output schema, it lacks a precise specification of the returned fields (e.g., prefecture/city/town names, town ID, postal code status). This is a minor gap given the tool's complexity, but enough to prevent a perfect score.
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 provides 100% coverage, including descriptions of both parameters (address and optional postal_code). The description adds no new parameter-specific information beyond what the schema offers, so the baseline of 3 is appropriate; it neither enhances nor detracts from semantic clarity.
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 actions: normalize Japanese addresses, decompose into prefecture/municipality/town, resolve town IDs, and match postal codes. It explicitly distinguishes itself from siblings (which handle company/invoice/calendar functions) and specifies the exact scope and limitations, making its purpose unambiguous.
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 Japanese address processing and clearly states what it does NOT do (no block numbers, etc.), which serves as an exclusion for cases needing finer granularity. However, it does not explicitly mention alternatives or provide a direct 'when to use vs. other tools' comparison, though none of the sibling tools are address-related.
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.