The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Edinet listing page.
Status: PUBLIC, shipped BYOK 2026-09-16 (fleet #1942/#1928). The keyless
company lookup works for every caller with no credential; the two filing-list
tools take the CALLER's own EDINET Subscription-Key as _apiKey. See "Auth"
below for why it shipped that way rather than on a platform key.
Part of Pipeworx — an MCP gateway connecting AI agents to 1683+ live data sources.
EDINET is Japan's EDGAR: securities reports (有価証券報告書), quarterly and half-year reports, extraordinary reports, large-shareholding reports (大量保有報告書), tender offers, and the XBRL/PDF/CSV documents behind them.
| Tool | Key? | What it does |
|---|---|---|
edinet_search_filers | no | Resolve a Japanese company → EDINET code + securities code, from the FSA's official EDINET code list (~11,400 filers). Searches Japanese name, English name, kana, EDINET code and ticker. |
edinet_list_filings | yes | Every document filed on one day, optionally filtered to a filer / document type / XBRL-only. |
edinet_company_filings | yes | One filer's filings over a range of ≤31 days, newest first. |
https://disclosure2dl.edinet-fsa.go.jp/searchdocument/codelist/Edinetcode.zip
is served by the FSA with no credential — a ~570 KB ZIP holding one
Shift_JIS CSV. The pack unzips it (DecompressionStream('deflate-raw')) and
decodes it (TextDecoder('shift_jis')); both are supported in workerd,
verified 2026-09-13 on a local wrangler dev, which is worth knowing because
no other pack in this repo decodes a legacy Japanese encoding._apiKey. Sent upstream as the Subscription-Key query parameter.BYO key. edinet_search_filers needs none. edinet_list_filings and
edinet_company_filings require an EDINET API v2 Subscription-Key, which the
caller supplies as _apiKey; without one they refuse with the words "requires
an API key", so the gateway books the refusal as a gate rather than as a defect
of ours.
Pipeworx holds no platform key for EDINET, and that is a decision, not an oversight (fleet #1942, 2026-09-16). Bruce registered an EDINET account — the account exists — but the FSA's own key-issuance page rendered blank on their side, so the account could not yield a key. Rather than hold a finished pack behind a third party's outage, the pack shipped BYOK.
Anyone re-checking this: the thing to look at is the key page behind a
logged-in EDINET account, not the pre-auth URL — …/api/auth/index.aspx?mode=1
302s to Azure B2C and answers normally whether or not the page behind the login
works, so probing it unauthenticated tells you nothing either way.
If a key is obtained, platformKeyEnv: 'PLATFORM_EDINET_KEY' goes in the
manifest in the same change that lands wrangler secret put — declaring it
early un-sinks routing and points Japanese-filings questions at tools that can
only refuse (the fda-inspections precedent, #617).
documents.json?date=YYYY-MM-DD&type=2). "Toyota's filings" is
therefore a walk of the daily lists — one upstream request per day, which is
why edinet_company_filings caps its range at 31 days. Resolve the company
first with the keyless edinet_search_filers.72030 in EDINET and
7203 on the exchange. Both tools accept either and return both
(sec_code / ticker).提出者種別 starting 個人). Their 所在地 is a home
address, so the pack drops location for those rows and keeps it for
organisations.EDINET API v2 registration is not 法人番号-gated (that was the worry carried over from NTA houjin-bangou — see fleet #1928). It is an Azure AD B2C self-service signup whose form asks for exactly four things:
Field IDs read live off the signup page, 2026-09-13:
email, emailVerificationCode, newPassword, reenterPassword,
captchaEntered / challengeString / captchaControlChallengeCode
("ボットを倒すお手伝いをします"). No organisation, no corporate number, no
Japanese address — a US individual can register.
The CAPTCHA made registration a human step, so it went to Bruce. He did it — and then EDINET's key-issuance page came back blank (2026-09-16). The pack was promoted BYOK at that point rather than waiting on a vendor website.
What is still outstanding, for whoever picks this up when the page recovers:
wrangler secret put PLATFORM_EDINET_KEY on the gateway.platformKeyEnv: 'PLATFORM_EDINET_KEY' to the edinet entry in
workers/gateway/src/pack-manifest.json, in that same change.tool-examples.json entries with calls that
actually returned rows. As shipped, edinet:edinet_list_filings and
edinet:edinet_company_filings carry argument shapes taken from the FSA's
own spec (ESE140206, EDINET API仕様書 Version 2) and from a real EDINET
code we resolved live (E02144 = Toyota) — but the calls themselves have
never completed, because we have never held a key. Treat those two
examples as unverified until someone runs them.2026-09-13, re-run 2026-09-16 against the promoted pack:
edinet_list_filings and edinet_company_filings refuse without a key, with the
words "requires an API key" so the gateway books the refusal as a gate rather
than an error.
Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):
tools/list at https://gateway.pipeworx.io/edinet/mcp returns the tools in the table
above plus the shared Pipeworx meta-tools — ask_pipeworx,
discover_tools, search_within, remember/recall and the rest of the
gateway-wide set. So the tool count you see is larger than this table: a
single-pack endpoint currently lists roughly 30 shared tools alongside the
pack's own. The connection's initialize response states its exact scope, and
is the authoritative answer for a given day.
This is deliberate, not multiplexing by accident. The meta-tools are what let a
scoped connection answer a question this pack does not cover — via
ask_pipeworx, which routes across the whole catalog — without you adding a
second MCP server. There is currently no way to mount a pack endpoint without
them; if the extra schemas cost you more context than the routing is worth,
connect to the full gateway once rather than to several pack endpoints.
Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:
Both URLs reach the same gateway and the same 1683+ data sources. The
only difference is which pack's tools are listed directly; ask_pipeworx
reaches all of them from either one.
No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/edinet_search_filers. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.
This package also runs as a local stdio MCP server — no Pipeworx account, no gateway round-trip:
Or run it directly to confirm it starts:
It speaks MCP over stdin/stdout and answers initialize/tools/list/tools/call
for only this pack's tools — none of the shared meta-tools the gateway
connection above adds. Same source, same tools, no ask_pipeworx routing.
Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:
The gateway picks the right tool and fills the arguments automatically.
MIT