Japan's Digital Agency put 75,000 administrative procedures behind MCP: the design that refuses to let the AI do the math

Hello, this is Ryuta Hamamoto from TIMEWELL.

Japan's Digital Agency has released an MCP server that makes its administrative procedures survey — about 75,000 records — searchable and summarizable in natural language.¹ Connect from Claude Desktop or ChatGPT and you can ask things like "rank ministries by number of procedures."

As news, the story is "government data is now analyzable by AI." What caught my attention was not the release but the architecture.

The AI is never handed raw data to compute over. It decides what to aggregate and how; the actual computation happens server-side. For any company trying to let an AI touch its internal data, that is a directly transferable design.

Written so it makes sense without prior knowledge of MCP.

The short version

• The dataset is the FY2024 comprehensive survey of administrative procedures, about 75,000 records
• Published on GitHub under the MIT license, but explicitly labelled sample code for technical validation
• No setup needed for Claude Code. The repository ships a .mcp.json
• The core design decision is not letting the AI compute. Aggregation completes server-side
• dataset.yaml declares each field's meaning, code lists and caveats, reducing the AI's room to guess
• Responses carry provenance, field notes and data completeness
• A CLI that needs no LLM (apcli) ships alongside, so you can check the numbers yourself
• This is not the agency's first MCP server; jgrants-mcp-server for subsidies came earlier

Groundwork: what MCP is

The problem it solves

Say you want an AI to analyze your internal sales data. Traditionally you write a bespoke connector between the AI and the database. Switch to a different AI and you rebuild it. Ten data sources and three AI clients means, in principle, thirty combinations to maintain.

MCP (Model Context Protocol) standardizes that connection layer. Build one MCP server on the data side and any MCP-capable AI client can use it the same way.

You could say it is just a standard. That "just" turns out to matter.

What it enables

An MCP server presents the AI with a list of available tools. The AI reads their descriptions, picks what it needs, and calls it.

The Digital Agency's server exposes four:¹

Tool	What it does
list_datasets	Returns the available datasets
inspect_dataset	Returns structure and quality overview
query_records	Retrieves records with filters, full-text search, sorting and pagination
summarize_records	Aggregates by group (count, sum, avg, min, max)

Users never think about these four. Type "show me five procedures under the Ministry of Health, Labour and Welfare" and the AI picks query_records and assembles the conditions.

What became available

The data

The dataset is the FY2024 comprehensive survey of administrative procedures, with the ID procedures-survey-r6.¹

How many administrative procedures exist, which ministry owns each, whether they have been moved online. About 75,000 records, directly interrogable.

One practical note. The data itself is not in the repository. Because corrections and updates follow publication, a command called apcli fetch pulls it from the agency's distribution page² and converts it to Parquet.

The "bundled data goes stale" problem is avoided by not bundling it. Unglamorous, but worth copying.

How you actually ask

Prompts quoted from the README:¹

Tell me the ranking of ministries by number of procedures (top entries). Check the dataset structure first, and include provenance and quality information.

I want to know what tendencies exist among procedures not yet available online. Aggregate the whole first, then show me a few concrete examples.

Find administrative procedures that look like priority candidates for review. Narrow to application-type procedures and extract improvement candidates from those not available online. Write facts and suggestions separately.

Look at the third one: "Write facts and suggestions separately." A practical technique for getting data analysis out of an AI, embedded in the official sample. Small detail, nicely done.

Connecting

Claude Code is the easiest. The repository ships a .mcp.json, so launching in the cloned directory connects it.¹ No additional configuration.

Claude Desktop needs an entry in its config file, though apcli install desktop will write it. For ChatGPT you run the server in HTTP mode, place it somewhere reachable over HTTPS, and register it as a connector.

There is a path that skips the AI

This is the part I liked most.

A CLI requiring no LLM, apcli, ships with it.¹

apcli list                                          # list datasets
apcli inspect procedures-survey-r6                  # structure and quality
apcli query procedures-survey-r6 -q 相続 --limit 5   # search
apcli summarize procedures-survey-r6 -g 所管府省庁 -m count  # aggregate

It says "analyze with AI" while leaving a route that works without AI. When you want to verify a number, having a way to hit the data directly matters.

A --html flag produces self-contained HTML reports.

The core: don't let the AI compute

Here is the substance.

What goes wrong

Anyone who has asked a generative model to analyze data knows the pattern. You hand it a table, ask for a total, get a plausible number, and it does not check out.

An LLM is a language model, not a calculator. The more digits, the more rows, the more conditions, the less you can trust the arithmetic. Worse, it stays confident while being wrong.

Feeding 75,000 records straight to a model and asking it to aggregate is not something you can rely on.

How they solved it

The Digital Agency's implementation splits the roles:¹

Aggregation completes server-side — group-by, metrics and computed measures are calculated on the server, preventing errors that arise from handing raw data to the AI to compute.

The AI's job stops at deciding what to aggregate and how. "Group by ministry, count the rows" — assembling that condition is the AI's work. The counting is done by ordinary server-side code.

Put another way, the model is translating natural language into a query. Translation is what LLMs are good at. Arithmetic is not, so that goes to conventional code. A sensible division of labour.

Teach the data's meaning up front

The second piece is dataset.yaml.

Meaning declared through a data definition (dataset.yaml) — field roles, code lists and caveats are defined server-side, creating a structure in which the AI is less likely to fill in or guess incorrectly.

If a "procedure type" column contains 1, 2, 3, the AI does not know what those mean. It will guess plausibly and answer anyway. That is where hallucination breeds.

Write in dataset.yaml that 1 means application and 2 means notification, and there is nothing left to guess.

Rather than waiting for the AI to get smarter, build a structure where it cannot get it wrong.

Answers arrive with provenance and quality

Third. Tool responses carry:¹

• provenance (source information)
• notes (per-field caveats)
• quality_summary (completeness and similar)

Where a figure came from, and how much of that column is missing, arrives with the answer.

This matters most when the data has holes. If a column is only 30% populated and results aggregated from it are presented as fact, you will be misled. With quality information attached, the AI can qualify its explanation.

There is also resolved_fields: when the server auto-corrects a field name you typed, it states what it corrected. It does not hide having fixed things quietly.

Why this is useful

1. No preprocessing. Analyzing government data used to mean downloading a CSV, opening it in a spreadsheet, working out what the columns meant, then aggregating. All of that becomes asking.

2. Faster exploration. The slowest part of analysis is the early stage where you do not know where to look. Being able to try an angle the moment you think of it is more than a time saving.

3. Non-specialists can use it. Someone who writes neither SQL nor Python can interrogate 75,000 records. The audience for government data widens.

4. You can check the work. apcli is there when an answer looks off.

What changes with AI agents

This is the forward-looking part.

From one-off questions to multi-step work

Single question, single answer in a chat window is convenient and no more. It gets interesting when you can hand an agent a piece of work with steps in it.

An agent like Claude Code assembles and executes multiple steps on its own.

• Check the dataset structure
• Aggregate by ministry
• Identify ministries with a high share of procedures not yet online
• Extract specific procedures from within those
• Write the result into a report file

Doing that from a single request is the difference. No copy-pasting between steps.

Crossing multiple data sources

This is not the agency's first MCP server. jgrants-mcp-server, wrapping the J-Grants subsidy application system's API, came earlier.³

Here is where MCP being a standard pays off. Connect several MCP servers at once and an agent can work across them.

• Look up the state of procedures in a given policy area
• Pull subsidy information for the same area from another server
• Pull the relevant statutes from another

Things invisible when viewed separately can surface when joined. As more government open data gets MCP interfaces, this becomes practical.

But keep expectations grounded

The sober part.

The volume of government data behind MCP today is still small. And this particular release is sample code for technical validation, not a continuously running service. It is meant to run on your own machine.

The README says so:¹

This repository is an experimental sample for local or single-user use, intended to try MCP-based search and aggregation and MCP Apps display using public data. It is not intended as a production service accommodating multiple users, nor as operational infrastructure.

In HTTP mode there is no user authentication, authorization, rate limiting or audit logging, so exposing it externally requires a reverse proxy providing authentication and traffic controls. Not something to put in front of the public as-is.

The disclaimer is explicit:

The output of this implementation does not represent official government views.

The intended use is cross-checking against the source materials, not pasting results straight into a deck.

What companies can copy

There is plenty to learn here regardless of whether you touch government data.

Many companies are trying to let AI reach internal data, and the failures share causes. The AI does not know what the columns mean. It gets the arithmetic wrong. It cannot show its basis. This implementation answers all three head-on.

1. Write down what the data means, in a machine-readable form. The dataset.yaml equivalent. Column names alone leave the AI guessing. Is "revenue" before or after tax? As of when? Things humans know tacitly, written down. This is the one that pays most.

2. Do not let the AI compute. Let it assemble conditions; let existing machinery aggregate. More reliable than "let the AI do everything," and easier to build.

3. Attach provenance and quality to answers. Which data, as of when, how complete. Without it, nobody can judge whether to trust the answer.

We get asked about connecting internal data to AI, and the failures usually skip step one. A database gets wired up and the AI is expected to figure the rest out. An AI can only guess at what nobody wrote down. Building the definitions first turns out to be the faster route.

Trying it

Not much effort to try:¹

git clone https://github.com/digital-go-jp/administrative-procedures-mcp.git
cd administrative-procedures-mcp
./setup.sh

setup.sh handles dependencies, data fetch and connection guidance. On Claude Code, launching in that directory connects it.

To look at the data without AI, apcli inspect procedures-survey-r6 is the clearest starting point.

One caution from the README on fetching. Run apcli fetch only against a bundled dataset.yaml or one whose contents you have verified, and never against YAML of unknown origin. Config files are treated as trusted here, so respect that boundary.

Wrapping up

• Japan's Digital Agency released an MCP server making about 75,000 records of its administrative procedures survey analyzable in natural language
• MIT licensed, but sample code for technical validation with no guarantee of maintenance or output accuracy
• No setup for Claude Code thanks to the bundled .mcp.json
• Four tools: list datasets, inspect structure, retrieve records, aggregate by group
• The core design is not letting the AI compute. The AI assembles conditions; the server aggregates
• dataset.yaml declares field meanings, code lists and caveats, leaving the AI less to guess at
• Responses carry provenance, notes and completeness, so answers can be grounded
• An LLM-free CLI (apcli) ships alongside for verification
• With agents, multi-step automation and crossing multiple data sources become realistic
• But it is a local, single-user experimental sample, not production infrastructure

More than "government data is now analyzable by AI," the bigger story to me was that it shipped with a design that refuses to let the AI do the math.

The hardest problem in putting generative AI to work is the answer that sounds right and is not. This tackles it not by making the AI more accurate but by building a structure where it cannot get it wrong. That thinking travels well beyond government data.

If you are stuck trying to let AI reach your own data, read this repository's dataset.yaml. It shows concretely what needs writing down so the model does not have to guess.

---

Footnotes

1. Digital Agency of Japan, "Administrative Procedures Data Analysis MCP Server" (digital-go-jp/administrative-procedures-mcp, MIT License). https://github.com/digital-go-jp/administrative-procedures-mcp ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. Digital Agency of Japan, administrative procedures survey results (data distribution page). https://www.digital.go.jp/resources/procedures-survey-results ↩

3. Digital Agency of Japan, "jgrants-mcp-server". https://github.com/digital-go-jp/jgrants-mcp-server ↩