What MCP Actually Is, Explained for Accountants

You have probably seen “MCP” appear in software announcements over the last year, usually in a sentence assuming you already know what it means. It stands for Model Context Protocol, which does not help much.

Here is the version that matters for a firm: MCP is the plumbing that lets an AI assistant read data out of the software you already use, live, without you copying anything. That is genuinely all it is. The rest of this post is why that turns out to matter more than it sounds.

The problem it solves

Until recently, getting an AI assistant to help with a client’s books meant moving the books to the assistant. Export a CSV, paste it into the chat, ask your question.

That workflow has three problems that compound. It is manual, so it only happens when the question is worth the effort. It is stale the moment you export, so an answer about “this month” is really about the month as of whenever you last exported. And it is over-broad, because filtering an export down to what the question needs is work, so you paste the whole register and hand over twelve months to answer a question about one.

MCP inverts it. Rather than moving data to the assistant, you give the assistant permission to ask the software for what it needs, when it needs it.

An analogy that holds up

MCP is doing for AI assistants roughly what “Sign in with Google” did for websites.

Before that existed, every site invented its own login. It worked, but there was no shared standard, so every integration was bespoke. Once OAuth settled, connecting a new service became a thirty-second approval screen instead of a project.

MCP is that, for tool access. Before it, if Claude wanted to read your receipt tracker, someone had to build a one-off integration for that specific pairing. With MCP, the receipt tracker implements the standard once, and every assistant that speaks MCP can connect — Claude, ChatGPT, whatever launches next year. That is why adoption moved quickly: vendors build one thing rather than one per assistant.

What a connection actually looks like

From your side it is an approval screen. You go to your assistant’s settings, add the integration, paste an address, and log in with the account you already have. The assistant then shows you what it is being granted.

Underneath, the vendor has told the assistant which specific operations it may perform. Ours exposes things like “list receipts,” “get a book summary,” and “check reconciliation status.” The assistant can call those and nothing else — it does not get a general key to the database, and it cannot invent an operation the vendor did not define.

This is the part worth internalizing, because it is what makes the security question answerable. The assistant’s access is a list of specific, named capabilities, not a login to your account. If “delete a receipt” is not on the list, no amount of clever prompting produces a deleted receipt.

Read versus write

Tools split into two kinds, and the distinction deserves more attention than it usually gets.

Read tools fetch information. Worst case, the assistant retrieves something and describes it wrongly — annoying, correctable, visible.

Write tools change your data. Worst case is different in kind: a plausible, confident, wrong change that sits in the books looking correct until someone reconciles months later.

Our integration is read-only, and write tools will be opt-in when they arrive. When you evaluate any vendor’s MCP support, the first question is which kind they have shipped, and whether write access is on by default. A vendor that quietly enabled write tools has made a decision about your risk without asking.

What to ask a vendor

Every tool in your stack is going to announce MCP support over the next couple of years. Five questions separate a serious implementation from a checkbox:

• Read-only or read-write? If write, is it opt-in, and can it be left off permanently?
• How is access revoked, and how fast does it take effect? “Contact support” is the wrong answer. It should be a button in settings.
• Does data flow through the vendor’s servers or straight from the source? Fewer parties handling client data is better.
• Is there a log of what the assistant accessed? You may need to reconstruct this later.
• On a multi-client plan, does client consent gate the connection? An advisor should not gain access to a client’s records without that client agreeing.

What it does not do

Worth being clear, because the marketing around this gets loose.

MCP does not make the assistant smarter or more accurate. It changes what the assistant can see, not how well it reasons about what it sees. An assistant with live access to bad data gives you confident answers built on bad data, faster than before.

It does not replace your accounting software, and it does not file anything. It is a connection, not a product.

And it does not remove your review obligation. Everything an assistant produces from connected data is a draft. The connection makes assembling the draft nearly free; it does not make checking it optional.

Why this matters sooner for small firms

The firms adopting this fastest are not the large ones. They are solo bookkeepers and three-person practices, for a straightforward reason: no procurement committee, no IT review, no eighteen-month software cycle. One person decides on a Tuesday and is using it Wednesday.

That is an unusual position for small firms to be in. The technology advantage normally runs the other way. For the next couple of years, the practice that can answer a client’s question in the time it takes to type it has an edge over the one still exporting to a spreadsheet — and the edge is available to whoever picks it up, not whoever spends the most.