MCP for Startup Finance: The Last Mile, Not the First Step

If you've read my last two posts, you know I have a thing about order. Design your data model before you write a single line of code. Build your data foundation before you layer AI on top. Both posts make the same argument from different angles: AI removes the building barrier, not the judgment barrier — and the teams that win are the ones who do the unsexy structural work first.

This post is about a technology that's getting a lot of breathless coverage right now, and that tempts finance people to break that rule. It's called the Model Context Protocol (MCP), and the hype around it is essentially: connect your AI directly to Stripe, your bank, and your accounting system, and just ask it anything.

It's a genuinely useful piece of technology. But where it belongs in your stack is exactly where the hype doesn't put it: at the end, not the beginning. This post explains what MCP is, where it actually fits in the sequence I've been writing about, and why "connect everything to AI" is the last mile of the journey — not the first step.

What MCP actually is

An AI model on its own is a brilliant reasoner with no access to your reality. It doesn't know your cash balance, your MRR, or what's in your bank feed. To do real finance work, it has to connect to the systems where your data lives.

Until recently, every one of those connections had to be custom-built — a bespoke integration for each AI-tool-to-data-source pairing, each one needing maintenance. For a startup with no spare engineering hands, that's usually where the ambition died.

MCP is an open standard, introduced by Anthropic in late 2024, that fixes this. Instead of a custom integration for every pairing, it defines one consistent way for AI applications to talk to outside tools and data. Build the connection once, and any AI assistant that speaks MCP can use it. The analogy that's stuck is "USB-C for AI" — one connector replacing a drawer full of incompatible cables.

A few things worth knowing, without the technical weeds:

• It's open and not locked to one AI vendor. Anthropic created it, but it's an open standard the major AI platforms have adopted. A connection you set up today shouldn't lock you into one provider tomorrow.

• Your data source gets exposed through an "MCP server"; the AI assistant is the "client." Increasingly the tools you already use, or third parties, provide these — you connect them rather than building from scratch.

• It lets the AI request specific, structured facts — "pull last month's revenue," "list past-due invoices" — instead of guessing from text you've pasted in.

That last point is why people get excited. And it's also where the trap is.

Where MCP fits in the sequence

In "From Spreadsheets to AI," I laid out the order that actually works:

1. Audit your data sources

2. Stand up a warehouse

3. Define your top 10 KPIs in writing

4. Build a metrics layer

5. Only then layer AI tools on top

   
   

Here's the thing to internalize: MCP is a Step 5 technology. It's a connector that lives in the top layer. It's the standardized plumbing that lets your AI assistant reach your data — which makes it the mechanism behind exactly the use cases I put in Step 5, like the Slack bot that answers "what was net new ARR last week by segment?" without anyone bothering the finance team.

What MCP is not is a replacement for Steps 1 through 4. And this is precisely where the hype tries to mislead you. The seductive pitch is that MCP lets you skip the warehouse and the metrics layer — just point the AI straight at Stripe, the bank, and DATEV and start asking questions. You already know why that fails, because I spent a whole post on it. Remember the five data problems:

• The same customer is "Acme" in Stripe, "Acme Corp" in your CRM, and "Acme GmbH" in DATEV.

• Bank transactions have no reference to the invoice they paid.

• Your "current" data is 15 days stale at month-end.

• Your ARR sits in a Notion doc, not a queryable table.

• Three people compute MRR three different ways.

MCP gives an AI live, automated reach into all five of those problems without fixing a single one of them. If anything, it makes them more dangerous, because now the wrong answer arrives in seconds and sounds authoritative. Connecting AI to ungoverned data faster doesn't get you to the truth faster. It gets you to a confident wrong number faster.

So the honest framing is this: MCP is what makes Step 5 easier to wire up and more flexible across vendors. But only the teams that did Steps 1–4 get clean answers out of it. For everyone else, it's a faster path to a number you can't trust.

It doesn't fix your data model either

There's a second trap, and it connects to my data-model post. When I built my cash flow app, the three bugs that quietly broke my numbers were all semantic failures: "type" meant different things in different tabs, income and internal transfers looked identical to the model, and signs were ignored when summing. None of those were connection problems. They were meaning problems.

MCP is a transport standard. It moves structured requests and responses between an AI and a system. It has no opinion whatsoever on whether your "category" field means the same thing everywhere, or whether a transfer is being miscounted as income. If I'd exposed that buggy cash flow app through an MCP server, every one of those three errors would have flowed straight through, untouched, into whatever the AI told me.

This is the same lesson as before, one level up. In the data-model post the line was: AI removes the coding barrier, not the judgment barrier. For MCP, the line is: MCP removes the integration barrier, not the judgment barrier. The person who has to decide what "category" means before the first prompt is the same person who has to decide what an AI agent is allowed to touch once it's connected to live financial systems. Easier access raises the stakes on that judgment — it doesn't remove it.

When MCP genuinely earns its place

None of this is a reason to ignore MCP. Once your foundation is in shape, it's the thing that makes the AI layer actually usable — and for a lean startup finance team, that's real leverage. The use cases worth getting excited about:

• Natural-language access to your trusted numbers. Once your metrics layer gives one answer to "what's our MRR?", MCP is the clean way to put that answer one Slack message away for the whole team — querying the defined metric, not raw Stripe data.

• Pulling a board update together. Verified numbers from your metrics layer, reached via MCP, drafted into a narrative you edit for judgment and tone.

• Answering ad-hoc questions without a spreadsheet detour — provided the questions hit your governed layer, not five raw systems the AI has to reconcile on the fly.

• Reaching the repetitive, rule-based work — categorization support, anomaly flags on the metrics you've already defined.

Notice the pattern: in every good use case, MCP is reaching something you've already made trustworthy. That's the whole game.

Doing it safely (the judgment part)

Because MCP gives an AI a pathway into your financial data — and possibly the ability to act on it — treat it with the same care you'd give to handing someone your bank login. On a lean team, a few rules prevent most of the trouble:

• Start read-only. Let the AI read before it can ever change anything. Reading your revenue is safe; letting an agent move money or edit records is a different risk class — don't start there.

• Keep the dangerous controls with you. Moving money, changing payment details, altering who has access — those stay manual, no matter how convenient automation sounds. An AI drafting a payment is fine; an AI sending one is not.

• Connect only what a use case needs. One or two sources for one clear job. Don't wire up your entire financial life on day one.

• Keep a human in the loop for anything that matters. Reports and drafts can flow freely. Anything that spends money, sends an external message, or changes a record gets your eyes first.

• Watch for instructions hidden in your data. An AI reading a document or email can be tripped up by instructions buried inside that content. Treat it as something that reads your data to inform you — not something that does whatever a document tells it to.

The takeaway

If you came in expecting me to tell you to connect your AI to everything and start asking it questions, you got the opposite — and if you've read my other posts, that won't surprise you. MCP is the last mile, not the first step. It's the connector that makes the AI layer easy and vendor-flexible — but it sits on top of the data foundation, never instead of it. It moves your data; it doesn't give your data meaning. Everything I've written about defining your model first and your KPIs first is what decides whether MCP hands you a real answer or a fast wrong one.

The teams that get the most out of MCP over the next couple of years won't be the ones who connected the most systems the fastest. They'll be the ones whose data was already in shape to be reached — the ones who, once again, got the order right.

Earlier in this series: Design your data model before writing a single line of code and From Spreadsheets to AI: A Head of Finance's Guide to Getting the Order Right. If you want to go deeper on MCP itself, Anthropic's original announcement and the docs at modelcontextprotocol.io are the best primary sources — just check which of your own tools support it before building anything around it.