Japanese corporate number lookup using official National Tax Agency public data.
Scored across 6 tools
lookup_corporate overlaps heavily with search_corporate_by_number, search_corporate_by_name, and search_corporate_by_address, since it appears to support both exact confirmation and name/location candidate search. An agent could easily choose the wrong tool for a given lookup task.
Most tools follow a clear verb_noun snake_case pattern, and the search_corporate_by_* group is consistent. company_profile breaks the pattern by omitting a verb, and lookup_corporate uses a different verb from search_corporate_by_number for a similar operation.
Six tools is well-scoped for a corporate-number lookup server. Each tool has a defined role, and the count is neither bloated nor too thin.
The server covers searching by number, name, and address, exact corporate lookup, detailed company profile retrieval, and invoice-number verification. For a read-only public-data domain, this is a complete and usable surface with no obvious dead ends.
法人番号（13桁）で基本情報・補助金・届出・財務の会社プロファイルを返す。各領域の出典・鮮度・欠損を保持し、部分障害時は取得済みと欠損を同時に返す。入力例: {"corporateNumber": "8000000000001"}
| Name | Required | Description | Default |
|---|---|---|---|
| corporateNumber | Yes | 13桁の法人番号。例: "8000000000001" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the behavioral burden. It usefully discloses that per-domain source, freshness, and missingness are preserved, and that partial failures return both acquired and missing data simultaneously. This goes beyond a bare 'returns profile' statement, though it doesn't cover auth or permission nuances.
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?
Two dense sentences: purpose first, behavioral guarantees second, and a concrete input example. Every sentence earns its place and there is no filler or redundant schema repetition.
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?
With no output schema, the description explains the returned content domains, provenance/freshness/missingness handling, and partial-failure behavior, plus a full invocation example. It could be more explicit about the output shape, but the key contract is clear.
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 100%; the schema already describes corporateNumber as a 13-digit string with an example. The description repeats the same example and constraint, adding no new parameter semantics beyond an inline JSON call example, so the baseline 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?
Description states a concrete verb/resource: returns a company profile containing four named domains (basic info, subsidies, notifications, financials) keyed by 13-digit corporate number. It does not explicitly distinguish itself from sibling lookup_corporate, so it isn't a perfect 5, but the named domains make intent clear.
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?
No guidance is given on when to choose this tool over siblings like lookup_corporate or search_corporate_by_number. The description implies a consolidated-profile use case, but it never names alternatives or provides selection/exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
法人番号の確定照会と名称・所在地の候補探索を分離して返す。名称だけでは断定せず複数候補と根拠別scoreを返す。番号確定例: {"corporateNumber": "8000000000001"}／候補例: {"name": "渋谷", "prefecture": "13", "limit": 10}
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 法人名の検索語（候補探索）。例: "渋谷" | |
| limit | No | 取得件数 1〜20（省略時は10） | |
| cursor | No | 前回応答の nextCursor（透過・省略可）。 | |
| address | No | 所在地の絞込語（候補探索の任意）。例: "渋谷" | |
| prefecture | No | 都道府県コード2桁（候補探索は必須）。例: "13"（東京） | |
| corporateNumber | No | 13桁の法人番号（確定照会）。例: "8000000000001" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add meaningful behavior: it will not determine based on name alone, returns multiple candidates, and returns scores by basis. However, it does not describe the actual response envelope, cursor/pagination behavior, or error cases, so transparency is partial.
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 and front-loaded: it states the core behavior in one sentence, adds an important caveat about name-only queries in the second, and then provides illustrative JSON examples. No filler or redundant content.
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 dual-mode tool with 6 parameters, no output schema, and no annotations, the description covers the input modes and basic behavior. But it omits the exact response shape, how nextCursor is used, and when to prefer sibling tools. It is sufficient for basic invocation but not fully complete.
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 100%, so the baseline is 3. The description's examples group parameters into confirmation vs candidate modes, which is mildly useful, but it does not add significant meaning beyond what the schema already documents for each parameter.
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 performs two separated functions: exact confirmation by corporate number and candidate search by name/location. It gives concrete request examples for both modesches. However, it does not explicitly contrast itself with sibling tools like search_corporate_by_name or search_corporate_by_number.
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 examples imply mode selection: use corporateNumber for exact confirmation, or name/prefecture/limit for candidate search. But the description never explicitly says when to choose this tool over sibling search tools, nor does it state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
都道府県＋所在地の接頭辞で日本の法人を検索します。国税庁公開データに基づきます。入力例: {"prefecture": "13", "prefix": "渋谷", "limit": 10}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数 1〜20（省略時は10）。例: 10 | |
| cursor | No | 前回応答の nextCursor（透過・省略可）。 | |
| prefix | Yes | 検索接頭辞（非空）。例: "渋谷" | |
| prefecture | Yes | 都道府県コード2桁。例: "13"（東京） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds the data source (国税庁公開データ) and implies a read-only search, but it does not mention pagination behavior, response format, rate limits, or what happens on no results. Significant behavioral gaps remain.
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 efficient sentences with no filler. The search method and data source are front-loaded, and the inline JSON example is concise and immediately actionable.
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 input side is well-covered by schema plus example, and pagination is hinted via the cursor parameter description. However, there is no output schema and the description does not explain what the response contains, which leaves an agent uncertain about return semantics for a search 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?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds a concrete input example mapping prefecture, prefix, and limit, but does not add meaning beyond what the schema provides. Baseline 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 states a specific verb ('search'), a resource ('Japanese corporations'), and a precise search method ('prefecture + address prefix'). It also names the data source (NTA public data). This clearly distinguishes it from sibling tools that search by name or number.
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 makes the usage context clear: use this when searching by prefecture code plus address prefix. It does not explicitly enumerate when-not-to-use conditions or name alternatives, but the search method itself implies its niche among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
都道府県＋法人名の接頭辞で日本の法人を検索します。国税庁公開データに基づきます。入力例: {"prefecture": "13", "prefix": "渋谷", "limit": 10}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得件数 1〜20（省略時は10）。例: 10 | |
| cursor | No | 前回応答の nextCursor（透過・省略可）。 | |
| prefix | Yes | 検索接頭辞（非空）。例: "渋谷" | |
| prefecture | Yes | 都道府県コード2桁。例: "13"（東京） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source (国税庁公開データ) but does not state that the operation is read-only, whether pagination is supported (despite the cursor parameter), or any rate limits or errors. This is a significant gap for a tool that likely performs network queries.
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 a single sentence plus an example, perfectly sized for a straightforward search tool. It is front-loaded with the core functionality and includes a useful example. No wasted words.
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?
With no output schema and no annotations, the description should clarify return format, pagination behavior, and any side effects. It only provides an example, which is helpful but insufficient. The schema covers parameters fully, so the tool is callable, but an agent would benefit from knowing that the response includes a nextCursor for pagination, which is only hinted at by the parameter description.
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 covers all four parameters with descriptions, so the baseline is 3. The description adds a concrete example (prefecture '13', prefix '渋谷', limit 10) that illustrates typical usage, but it does not explain the meaning of cursor beyond what the schema already states. The example adds marginal value over the 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?
States a specific verb (検索します) and resource (日本の法人), with the exact criteria: prefecture code and name prefix. This is clearly distinct from siblings like search_corporate_by_address or search_corporate_by_number, which search by different fields. The description's focus on name-prefix matching leaves no ambiguity.
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 does not mention when to use this tool versus its siblings. It only states the core functionality without any exclusions or alternative recommendations. An agent must infer from the tool name that it is for name-prefix searches, which is not explicitly stated in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
法人番号（13桁）で日本の法人を1件検索します。国税庁公開データに基づきます。入力例: {"corporateNumber": "8000000000001"}
| Name | Required | Description | Default |
|---|---|---|---|
| corporateNumber | Yes | 13桁の法人番号。例: "8000000000001" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does add useful context: the data source is 国税庁公開データ and the operation returns exactly one record. However, it omits no-match behavior, response format, and any rate or access limits, leaving meaningful gaps.
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 and front-loaded: the purpose and source appear in the first clause, and the input example is directly useful. There is no filler or redundancy.
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 operation is simple and the only required parameter is fully documented in the schema, with an example. Still, there is no output schema and no discussion of what happens when no match is found or what the response looks like. A mid score is fair for a simple lookup with these omissions.
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 100%: the single parameter already has a type, pattern, and example. The description repeats the parameter and adds an input example, but this adds little beyond what the schema already documents. Baseline 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 opens with a specific verb and resource: '法人番号（13桁）で日本の法人を1件検索します' – search one Japanese corporation by its 13-digit corporate number. This clearly distinguishes the tool from sibling searches by name/address and from generic lookups like lookup_corporate.
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 clearly implies this tool is for when you have an exact 13-digit corporate numberebb8e. It does not explicitly mention alternatives or exclusions, such as 'use search_corporate_by_name if you only have a name', but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
適格請求書発行事業者番号（T＋13桁）の登録・取消・失効を日付付きで照合します。未発見は個人非掲載または未収録として明示し、無効・不存在と断定しません。入力例: {"invoiceNumber": "T8000000000001"}
| Name | Required | Description | Default |
|---|---|---|---|
| invoiceNumber | Yes | T＋13桁の登録番号。例: "T8000000000001" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. The description does disclose important behavioral nuances: it explicitly states that 'not found' is not interpreted as invalid or nonexistent, which is critical for correct use. However, it does not mention any other behavioral aspects such as rate limits, authentication, or what the response format is, which would be needed for a fully transparent behavior.
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 concise, two sentences long, and the key purpose is stated first. The not-found behavior is highlighted, which is important. The example is helpful but already present in the schema, so it is slightly redundant. Overall, it is well-structured and focused.
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?
Given the tool has only one parameter and clear schema coverage, the description is mostly complete. However, it does not explain the expected output or return values, and for a verification tool, that could be important for an agent to interpret the result. It also does not mention any prerequisites or special conditions. The absence of output schema increases the need for description clarity, which is partially met.
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 a description for the single parameter and an example. The tool description also includes an input example. Since schema coverage is 100%, the description contributes minimal additional meaning, only the example which is also in the schema. Baseline 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 verifies qualified invoice issuer numbers (T+13 digits) for registration, cancellation, and revocation with dates. It also explicitly distinguishes the tool's behavior from sibling tools by stating that 'not found' is reported as 'personal not listed or not recorded' and not asserted as invalid or nonexistent. This is specific and sets it apart from corporate search tools.
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 what the tool does and how it handles not-found cases, but it does not explicitly state when to use this tool versus the siblings. Since siblings are corporate profile and search tools, the context is clear that this is for invoice number verification, but no alternative or exclusion is mentioned. The usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
company_profilelookup_corporatesearch_corporate_by_addresssearch_corporate_by_namesearch_corporate_by_numberverify_invoice_numberVerify Japanese companies, invoice-issuer registrations and addresses against government open data.
Search Japanese company database
gBizINFO — Japanese corporate registry, from METI (経済産業省).
Search Japanese subsidies and public company data using J-Grants, gBizINFO, and EDINET.
Add one secure layer between your agents and this server.