A simple civic question, a messy stack of APIs
When James McComish set out to answer “How has my MP voted on climate?” with an AI agent, the problem was not that the model gave the wrong answer. It was how the agent found the answer.
MCP oppourtunity
UK Parliament already publishes a huge amount of high quality information through public APIs. Members, divisions (votes), bills, written questions, committees, even the register of financial interests are all available if you know where to look. The issue is that they live behind more than ten separate domains and APIs, each with its own schema and conventions.
To answer that one climate question, an agent has to:
- Turn a postcode into a constituency and then into a current MP.
- Pull that MP’s voting record from division APIs.
- Filter it by topic, which often means matching against bill titles, debate subjects, and question texts.
- Pull relevant debates or statements from Hansard for context.
- Show all of this in a way a non-expert can sanity check.
A human developer can stitch this together across Members, Commons Votes, Lords Votes, Hansard, Bills, Questions and more. An LLM agent that is paying for every call and every token struggles. It has to guess which endpoint to call, guess how to shape the request, and guess how to join the results. That guesswork shows up as extra latency, unnecessary tokens, and sometimes incorrect answers.
James’ response was to build mp-mcp, a Model Context Protocol server that exposes UK Parliament data as a small, intent-led toolset designed specifically for agents. Instead of ten APIs and dozens of endpoints, an agent talks to one MCP server and gets structured JSON that reflects what people actually want to know.
Why UK Parliament is a good testbed for agent tooling
This is not just a neat civic hack. It is a good testbed for anyone thinking about serious agent deployments.
UK Parliament’s data estate looks a lot like many internal estates:
- Multiple mature systems, each with its own API and schema.
- Overlapping domains. Members are referenced in votes, debates, committees, questions and registers of interests.
- A broad set of use cases, from “who is my MP?” to “what has Parliament done about X in the last two years?”
On top of that, the data is:
- Openly licensed, under the Open Parliament Licence v3.0.
- Official. It already is the source of truth for MPs, votes, debates, bills and committees.
That combination makes it safe to experiment with agent design patterns that also matter in enterprise settings: tool shaping, grounding, and how much work you push into your MCP layer versus into each individual client.
Design goals: make the data agent friendly, not just available
James set three design goals for mp-mcp:
1. One interface for agents, regardless of the underlying API.
The MCP server hides the variety of Parliament APIs behind a single connection. An agent does not need to know whether a result came from Members, Hansard, Bills, or an interests register.
2. Tools shaped around user intent, not raw endpoints.
The server does not expose thin wrappers over HTTP calls. Instead, it provides tools like `parliament_member_overview` or `parliament_topic_tracker` that match how a person frames questions.
3. Trustworthy, token-efficient responses.
Tools return concise, structured JSON by default, with options to ask for more detail when a client needs it. An evaluation suite helps keep descriptions and behaviour aligned so that responses stay predictable.
From those goals, the rest of the design follows.
The tool surface: 15 tools and 4 prompts
James organised the server’s tools into four groups that cover what an agent typically needs to do with Parliament: identify people and places, synthesise across sources, drill into details, and describe composition of Parliament itself.
Identity
These tools help an agent anchor queries on real representatives and constituencies:
- `parliament_find_member`
Find a sitting or former MP or Lord by name, constituency or postcode.
- `parliament_find_constituency`
Resolve a constituency or postcode to a seat and its current MP.
Behind the scenes, these tools wrap the Members API and postcodes.io, taking care of nuisances like partial names and postcode formats so tools always return clean, structured records.
Synthesis
These tools are where the real value of the MCP layer shows up. They join across multiple APIs so that an agent gets something close to an answer rather than just raw data.
- `parliament_member_overview`
Returns a one-call overview of a member including a synopsis, committees, recent votes, recent contributions, and registered interests.
- `parliament_member_voting_history`
Aggregates how a member has voted over time, with filters by topic or date range.
- `parliament_search_hansard` / `parliament_get_debate`
Search debates, written answers and ministerial statements by text, then pull the complete text of a particular debate.
- `parliament_search_divisions`
Find Commons divisions (recorded votes) on a given topic, with overall results and IDs for deeper drill-down.
- `parliament_topic_tracker`
This is effectively a cross-Parliament dossier: relevant bills, debates, divisions, written questions and petitions on a single subject, returned in one call.
Without these tools, an agent would have to discover each API, assemble its own joins, and keep that logic in the client. By pushing that work into the MCP server, James gives every agent the same well-shaped, reusable primitives.
Detailed lookups
Sometimes a user does want the raw detail behind a high level summary. These tools return specific institutional artefacts:
- `parliament_get_division` for a complete vote, including Ayes and Noes by party, tellers, and result.
- `parliament_member_interests` for entries in the Register of Members’ Financial Interests.
- `parliament_get_committee` for committee membership, chair and recent work.
- `parliament_get_bill` for the status of a bill, including current house and stage, sponsors, and whether it has become an Act.
These endpoints correspond more directly to individual Parliament APIs, but they still come back as normalised JSON rather than whatever shape the underlying API happens to use.
Composition
Finally, there are tools that answer questions about the structure of Parliament rather than about a single member or bill:
- `parliament_get_state_of_parties` for seat counts by party, for either House, now or on a given date.
- `parliament_get_ministerial_roles` for government and opposition frontbench posts and who currently holds them.
- `parliament_get_election_results` for constituency election outcomes, including winner, majority, turnout and full candidate breakdown.
Orchestrated prompts
On top of those fifteen tools, James defined four reusable prompts that orchestrate several calls into finished work products:
- mp-report-card – a one-page profile of any MP, starting from a name or postcode.
- topic-tracker – a briefing on what Parliament is doing about a subject, joining bills, debates, votes, questions and petitions.
- draft-constituent-letter – a constituent letter grounded in the member’s actual voting record and contributions.
- vote-explainer – a plain-language description of a division, including motion, result, party breakdown and surrounding debate.
These prompts are not hard-coded into clients. They live in the MCP server so any MCP-capable client can reuse them with consistent behaviour.
Trust and citations
Civic answers need to be verifiable, not just plausible. James designed mp-mcp around a strict citation contract.
Every tool response includes a `sources` array of `parliament.uk` and `hansard.parliament.uk` URLs. The server declares the expectation on connection that agents must cite the corresponding URL for any factual claim about a member, vote, debate, bill, committee or election result.
That instruction is important. Without it, an agent could happily summarise the JSON it sees and omit the provenance. With it, a client UI can:
- Display citations next to each statement.
- Allow users to click through to the underlying record.
- Audit agent behaviour for missing or inconsistent citations.
The difference between “sounds like a good explanation of a vote” and “is directly traceable to the official record” comes down to this design choice.
In an enterprise setting, the same pattern applies. Swap `parliament.uk` for your own systems of record and you get agents that can be checked, not just enjoyed.
Under the hood: wiring many APIs into a single MCP server
The repository splits into three main parts:
- `packages/mp-mcp` – the core MCP server, published as an npm package.
- `apps/agent-of-parliament` – a single-page browser demo that talks to the MCP server.
- `apps/mcp-host` – a stateless HTTP host that exposes mp-mcp over a `/mcp` endpoint, used by the demo via Anthropic’s MCP connector.
Inside the server, James connects to:
- Members API for MPs and Lords.
- Commons Votes and Lords Votes for divisions.
- Hansard for debates and statements.
- Bills API for legislation.
- Committees API.
- Questions & Statements API.
- Interests API for the register.
- postcodes.io for postcode to constituency resolution.
Each of those services has its own pagination model, filtering idioms, and response schema. Rather than expose that variety to the agent, James normalises them behind the tool schemas. Tools also support response format toggles so they can return concise summaries by default and more detailed records on request, which keeps context size under control.
To stop the surface from drifting over time, the repo includes an evaluation suite that exercises tool descriptions and expected behaviour. That suite acts both as regression tests for the library and living documentation for how tools are supposed to be used.
The “Agent of Parliament” demo app
The `apps/agent-of-parliament` app exists to show non-developers what an MCP-backed agent can feel like in practice.
You visit the page, type a question in plain English, and watch the app build a set of cards to the side of the chat: MPs, votes, debates, topic dossiers and so on, each with inline citations back to Parliament or Hansard.
A flow like “Who is my MP and how have they voted on climate?” becomes, behind the scenes:
1. `parliament_find_constituency` to resolve a postcode to a constituency and MP.
2. `parliament_member_overview` to get committees, interests, and a snapshot of recent activity.
3. `parliament_member_voting_history` filtered by climate-related topics.
4. `parliament_topic_tracker` for a wider view of climate bills, debates and petitions.
The user sees a cohesive answer with references. The agent sees four well-defined tool calls and their JSON outputs. The particular Parliament APIs involved are completely hidden.
That separation is the core product of the MCP server. The demo app is just one way to show it off.
Patterns you can reuse in your own MCP work
The specifics of UK Parliament will not apply to most teams. The patterns James used in mp-mcp do.
A few that are worth copying:
Start from intent, not endpoints.
Shape tools around what a person is trying to do, even if that means fanning out to multiple underlying services inside the tool implementation.
Keep the tool surface small by default.
mp-mcp covers a large institution with fifteen tools and four orchestrated prompts. The default answer to “should we add a tool?” is no, unless it represents a genuinely new class of question.
Bake in a citation contract early.
Decide up front what a “grounded” response means and have every tool return enough metadata to support it. In mp-mcp that is just a `sources` array of URLs, but it is enforced everywhere.
Use evals to keep your interface honest.
Once you have agents and client code relying on your tools, you cannot casually change semantics. The eval suite in this repo is one way to hold descriptions and behaviour accountable over time.
Give people a reference client.
The Agent of Parliament app is a thin layer on top of the MCP server, but it makes the whole thing real to non-engineers and gives other teams an example of how to integrate with the surface.
Where this could go next
Right now, mp-mcp is strongest for questions about current MPs and recent discussions. James has already called out that deeper historical coverage is possible as more endpoints are wired in. There is also clear interest, even inside Lazer, in similar agents for other governments.
Whatever comes next, the project already proves something important.
UK Parliament did the hard work of publishing open data across multiple domains. James showed what it takes to turn that into something agents can work with directly: a single, coherent MCP server with a small, well designed tool surface, a clear contract for citations, and a demo that anyone can try.
mp-mcp is an independent, open-source project built by James McComish. It is not affiliated with, nor endorsed by, the UK Parliament. It uses only official public APIs and data licensed under the Open Parliament Licence v3.0.
Turning Open Parliament Data into Agent-Ready Infrastructure
mp-mcp shows that the next step for public data is not simply making more APIs available, but shaping them into interfaces that agents can use reliably, efficiently and transparently. By turning the UK Parliament’s fragmented data sources into a small set of intent-led MCP tools, James McComish has created a practical model for civic AI that can answer real questions while staying grounded in official records. The project’s emphasis on structured outputs, reusable prompts, citations and evaluation makes it more than a Parliament demo: it is a pattern for any organisation trying to connect agents to complex systems of record. In that sense, mp-mcp demonstrates how open data can become genuinely useful infrastructure for trustworthy AI.
