Skip to main content
Glama
Sign In

PlugRail JP Corporate

by dev.plugrail
OverviewDiscussionsAdmin

Server Details

Search Japanese corporations and verify invoice numbers using official National Tax Agency data.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 39 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
plugrail/servers
GitHub Stars
0
Server Listing
jp-calendar
ChatGPT
–
Claude
–

TDQS

B3.3/5.0

Scored across 7 tools

Disambiguation2/5

lookup_corporate explicitly performs both number confirmation and name candidate search, which is exactly what search_corporate_by_number and search_corporate_by_name do, and company_profile also returns core company data by the same corporate number — so three to four tools share the same input and overlapping output. The descriptions explain the nuances (scoring, nationwide fallback, aggregated citations), but an agent can easily pick the wrong one for a simple number or name lookup. Only the invoice tools (single vs. batch) have a crisp boundary.

Naming Consistency3/5

Most names follow verb_noun (search_corporate_by_x, verify_invoice_number, lookup_corporate), but the verb is inconsistent across equivalent operations (lookup vs. search), and company_profile breaks the pattern entirely as a bare noun. The domain term also flips between 'corporate' and 'company', which adds noise to an otherwise readable scheme.

Tool Count4/5

Seven tools is a well-scoped size for a corporate-registry plus invoice-verification server. The count is slightly inflated by the redundant name/number search tools that lookup_corporate already subsumes, but nothing feels bloated.

Completeness4/5

The surface covers the domain lifecycle well: number resolution, name/address/prefix discovery, an aggregated profile with provenance and partial-failure reporting, and both single and batch qualified-invoice verification with cancellation/expiry states. Minor gaps exist — no batch corporate profile or batch number lookup to pair with the batch invoice path — but agents can work around them with repeated calls.

Available Tools

7 tools
company_profileAInspect

法人番号（13桁）で基本情報・補助金・届出・財務の会社プロファイルを返す。各領域の出典・鮮度・欠損を保持し、部分障害時は取得済みと欠損を同時に返す。入力例: {"corporateNumber": "1180301018771"}

NameRequiredDescriptionDefault
corporateNumberYes13桁の法人番号。例: "1180301018771"

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it does real work: it discloses per-domain provenance, freshness, and missingness tracking, plus partial-failure semantics where acquired data and gaps are returned together. It stops short of stating auth requirements, rate limits, or caching behavior, which a read-only tool with no annotations would ideally cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the purpose before the behavioral caveats, and no filler. The trailing input example is mildly redundant against the schema but does make the required 13-digit format salient for a bilingual agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a composite read tool with no output schema and a single well-documented parameter, the description covers what is returned, that each domain carries provenance/freshness/gaps, and how partial failures surface. The main omission is any sense of the returned object's structure or size, but naming the four domains largely compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter is fully documented in the schema, so baseline is 3. The description's input example is the same value already given in the schema ("1180301018771") and adds no format, validation, or constraint detail beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it returns a company profile keyed by 13-digit corporate number, and it enumerates the four domains covered (basic info, subsidies, filings, financials). This is far more precise than the generic lookup/search siblings, but it never names those siblings or says how this composite profile differs from calling lookup_corporate 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance, no conditions for preferring this composite profile over the lookup/search siblings, and no exclusions or prerequisites. The only usage-adjacent content is an input example, which is not routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_corporateAInspect

法人番号の確定照会と名称・所在地の候補探索を分離して返す。名称だけでは断定せず複数候補と根拠別scoreを返す。候補探索は name 指定時は prefecture 任意（省略時は全国前方一致で searchedNationwide:true・候補に県コード付き・県か住所を足すと絞り込める）。prefecture は '13' または '東京都' のどちらでも可。address が「東京都渋谷区…」のように都道府県名で始まれば prefecture は省略可（推定）。address のみの検索は prefecture または推定が必須（全国非対応）。番号確定例: {"corporateNumber": "1180301018771"}／候補例: {"name": "渋谷", "prefecture": "13", "limit": 10}／全国例: {"name": "山田工業"}corporateNumber はハイフンなし13桁の文字列（数値・ハイフン付き・先頭 T 付きは不可）。番号と name は併用不可。

NameRequiredDescriptionDefault
nameNo法人名の検索語（候補探索）。例: "渋谷"
limitNo取得件数 1〜20（省略時は10）
cursorNo前回応答の nextCursor（透過・省略可）。
addressNo所在地の絞込語（候補探索の任意）。例: "渋谷"
prefectureNo都道府県（name 指定時は任意・省略時は全国検索。address のみのときは必須。address 先頭の都道府県名から推定できれば省略可）。JISコード "13"・13・"1" または都道府県名 "東京都"・"東京" のどちらでも可
corporateNumberNo13桁の法人番号（確定照会）。例: "1180301018771"

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose key behavior: results are separated into definitive vs candidate, candidates carry per-basis scores, and nationwide searches set searchedNationwide:true. It does not cover permissions, rate limits, or the full response shape, but the important semantic traits are exposed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The separation between definitive lookup and exploration is front-loaded, and the three worked examples are efficient and useful. It is dense but nearly every clause carries distinct operational information, with little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter, dual-mode tool with no output schema, the description covers the critical invocation conditions and hints at return fields (scores, searchedNationwide). A fuller description of the returned candidate structure would be needed for a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the schema documents parameters fully; the description largely repeats prefecture/address inference rules that the schema also states. The one genuinely extra rule is that corporateNumber and name cannot be combined, so it adds only marginal value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific resource (corporate number/name/location) and distinguishes two operating modes: definitive lookup by corporateNumber and candidate exploration by name/address. However, it never names or routes against the siblings search_corporate_by_number, search_corporate_by_name, or search_corporate_by_address, which clearly overlap with this tool's modes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit conditional usage: when name is given prefecture is optional, address-only search requires a prefecture or inference, and name+corporateNumber cannot be combined. What is missing is any statement of when to prefer this tool over the sibling search_corporate_by_* tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_corporate_by_addressAInspect

都道府県＋所在地の接頭辞で日本の法人を検索します。国税庁公開データに基づきます。市区町村名の前方一致が主経路で、町名以降を含む指定（例: 港区港南・東京都港区港南）は住所全文の前方一致へ迂回し、町名のみの断片（例: 港南）は住所全文の部分一致で拾います。入力例: {"prefecture": "13", "prefix": "渋谷", "limit": 10}

NameRequiredDescriptionDefault
limitNo取得件数 1〜20（省略時は10）。例: 10
cursorNo前回応答の nextCursor（透過・省略可）。
prefixYes検索接頭辞（非空）。例: "渋谷"
prefectureYes都道府県コード2桁。例: "13"（東京）

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses the data provenance and, more importantly, that results depend on whether the input is a municipality name, a full address prefix, or a town-name fragment — non-obvious behavior that changes what gets returned. It stops short of describing the returned record shape or result-set behavior, since no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and provenance, then the matching-mode rules, then a compact input example. Every sentence carries information — nothing is restated from the schema verbatim, and the example is short.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter search tool with no annotations and no output schema, the description covers purpose, data source, matching behavior, and a valid call example. The remaining gap is that it says nothing about what a result contains, which matters somewhat given there is no output schema to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description earns above that by giving the prefix parameter real semantics the schema lacks: which input forms route to which matching mode, with concrete examples (渋谷, 港区港南, 港南). The worked input example ties prefecture, prefix, and limit together in a way the schema does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource (search Japanese corporations by prefecture + address prefix) and states the data source (National Tax Agency public data), which implicitly separates it from search_corporate_by_name and search_corporate_by_number. It never names those siblings explicitly, so sibling disambiguation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains how the *form* of the input selects a matching strategy: municipality prefix as the main path, town-and-beyond strings (e.g. 港区港南) falling back to full-address prefix matching, and bare town fragments (e.g. 港南) being caught by full-address partial match. That is actionable routing guidance, but it offers no explicit when-to-use-this-instead-of-a-sibling rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_corporate_by_nameCInspect

都道府県＋法人名の接頭辞で日本の法人を検索します。国税庁公開データに基づきます。入力例: {"prefecture": "13", "prefix": "渋谷", "limit": 10}

NameRequiredDescriptionDefault
limitNo取得件数 1〜20（省略時は10）。例: 10
cursorNo前回応答の nextCursor（透過・省略可）。
prefixYes検索接頭辞（非空）。例: "渋谷"
prefectureYes都道府県コード2桁。例: "13"（東京）

TDQS

C2.9/5.0
Behavior2/5

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 does disclose the data provenance (国税庁公開データ), which is useful, but it says nothing about the read-only nature, the per-call cap, whether empty results are an error, or how the cursor-based pagination behaves, so an agent cannot tell what to expect from a call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, with the search-key sentence front-loaded and no filler. The embedded JSON sample widens the description without adding information that the schema does not already hold.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, annotation-free search tool with no output schema, the definition covers the key and an example but leaves the shape of the results and the page-follow-up flow to the schema. Adequate to invoke, yet the agent learns nothing about what a successful or empty response contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% – every parameter, including limit's 1–20 range and cursor's nextCursor link, is documented in the schema. The description's sample payload adds no meaning beyond the schema, so a baseline 3 is accurate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('都道府県＋法人名の接頭辞で日本の法人を検索') with the exact retrieval key, which implicitly separates it from the address and number search siblings. It does not name those siblings explicitly, so the differentiation is inferred from the key combination rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus search_corporate_by_address, search_corporate_by_number, lookup_corporate, or company_profile. The only actionable content is a sample payload, which is an invocation example rather than guidance about the situations the tool fits or the cases it should not be used for.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_corporate_by_numberBInspect

法人番号（13桁）で日本の法人を1件検索します。国税庁公開データに基づきます。入力例: {"corporateNumber": "1180301018771"}

NameRequiredDescriptionDefault
corporateNumberYes13桁の法人番号。例: "1180301018771"

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It adds useful context — the data source (NTA public data) and the single-record result shape — but says nothing about read-only safety, not-found behavior, rate limits, or what fields the returned record contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with the resource and scope front-loaded. The inline input example duplicates the schema's example, which is mild redundancy but not harmful for a one-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter lookup with no output schema, the description covers what the tool does and where data comes from, but leaves the agent guessing about returned fields and behavior when the number matches nothing — gaps that matter for a lookup tool with no annotations to fall back on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents the 13-digit format with an example identical to the one in the description. The description adds no semantics beyond format restatement, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieve exactly one Japanese corporation by its 13-digit corporate number, based on National Tax Agency data. The '1件' single-record scope and the number-based key clearly separate it from search_corporate_by_name and search_corporate_by_address, though it does not explicitly distinguish itself from lookup_corporate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly signals usage by requiring a 13-digit corporate number, which an agent can only supply if it already has the identifier. There is no explicit statement of when to prefer this over lookup_corporate or the name/address search siblings, and no guidance on what to do when the number is unknown.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_invoice_batchAInspect

適格請求書発行事業者番号（T＋13桁）を最大100件まで一括照会します。国税庁公表データに基づきます。取消（cancelled）と失効（expired）を区別して返します。未発見を無効・不存在と断定しません（個人事業者のデータは取り込んでいないため、個人事業者の番号はここでは見つかりません）。入力例: {"invoiceNumbers": ["T1180301018771", "T1180301018772"]}

NameRequiredDescriptionDefault
invoiceNumbersYesT＋13桁の登録番号の配列（1〜100件）。例: ["T1180301018771"]

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose real behavior: the data source (NTA published data), that cancelled and expired statuses are returned distinctly, and that non-discovery is not proof of invalidity. It still omits read-only framing, any auth or rate-limit notes for a 100-item batch, and per-item result shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and its 100-item cap are front-loaded, and each following sentence contributes a distinct fact (data source, cancelled/expired distinction, non-discovery caveat, example). The input example at the end is the one redundant sentence given the schema already contains an example.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must explain return semantics, and it covers the important part: cancelled vs expired are distinguished and misses are not definitive. It does not say what fields come back per number, whether results preserve input order, or how mixed found/not-found responses are shaped.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter and schema coverage is 100%, with pattern ^T\d{13}$, maxItems 100, and an example already in the schema. The description's T+13-digit format note and JSON input example restate what the schema already provides, adding no new semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

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: batch lookup (一括照会) of qualified invoice issuer registration numbers in T+13-digit form, capped at 100. The word 一括 implicitly separates it from the single-number sibling verify_invoice_number, but no sibling is named, so the differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the batch scope and an explicit coverage exclusion — numbers belonging to sole proprietors (個人事業者) are not in the dataset, so a miss here must not be read as invalidity. That is genuine when-not guidance, but it never routes the agent to verify_invoice_number for single lookups or to the corporate siblings for name/address searches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_invoice_numberAInspect

適格請求書発行事業者番号（T＋13桁）の登録・取消・失効を日付付きで照合します。本サービスは法人・人格のない社団等のデータのみを取り込み、個人事業者のデータを取り込んでいないため、個人事業者の番号はここでは見つかりません（公表サイト https://www.invoice-kohyo.nta.go.jp/ では確認できる場合があります）。未発見を無効・不存在と断定しません。登録ありの応答には法人番号データ由来の法人名 name・所在地 address を含みます（法人番号表に無い場合は null。未発見の応答は name/address ともに null）。入力例: {"invoiceNumber": "T1180301018771"}

NameRequiredDescriptionDefault
invoiceNumberYesT＋13桁の登録番号。例: "T1180301018771"

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and discloses important traits: only corporate/association data is ingested, not-found is not equivalent to invalid, and registered responses include name and address derived from corporate number data or null. It does not cover operational details such as authentication, rate limits, or pagination, but the domain-specific caveats are strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, followed by data-scope caveats and response details, so most sentences earn their place. The final input example duplicates the schema's own example and is unnecessary, keeping it from a higher score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values; it does describe that registered responses include name and address, when those are null, and that not-found responses have both null. It also mentions date-bearing verification for registration/cancellation/expiration, though it does not fully specify the output shape for those date fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents the single parameter with the T + 13-digit format and an example. The description adds the same input example and format, but no semantic meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: verifying qualified invoice issuer numbers (T + 13 digits) for registration, cancellation, and expiration with dates. It clearly scopes the data to corporations and associations, but it does not explicitly differentiate itself from sibling corporate-lookup tools by name or contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear when-not condition: sole proprietor numbers will not be found because only corporate/association data is ingested, and points to the public site as an external alternative. It also warns not to treat 'not found' as invalid. However, it offers no guidance on choosing among the sibling corporate lookup tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changedsearch_corporate_by_address1 field changed
      • removedInput schema / properties / prefecture / pattern
        Removed value: -"^\\d{2}$"
    • Changedsearch_corporate_by_name1 field changed
      • removedInput schema / properties / prefecture / pattern
        Removed value: -"^\\d{2}$"
    • Changedsearch_corporate_by_number1 field changed
      • removedInput schema / properties / corporateNumber / pattern
        Removed value: -"^\\d{13}$"
    • Addedsearch_invoice_batch
  2. 4 tool updates
    • Changedcompany_profile1 field changed
      • changedInput schema / properties / corporateNumber / description
        Previous value: -"13桁の法人番号。例: \"8000000000001\""New value: +"13桁の法人番号。例: \"1180301018771\""
    • Changedlookup_corporate1 field changed
      • changedInput schema / properties / corporateNumber / description
        Previous value: -"13桁の法人番号（確定照会）。例: \"8000000000001\""New value: +"13桁の法人番号（確定照会）。例: \"1180301018771\""
    • Changedsearch_corporate_by_number1 field changed
      • changedInput schema / properties / corporateNumber / description
        Previous value: -"13桁の法人番号。例: \"8000000000001\""New value: +"13桁の法人番号。例: \"1180301018771\""
    • Changedverify_invoice_number1 field changed
      • changedInput schema / properties / invoiceNumber / description
        Previous value: -"T＋13桁の登録番号。例: \"T8000000000001\""New value: +"T＋13桁の登録番号。例: \"T1180301018771\""
  3. 1 tool update
    • Changedlookup_corporate1 field changed
      • changedInput schema / properties / prefecture / description
        Previous value: -"都道府県（候補探索で必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"New value: +"都道府県（name 指定時は任意・省略時は全国検索。address のみのときは必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"
  4. 1 tool update
    • Changedlookup_corporate4 fields changed
      • addedInput schema / properties / prefecture / anyOf
        Added value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  }
+]
      • changedInput schema / properties / prefecture / description
        Previous value: -"都道府県コード2桁（候補探索は必須）。例: \"13\"（東京）"New value: +"都道府県（候補探索で必須。address 先頭の都道府県名から推定できれば省略可）。JISコード \"13\"・13・\"1\" または都道府県名 \"東京都\"・\"東京\" のどちらでも可"
      • removedInput schema / properties / prefecture / pattern
        Removed value: -"^\\d{2}$"
      • removedInput schema / properties / prefecture / type
        Removed value: -"string"
  5. 6 tool updates
    • First observedcompany_profile
    • First observedlookup_corporate
    • First observedsearch_corporate_by_address
    • First observedsearch_corporate_by_name
    • First observedsearch_corporate_by_number
    • First observedverify_invoice_number

Related MCP Connectors

Related MCP Servers

  • jp-verify-mcp

    Hiroshi-Ichiyanagi
    A
    license
    A
    quality
    C
    maintenance
    Enables verification of Japanese companies through JP-Verify's API: checking qualified-invoice registration (T-numbers) and Corporate Numbers, resolving company names to candidate numbers, retrieving official or romanised English names and addresses, and fetching major-shareholder tables from EDINET filings. Supports single or batch lookups with API-key or key-less sandbox access, returning raw responses plus quota and provenance metadata.
    4
    37 PyPI
    MIT

  • mcp-gbizinfo

    pipeworx-io
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables querying the Japanese corporate registry from METI's gBizINFO for company profiles, government procurement, subsidies, patents, certifications, financials, and workplace disclosures using corporate numbers or names.
    489 npm
    MIT

  • jp-invoice-check

    japan-ai-tools
    A
    license
    A
    quality
    B
    maintenance
    Enables AI agents to validate a Japanese qualified invoice against the six required items, reduced-rate markings, per-rate totals, and once-per-invoice-per-rate tax rounding, while flagging the common line-by-line rounding mistake, and to normalize and verify T + 13-digit registration numbers. Read-only tools also compute expected consumption tax for a given amount, rate, price basis, and rounding method.
    3
    MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources