An MCP is not an API

When you ask an AI assistant how your MP voted, it answers. The problem is where the answer comes from: its memory, which is months old and mixes up legislatures. It answers with confidence, and sometimes correctly; what it cannot do is show you the source, because it never looked it up.

That is what MCP, the Model Context Protocol, is for: an open protocol that lets an assistant query external tools instead of filling in the gap. The assistant sees a list of tools, decides which one to call, gets the data back and answers with it. It is handing someone the archive's phone number instead of asking them to remember.

The example

I built one for Es la hora de la verdad, my personal project on the votes of the Spanish Congress of Deputies: how every group and every MP voted in plenary since February 2020, with the official document of each vote. It is free, ad-free and makes no voting recommendations, and the data comes from the Congress's open data.

Exposing the data was the easy part: eight tools. Search votes by text, see a vote with each group's position, see an MP's profile, find out how a given MP voted on a given vote, see a province, search MPs, and two about the general election of 29 November: the official calendar and the party manifestos. Each one is a query against a database that already existed.

The hard part

The hard part was realising that whoever calls that API is not a programmer but a model that wants to please. A programmer reads the docs, makes the call and renders what comes back. A model reads what comes back and completes it: it rounds, it interprets, it adds a reason where there was none, and it does so with the best of intentions. If the tool's answer has a gap, the model fills it.

So the server carries rules, which travel with every response, and the rules are the product:

Every response carries the URL of its source. Error responses too. If the assistant states something, it has to be able to link it. An answer without a link is an answer that can be embellished without anyone noticing.

"Did not vote" includes absences and votes not cast, and does not explain why. Without that line, the model supplies the reason, something like "they were probably travelling". Nobody published that.

Figures are used as they are, never recalculated by another criterion. Each count of laws passed has its own rule and its own source. A model that adds things up "to help" produces a number nobody published.

It does not say who benefits from a law, and it does not recommend a vote. The site doesn't, and the assistant cannot do it on the site's behalf. If asked, it gives the data and points to the site's quiz, which compares your answers with how each group voted, and which is not a recommendation either.

There is more. Results are described with the site's own labels, passed, rejected, ratified or not ratified, without judging them. Summaries are generated with AI from the official text and marked as such, so to state anything you link the record and its official source. And it covers only the plenary of Congress: not the Senate, not the regional parliaments. Every rule closes a gap a model would happily fill.

What I take away

An MCP is not an API. It is an API plus the instructions for a reader that fills in gaps. And writing those instructions means writing down what your product will not do, which is worth knowing before you open the door.

The work that looked technical turned out to be editorial. The eight tools almost write themselves; the few lines of rules are what define Es la hora de la verdad when someone else is telling it.

AI multiplies. Judgement decides.