経済産業省の法人情報データベース（gBizINFO）で法人名を検索し、法人番号・所在地を含む候補を返します。利用者向け回答では単に『gBizINFO』とせず、『経済産業省の法人情報データベース』と説明してください。同名法人など複数候補がある場合は自動決定せず、利用者に所在地や正式名称を確認してください。mayHaveMoreがtrueなら先頭ページだけであることを明示してください。statusAvailabilityがnot_providedの法人を登記中・存続中と断定しないでください。候補確定後はget_company_profileを使用します。
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | 候補を絞り込む市区町村。例: 千代田区 | |
| name | Yes | 検索する法人名。正式名称が望ましい | |
| page | No | ||
| limit | No | ||
| prefecture | No | 候補を絞り込む都道府県。例: 東京都 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent, but the description adds essential behavioral details beyond those: do not automatically decide among same-name candidates, disclose when only the first page is returned, avoid asserting registration status when statusAvailability is not_provided, and use specific user-facing terminology for the data source. These are non-obvious behaviors an agent would otherwise miss.
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 core function is front-loaded in the first sentence, and the remaining sentences each carry a distinct, valuable usage or handling rule. The length is justified by the number of important caveats, and there is no wasted text.
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?
Despite the absence of an output schema, the description covers what the tool returns, how to handle multiple candidates, pagination disclosure, status uncertainty, and the next tool to invoke. This is sufficiently complete for a read-only search tool with strong annotations.
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 schema describes name, city, and prefecture with examples, while page and limit lack descriptions, giving about 60% schema coverage. The description does not add much parameter-specific meaning, although it reinforces formal name usage and mentions pagination-related output via mayHaveMore. It does not clarify page or limit semantics beyond the schema defaults.
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 identifies a specific verb and resource: it searches for company names in the METI gBizINFO database and returns candidates with corporate number and address. It also distinguishes itself from the follow-up tool get_company_profile by stating that the profile tool should be used after candidate confirmation.
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 gives clear context for when to use this tool: when searching for a company by name and needing candidate identification. It also provides explicit handling rules for ambiguous candidates, pagination, and status uncertainty, and directs to get_company_profile after confirmation. It does not explicitly contrast with search_corporate_identities, so the alternative selection guidance is not fully complete.
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.