MCP for Finance Is Getting Crowded. Verification Still Isn't Included

Open the changelog of almost any FP&A platform this year and you’ll find the same line item: an MCP server, or a downloadable folder of “AI skills”: prompt templates you drop into Claude or another assistant so it knows how to ask for a variance report or a headcount forecast. The pitch is always some version of “now your AI can talk to your finance data.” Within a quarter, this went from a differentiator to table stakes. Everyone has one.

Which means MCP itself has stopped telling you anything useful about a vendor. It’s a protocol, not a promise. A prompt template is a nicely worded question, not an answer. The real question is what sits behind the endpoint before the protocol ever gets involved: whether your agent’s output is a fact, or a guess dressed up in JSON. Most of the current wave of finance MCP servers hasn’t answered that question. They’ve just made it easier to ask.

MCP is transport. It has no opinion on truth

Model Context Protocol solves a real problem: it gives an AI a standard way to call tools and fetch context instead of every vendor inventing a bespoke plugin format. That’s genuinely useful, and it’s why adoption moved fast. But look at what MCP actually specifies: request and response shapes, tool discovery, auth handshakes, streaming. Nowhere in the spec is there a clause about whether the number a tool returns is correct. MCP doesn’t reconcile your general ledger. It doesn’t know if the “revenue” a resource exposes is contract value, recognized revenue, or last quarter’s number that never got refreshed. It just moves bytes from a server to a model in a format both sides agree on.

That’s not a knock on the protocol. A well-built, governed, read-only MCP endpoint is a legitimate way to expose data, better than an ad hoc script, better than copy-pasting into a chat window. The problem is what it’s commonly wired to. If the data behind that endpoint is an unreconciled export, a model-internal figure the AI itself computed earlier, or a spreadsheet nobody’s tied to source in months, the MCP server just gives an external agent a cleaner, faster, more authoritative-looking path to a number that was never checked. Same bad number. Better packaging. An agent pulling over MCP doesn’t ask “is this reconciled”: it asks the tool, gets a response, and treats a 200 status as truth.

Skill files have the identical gap, one layer up

The other half of this wave is the free downloadable “AI skill” library: prompt templates that tell an assistant how to phrase a request for a board deck summary or a budget-vs-actual pull. These are useful in the way a good email template is useful: they save you from writing the same instructions from scratch every time. They also do nothing about where the assistant gets its numbers.

A skill file is phrasing. It shapes the ask (which fields to pull, what tone to use, how to structure the output) but it has no mechanism to verify the answer that comes back. If the underlying data source is thin, the skill file just makes the resulting bad number arrive in a more polished paragraph. You can hand an assistant the world’s best-written prompt template for “summarize this quarter’s variance,” and if the tool behind it returns a figure with no ledger lineage, you get a beautifully written, confidently wrong summary. Better prose is not verification. It’s veneer.

What “verified” actually requires, and where it has to happen

Layer	What it does	What it does NOT do
Prompt / skill template	Phrases the request consistently	Confirm the data is correct
MCP server	Transports the request and response over a standard protocol	Reconcile, source, or check the underlying figure
Reconciled model	Ties every figure to its source transaction across systems	This is where verification actually happens
Deterministic engine	Computes the number the same way every time, no model guessing	This is where accuracy actually happens

The table makes the point structurally, but it’s worth saying plainly: verification is a data-layer property, not a protocol-layer property. It has to exist before the MCP call happens, not be inferred from the fact that a call happened successfully. A number is trustworthy because it was pulled from a model reconciled against the ledger and calculated by a deterministic engine, not because it arrived over a well-documented API. You can put the cleanest transport in the world on top of a shaky foundation and the number at the end is exactly as shaky as it started.

This is the same failure mode we’ve written about from the other direction: MCP alone doesn’t solve the ERP math problem, because a live connection to your ERP doesn’t reconcile it, and an AI operator connected over MCP needs the same access discipline as a human user, because a governed pipe into bad data is still a pipe into bad data. The pattern repeats: fix the plumbing all you want, the water quality doesn’t change on its own.

The question that actually separates vendors

Given that almost every vendor now has some MCP story, the diligence question needs to move past “do you support MCP” (everyone will say yes) to something that exposes the layer underneath:

“When my agent pulls a number over your MCP server, what proves it’s right?”

A vendor with a real answer will describe something concrete: the figure traces to a specific source document or ledger entry, a deterministic calculation produced it rather than the model inferring it, and the agent gets that provenance alongside the number, not just the number. A vendor without a real answer will describe the protocol instead: auth scopes, tool schemas, rate limits, because that’s the part they actually built. Both answers can sound sophisticated. Only one of them tells you whether the number is true.

Rexfin’s MCP server is built on the second premise. It’s a transport layer sitting on top of a model that’s already reconciled against your accounting and banking data, where every figure a connected agent can retrieve either resolves to a source citation or the tool returns an explicit refusal, never a plausible number with nothing under it. That discipline isn’t something the MCP layer adds; it’s inherited from the same verification and refusal logic that governs every answer inside Rexfin’s own interface. The protocol didn’t do the work. It just makes the work available to whatever agent asks for it.

The takeaway

MCP support and a folder of skill prompts are now the baseline, not the differentiator, and neither one does anything to verify the number underneath them. A prompt template controls phrasing. An MCP server controls transport. Truth is a property of the data layer those two things sit on top of, reconciled to source, computed deterministically, and it either exists before the protocol handshake or it doesn’t exist at all. Before you evaluate anyone’s MCP story, including ours, ask what proves the number. Then see our MCP server for how we answer that, or start from the broader case for why agentic finance needs a trust layer before it needs more autonomy. If you want to see the provenance chain on your own data, book a demo.