Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jp-verify-mcp verify T-number T1234567890123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for JP-Verify, the English-first API that verifies Japanese companies: qualified-invoice registration numbers (T-numbers), Corporate Numbers (法人番号), English names and major shareholders.
It is a thin client. Each tool call is one HTTPS request to JP-Verify's public API at
https://jp-verify.obolpay.xyz. The package holds no register data and contacts no other site; it
downloads nothing from the National Tax Agency or from EDINET.
Tool | JP-Verify endpoint | Returns |
|
| Registration status and dates, Corporate Number, Japanese name and address, English name and address (labelled official or machine-romanised) |
|
| The same for many numbers: up to 100 per call on the sandbox and Starter keys, 500 on Growth, 1,000 on Reseller. Malformed numbers are listed under |
|
| The 「大株主の状況」 (major shareholders) table from a company's securities report on EDINET, or a |
|
| Candidate Corporate Numbers for a company name (rule-based exact matching, not fuzzy search) |
All four are read-only. Each answered call (HTTP 200) is one metered lookup on your JP-Verify plan;
the batch tool counts one per well-formed number. verify_japanese_company and
get_major_shareholders reject a number that fails JP-Verify's own format or check-digit rule
locally, without a call; the batch tool sends the list as given and JP-Verify lists such numbers
under invalid, free of charge.
Every result has two parts:
jp_verify_response: JP-Verify's answer exactly as sent, including data_as_of, notes,
disclaimers and the attribution strings;
metadata: the endpoint, the HTTP status, whether an API key or the key-less sandbox was used,
the quota headers (limit, remaining, resets_at) and where the data comes from.
HTTP errors (400, 401, 404, 429, 503, 5xx) and network failures come back as tool errors with a one-line explanation. JP-Verify does not charge for 400, 401, 404, 429 or 503 answers.
Related MCP server: J-Quants Free MCP Server
Requires Python 3.10 or later.
uvx jp-verify-mcp # or: pip install jp-verify-mcp && jp-verify-mcpFrom a source checkout: pip install ., then jp-verify-mcp.
For Claude Desktop, Claude Code (.mcp.json), Cursor and other clients that start a local server:
{
"mcpServers": {
"jp-verify": {
"command": "uvx",
"args": ["jp-verify-mcp"],
"env": { "JPVERIFY_API_KEY": "your key (optional)" }
}
}
}Leave out env to use the key-less sandbox.
jp-verify-mcp --transport streamable-http --host 127.0.0.1 --port 8000
# endpoint: http://127.0.0.1:8000/mcp (stateless, JSON responses)A client may send its own key in an X-API-Key header. It is forwarded to JP-Verify for that
call only and takes precedence over JPVERIFY_API_KEY.
A loopback bind gets DNS-rebinding protection automatically. For a public host name pass
--allowed-host your.host.name (repeatable).
On a non-loopback address the server refuses to start while JPVERIFY_API_KEY is set, because
every caller without its own key would use it. Pass --allow-shared-key if that is intended.
The sandbox allowance is per IP address, so key-less callers of a hosted endpoint share the host's allowance.
Variable | Default | Meaning |
| unset | Your JP-Verify API key, sent as |
|
| API origin. Plain |
|
| Seconds per request (at most 120) |
Other options: jp-verify-mcp --help.
Without a key, JP-Verify's key-less sandbox answers. It is limited per IP address per day (JP-Verify documents 50 requests a day, as of 2026-10-07) and JP-Verify may change or end it (its Terms, Article 4).
Paid plans and their prices are published on JP-Verify's legal notice: https://jp-verify.obolpay.xyz/legal. For a key, see https://jp-verify.obolpay.xyz or write to yanagithefirst11@gmail.com.
Registration status, Corporate Number and Japanese name and address come from data published by Japan's National Tax Agency (国税庁): 国税庁適格請求書発行事業者公表サイト (qualified invoice issuers) and 国税庁法人番号公表サイト (Corporate Numbers), mirrored and processed by JP-Verify. They are not produced or guaranteed by the National Tax Agency.
English names: official-en where the company filed an English name with the Corporate Number
register; otherwise generated, a machine romanisation that is not authoritative. Most
companies have not filed one.
Sole proprietors: number, status and dates only. No name or address is returned.
Major shareholders: the 「大株主の状況」 tables companies file on the FSA's EDINET, extracted by
JP-Verify. Organisations are named; every other holder, including every individual, is
reported without a name, normally as an aggregate (always on the sandbox). Only companies that
file a 有価証券報告書 or 半期報告書 publish this table; for any other company JP-Verify returns
no_public_disclosure, a statement of why nothing is published (not a claim that the company
has no shareholders). Some filers may show not_yet_available while JP-Verify's ingest catches
up. JP-Verify switches this route on separately (its /health reports
major_shareholders.enabled); until then the tool answers route_not_enabled.
JP-Verify may add the FSA's EDINET code list (PDL1.0) and GLEIF LEI data (CC0 1.0) to a result.
When you republish data from a response, keep its attribution strings and *_register
blocks (JP-Verify Terms, Article 5).
These are register facts as of the dates each response states. They are not tax, legal, investment or ownership advice. JP-Verify answers 503 rather than serve data older than its freshness window.
The server sends JP-Verify only what a tool is asked about (numbers, a name, a date) and the API key, if any. It stores nothing, keeps no cache, never retries a call and adds no logging of its own; at the default log level (WARNING) request contents are not logged. JP-Verify's privacy statement: https://jp-verify.obolpay.xyz/v1/privacy. Terms: https://jp-verify.obolpay.xyz/terms.
python3 -m venv .venv && .venv/bin/pip install -e '.[test]'
.venv/bin/python -m pytestThe tests never reach JP-Verify: HTTP is mocked, or answered by a stand-in on 127.0.0.1.
Yanagi the First Co., Ltd. (株式会社ヤナギtheファースト) · yanagithefirst11@gmail.com · https://jp-verify.obolpay.xyz
MIT, for this client. Use of the JP-Verify service is governed by its Terms of Service.
Official MCP Registry name: xyz.obolpay/jp-verify. Source: https://github.com/Hiroshi-Ichiyanagi/jp-verify-mcp
Find candidate Corporate Numbers (法人番号) for a Japanese company name (kanji, kana, romaji or the company's registered English name) with JP-Verify's deterministic matching (rule-based exact keys, not fuzzy search). Candidates carry prefecture and city to tell same-name companies apart; a name match is not proof of identity, so confirm the candidate, then call verify_japanese_company. Corporations only. One metered lookup; an empty candidate list is a valid answer.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A company name, e.g. トヨタ自動車株式会社 or Toyota Jidosha. | |
| limit | No | Maximum number of candidates: 1-25 on the key-less sandbox and Starter keys, up to 100 on Growth and Reseller keys. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/open-world/non-destructive, but the description adds substantial behavior beyond that: deterministic rule-based exact-key matching rather than fuzzy search, a metered lookup cost, corporations-only scope, and the warning that same-name companies must be disambiguated by prefecture/city. This is exactly the context annotations cannot carry.
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?
One dense paragraph, and the highest-value facts (what it returns, the verify follow-up, the metered cost) are front-loaded. The middle clause about prefecture/city and the non-identity caveat is slightly run-on, but 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?
With no output schema, the description still explains the shape of the response (candidates carrying prefecture and city), the cost model, the scope restriction, and the empty-list case. Nothing an agent needs to call and interpret this tool correctly is missing.
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, but the description adds real meaning by enumerating accepted input forms (kanji, kana, romaji, registered English name) that the schema's single example does not fully convey. It says nothing extra about the limit parameter, which the schema already documents thoroughly.
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+resource ('Find candidate Corporate Numbers for a Japanese company name') and immediately distinguishes itself from the sibling verify_japanese_company by framing the output as candidates rather than proof. An agent can tell it apart from the verify tools without opening any schema.
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?
Explicitly states the workflow: 'a name match is not proof of identity, so confirm the candidate, then call verify_japanese_company.' It also scopes usage with 'Corporations only' and normalizes the empty result as a valid answer, so the agent knows both when to use it and what a negative result means.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The same check as verify_japanese_company for many numbers in one call: up to 100 per call on the key-less sandbox and Starter keys, 500 on Growth, 1,000 on Reseller. Malformed or mistyped numbers come back under invalid and are not charged; each well-formed number is one metered lookup. Large batches give large outputs. Source: the National Tax Agency's published data as served by JP-Verify (attribution kept). Not tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | Yes | T-numbers and/or 13-digit Corporate Numbers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/non-destructive annotations: it discloses per-tier batch limits, billing behavior ('malformed or mistyped numbers... are not charged; each well-formed number is one metered lookup'), an output-size warning, and the data provenance. These are the operational facts an agent needs before committing to a batch.
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?
Purpose and the sibling relationship are front-loaded in the first clause, followed by limits, billing, and output caveats in descending priority. Dense but every clause carries actionable information; nothing is padding.
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 compensates by describing the `invalid` bucket, the metered-per-number cost model, and the large-output caveat. It does not describe the result shape for well-formed numbers, which is the one remaining gap for a batch verification call.
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% and the single parameter already documents accepted identifier formats, so the schema carries the parameter burden. The description adds only the downstream behavior of malformed entries (returned under `invalid`), not input syntax or format detail beyond 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 and explicitly frames itself as the batch form of a named sibling ('The same check as verify_japanese_company for many numbers in one call'). An agent can distinguish it from the single-lookup sibling without opening either schema.
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?
Names the sibling it parallels and the condition that selects it (many numbers in one call), plus per-tier batch caps that tell the caller whether a batch will fit. It never states the inverse routing rule (use verify_japanese_company for a single number), so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a Japanese business in JP-Verify by its qualified-invoice registration number (T + 13 digits) or its 13-digit Corporate Number (法人番号). Returns the invoice-registration status (registered, expired, revoked or not_registered) with its dates, the Corporate Number, and for companies the Japanese name and address with an English rendering (name_en_source 'official-en' = filed by the company; 'generated' = machine romanisation, not authoritative). Sole proprietors: number, status and dates only. Source: the National Tax Agency's published data as served by JP-Verify; JP-Verify's attribution and data_as_of fields are kept as sent. Not tax advice. One metered lookup; a malformed or mistyped number is rejected without a call.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | A T-number such as T1180301018771, or a 13-digit Corporate Number. Spaces, hyphens and full-width characters are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description goes well beyond them: the data source (NTA via JP-Verify), that attribution and data_as_of are passed through unchanged, that each call is a metered lookup, and that malformed input is rejected without consuming a call. It also discloses the exact status vocabulary and the meaning of name_en_source values.
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?
It is a dense paragraph but well front-loaded: identifier, then return fields, then the English-rendering caveat, then source and caveats. Every clause carries information, though the single block is longer than strictly necessary for a one-parameter tool.
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 carries the full burden of describing returns and does so completely: status values, dates, Corporate Number, name/address fields, the name_en_source semantics, and the reduced payload for sole proprietors. An agent has everything needed to call and interpret the result.
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% for the single 'number' parameter, so format and full-width/hyphen tolerance are already documented in the schema. The description's '(T + 13 digits)' adds only a small structural clarification over the schema 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?
States a specific verb (check/verify), resource (a Japanese business), and the two accepted identifier forms, so an agent immediately knows this is a single-entity number lookup. It does not explicitly name or contrast itself with find_japanese_company_by_name or the batch sibling, but the 'by its ... number' framing implicitly separates it from name-based search.
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?
Usage is implied by the identifier-based framing and the note that a malformed/mistyped number is rejected without a call, which tells the agent when this tool will and won't spend a lookup. However, there is no explicit when-to-use-this-vs-the-batch-or-name-search guidance and no stated prerequisites.
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.
v0.1.0find_japanese_company_by_nameget_major_shareholdersverify_japanese_companies_batchverify_japanese_companyScored across 4 tools
Each tool has a clearly distinct purpose: single verification, batch verification, shareholder lookup, and name-to-number resolution. The single-vs-batch pair is explicitly differentiated by input cardinality and pricing limits, so there is no realistic misselection.
All names use consistent snake_case with a verb_noun structure (verify_..., get_..., find_...). The only deviation is pluralization in verify_japanese_companies_batch, which is natural and readable rather than inconsistent.
Four focused tools fit a narrow verification domain well; each earns its place with no redundant surface. The single/batch split is justified by the metered per-lookup pricing model.
The surface covers the core lifecycle: resolve a name to a number, verify registration/invoice status, batch-verify, and retrieve shareholders. Minor gaps remain (no richer company profile or historical status-change endpoint), but the primary workflows have no dead ends.
Verify Japanese companies, invoice-issuer registrations and addresses against government open data.
Search Japanese corporations and verify invoice numbers using official National Tax Agency data.
Search Japanese subsidies and public company data using J-Grants, gBizINFO, and EDINET.
Verify a company on GLEIF LEI and SEC EDGAR, screen sanctions. No key; quota-free data.