Japan's Digital Agency
has started using MCP.
Until now, MCP (Model Context Protocol) talk has mostly stayed inside corporate engineering teams. Now a first MIT-licensed release from the Japanese government joins the field. Japan's Digital Agency has published on GitHub an MCP server that lets you analyze roughly 75,000 administrative-procedure records in natural language.
MCP is no longer
just a private-sector story
A first MIT-licensed MCP implementation, straight out of the Japanese government.
MCP (Model Context Protocol) is the open standard Anthropic released in November 2024 for connecting AI models safely to external data and tools. In December 2025, Anthropic itself donated MCP's governance to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, with OpenAI and Block joining as co-founders — cementing it as a vendor-neutral industry standard.
Over the past few months, MCP talk inside Japan centered on corporate engineering teams, with almost no public-sector examples. The Digital Agency itself had previously published an MCP wrapper for the "J-Grants" subsidy application API, but that was closer to a thin wrapper around an existing API.
This time the scale is different. On August 13, 2026, Digital Agency product manager Ryuichi Toki published a post on the agency's official note (its Tech blog) titled "Administrative procedure survey data (approx. 75,000 records) now analyzable via MCP in natural language," revealing that the agency had released an MIT-licensed MCP server implementation, administrative-procedures-mcp, on GitHub. The data source is the FY2024 "Comprehensive Survey of Administrative Procedures", covering roughly 75,000 national administrative procedures.
The implementation, in numbers
Sourced from the README of the GitHub repository digital-go-jp/administrative-procedures-mcp.
The core design idea is that the LLM never reads the raw data itself. Through tools like query_records and summarize_records, the LLM's job is limited to specifying search and aggregation conditions. The actual aggregation runs server-side, while field meanings, code values, and how to handle missing data are defined in dataset.yaml — a design meant to cut down on the AI misreading numbers or filling gaps with guesses. The dataset itself isn't bundled in the repo; the apcli fetch command retrieves the latest version and converts it into roughly 3MB of Apache Parquet.
From one question to an answer
"Which ministries oversee procedures with low online-completion rates?" — here's how that question gets handled.
Ask in natural language
Users type their question in plain Japanese into an MCP-compatible client like Claude Desktop or ChatGPT. No need to know SQL or an API spec.
The LLM builds the query conditions
The LLM reads the question, checks the data structure via inspect_dataset, then assembles the filter and aggregation conditions to pass to query_records or summarize_records.
The server runs the aggregation
All actual counting, grouping, averaging, and summing happens on the MCP server side. Provenance metadata, such as a fetched_at timestamp, is attached to every response.
Results render in the chat
On MCP Apps-compatible clients, there's a prototype feature that renders aggregated results directly as charts or tables in the chat. It's still experimental.
Cutting down on the AI's mistaken guesses,
while prototyping chat-UI rendering via MCP Apps.
Who this actually helps, and how
It barely matters to an individual user, but it's a concrete reference for anyone evaluating an internal document-analysis platform.
Engineers: read it as a reference implementation
Because it's MIT-licensed, the design can be reused directly. "Let the LLM only specify conditions, aggregate server-side" and "define field meaning and code values explicitly in dataset.yaml" are two patterns you can lift straight into an internal RAG or MCP server build.
Business: a nudge toward internal document analysis
The fact that a government agency itself made roughly 75,000 records of administrative data queryable in natural language via MCP is concrete ammunition for pitching MCP-based internal document analysis to leadership. That said, the agency itself calls this "sample code for technical validation" — worth flagging that it's not an endorsement of production readiness.
PMs: a map of the design constraints
The 5,000-record cap and pagination design on query_records, along with the lack of built-in authentication in HTTP mode (below), double as a ready-made checklist when scoping requirements for any other MCP server.
| Public-sector MCP, until now | This implementation |
|---|---|
| Almost no real examples; talk stayed corporate | Digital Agency itself publishes a primary-source release on GitHub |
| Mostly thin wrappers around existing APIs (e.g. J-Grants) | Roughly 75,000 census-survey records analyzable in full |
| Chat-UI integration largely unaddressed | MCP Apps support prototypes chart/table rendering |
This isn't purely a good-news story
There's reason for caution here too. The README itself states that this is "sample code for technical validation" with no guarantee of stability or ongoing maintenance — it's explicitly a pilot, not production software. The more practically significant caveat is that HTTP mode ships with no built-in authentication or rate limiting. Exposing it externally is expected to require a reverse proxy layer for access control — not a trivial constraint for an MCP server that touches government data. The README also explicitly warns against ever running untrusted dataset.yaml files.
What to watch next: whether this implementation gets extended to other agencies or datasets, and how it keeps pace with the MCP spec (it currently supports both the 2025-11-25 and 2026-07-28 versions). If you want to try something similar in-house, a realistic first step is inspecting the data with the standalone apcli tool before wiring up MCP at all, then adapting the dataset.yaml pattern to your own dataset.