Retrieve official e-Stat area codes from a Japanese region name. Supports partial matches, so '東京' returns '東京都 (13000)' and similar matches.
地域名から e-Stat の地域コードを検索する.
都道府県名の部分一致で検索可能。 「東京」→「東京都 (13000)」のように接尾辞なしでもマッチする。
Args: name: 地域名（例: "東京", "大阪府", "北海"）
Returns: マッチした地域名と地域コードの一覧
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does explain matching behavior (prefix-based partial match) and example output format (name and code list). However, it omits details like whether the match is case-insensitive, handling of ambiguous matches, or potential multiple results. This is adequate but not exhaustive.
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 compact, well-structured, and front-loaded with the core purpose. It includes relevant examples and clear Args/Returns sections, with no unnecessary repetition or fluff. Every sentence earns its place.
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 a single parameter and an output schema (implied by presence), the description covers the essential usage, matching logic, and output format. It could mention edge cases like empty results or how to handle multiple matches, but these are minor given the tool's simplicity.
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 coverage is 0% since the schema only provides the parameter name 'name' with no description. The description fully compensates by explaining what the parameter expects (area name) with concrete examples, and also clarifies the interpretation (partial match, suffix-optional). This adds significant meaning beyond the bare schema.
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 purpose: resolving area names to e-Stat area codes via partial matching. It provides concrete examples like '東京' → '東京都 (13000)', which fully distinguishes it from sibling tools that handle statistics, corporations, or invoices.
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 explains partial matching behavior with examples, but does not explicitly state when to prefer this tool over siblings or when not to use it. Usage is clear for the tool's own scope, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.