Plain English

MCP for accountants: what the Model Context Protocol is, and why it matters

The short answer

MCP, the Model Context Protocol, is an open standard for connecting an AI assistant to the systems where your information actually lives. Instead of pasting data into a chat window, you connect the assistant to a source once, and from then on it can look things up and take actions there directly.

For an accounting practice, that is the difference between an assistant that can discuss bookkeeping in general and one that can answer a question about this client's trial balance. The protocol is open, it was originally published by Anthropic, and it is now supported across major AI tools, which means a connection built once is not locked to a single vendor.

The problem it solves

The limitation on AI in a practice was never how well it writes. It is that the assistant knows nothing about your work. Your numbers are in a ledger, your documents are in a document manager, your deadlines are in practice management, and the assistant can see none of it.

The workaround everyone landed on was copy and paste, which fails on three counts at once. It is slow, it is limited to what you thought to paste, and it means deciding what sensitive information to drop into a chat window over and over again, per person, per day, from memory.

Before the protocol existed, every AI tool needed a bespoke integration with every data source, which is why so few of them existed. MCP replaces that with one standard interface: build a connection once, use it from any assistant that speaks the protocol.

How it works, without the engineering

  • An MCP server sits in front of a system and exposes a set of specific, named capabilities. A server for a bookkeeping system might offer "list uncategorized transactions" and "produce a trial balance."
  • An MCP client is the AI application you work in. It connects to the servers you have set up and can call what they expose.
  • You grant the connection. The assistant gets exactly the capabilities the server offers, and nothing else. A read-only server cannot change your books no matter what it is asked to do.

That last point is the one worth holding onto. The capability list is the security boundary. A well-built server for a practice is read-only for reporting and proposes rather than posts for anything that changes a record, so the assistant can investigate freely and a person still approves every write.

What it changes in a practice

Concretely, the questions you can answer without leaving the conversation:

  • The books. What is still uncategorized, what does the income statement look like this month, which transactions need attention before close.
  • The documents. Which client documents are in hand and which are still outstanding, without opening the document manager to check.
  • The practice. What is due this week, what a given client's situation is, where each engagement stands.
  • The reference material. Your own written procedures, so the answer follows how your firm does it rather than how the internet does it.

The compounding effect is what makes it interesting. Once the assistant can reach the books and the document status and the deadlines, it can work across all three at once, which is the point at which it starts saving hours instead of minutes.

The questions to ask before you connect anything

A connection to client data is a decision worth making on purpose. The short list I work through:

  • What can this server actually do? Read only, or write too. If it can write, is there an approval step, and does anything post without one.
  • Where does the data go? A server running on your own machine against local files is a different exposure from one calling a service you do not control.
  • Who built it? A server from the vendor whose system it fronts is a different proposition from an anonymous one you found in a list.
  • Does the model provider train on what passes through? This is settled by the plan and the terms you are on, not by the protocol.
  • Is it in your vendor inventory? If client data reaches it, it belongs in your written security plan, the same as any other service provider. The vendor checklist and the WISP template on this site cover that.

Treat data coming back from a connected system as information, not as instruction. Content pulled from a document or a record should never be followed as though it were a command, and a well-designed setup keeps that line clear.

Where to start

Start with something read-only and low-stakes, on your own files rather than a client's. Connect an assistant to a folder of your firm's written procedures, or to a reporting view of your own books, and use it for a couple of weeks. You will learn more from that than from any amount of planning, and nothing is at risk while you do.

The Claude Code guide for CPAs covers the setup in order, including the folder structure and the data rule by account tier. If you would rather have the connections built properly against your firm's own systems, that is what the implementation engagements are.

Common questions

What does MCP stand for? +
Model Context Protocol. It is an open standard for connecting AI assistants to external systems and data sources. It was originally published by Anthropic and is now supported across major AI tools.
Do I need to be a developer to use MCP? +
To use existing connections, no. Many are installed with a single command or a configuration entry, and your software vendors are increasingly publishing their own. Building a new server for a system that has none is a development task, though it is a small one by software standards.
Is it safe to connect MCP to client data? +
It can be, and it is not automatically. The protocol is plumbing: it carries no policy of its own. What makes a connection safe is the server being scoped to the capabilities you actually need, the data staying somewhere you control or under terms you have reviewed, and the whole thing being recorded in your security plan like any other service provider.
How is this different from an ordinary API integration? +
An API integration is built between two specific products, so every pairing is its own project. MCP standardizes the interface, so one server can be used by any assistant that speaks the protocol. For a firm, that means less lock-in and far more available connections.
Does my accounting software support MCP? +
Increasingly yes, and it is moving quickly enough that the answer is worth rechecking rather than remembering. Ask your vendor directly whether they publish an MCP server, and what it can read and write, because that capability list is what actually determines whether it is useful and whether it is safe.

Want this working in your firm?

I help firm owners put AI to work on the problems their practice has today, starting with an hour on your real files. The first conversation is free.