QuickBooks MCP server: what it does, what it can't, and how to set it up

Key points

• The official server is Intuit's own open-source repo. It runs as a local stdio process on your machine, not as a hosted service.
• It reads and writes by default. Create, update and delete tools are on unless you switch them off with three environment flags.
• Hosted alternatives exist from Zapier, Pipedream, Composio and CData, each with its own auth model and tool set.
• MCP connects a model to QuickBooks. It does not control what the model does. Approvals, run records and safe retries sit outside the protocol.
• For production books, keep the controls in the workflow, not in the prompt.

What QuickBooks MCP servers exist today?

Five options cover most QuickBooks MCP searches: Intuit's official server, plus hosted or packaged versions from Zapier, Pipedream, Composio and CData. They differ in where they run, how they authenticate, and whether they can write.

Community builds are also listed in MCP directories. Check who maintains a server before you give it a production refresh token.

What can the Intuit QuickBooks MCP server actually do?

The Intuit server exposes QuickBooks Online records as MCP tools named {verb}_{entity}, plus 11 report tools. Read tools (get_, search_) are always on. Create, update and delete tools are on by default. Every tool below comes from the repo's README.

The README's entity table also lists Estimate, Employee, Account, Item, Journal Entry and Purchase as supported entities.

What this is good for: asking questions of your books in plain language. "Which customers are more than 60 days past due?" maps cleanly to get_aged_receivables. "Pull last quarter's P&L by month" maps to get_profit_and_loss. Read-only, against a sandbox or a scoped company, this is low-risk and useful.

What can't the QuickBooks MCP server do?

The QuickBooks MCP server gives a model access to QuickBooks. It does not decide who may approve a write, record why a write happened, or make a multi-step sequence safe. Those four gaps are where finance teams get hurt.

1. Writes are on or off, not scoped. The three flags (QUICKBOOKS_DISABLE_WRITE, QUICKBOOKS_DISABLE_UPDATE, QUICKBOOKS_DISABLE_DELETE) switch whole categories off for the whole server. The README describes no per-tool, per-amount or per-user limit. If create_bill_payment is on, it is on for any amount.

2. There is no approval step. The server runs a tool when the client calls it. The MCP specification says clients should show confirmation prompts and keep a human able to deny tool calls, but that is a client behavior and a recommendation, not a guarantee. A confirmation click from the person chatting is also not an approval under your delegation of authority. The approver and the requester are the same person.

3. There is no run-level audit trail. QuickBooks' own audit log records the change: the date, the user, the event, and changes made by connected third-party apps. It keeps events for two years and cannot be turned off. It does not record the instruction that led to the change, the tool call, or who approved it. The MCP specification says clients should log tool usage for audit purposes. The Intuit server's README describes no log of its own.

4. There is no notion of a run. Each tool is one operation on one entity or one report. The model selects and orders the calls at runtime. If an agent creates an invoice, applies a payment, and then fails on the third step, the README describes no rollback, so the first two writes stay in the books. Nothing in the README describes a duplicate check before a create_ call, so a retried step can post the same transaction twice.

Two smaller limits are worth knowing. One configuration connects to one QuickBooks Online company (one QUICKBOOKS_REALM_ID). And "delete" often means "void" for transactions such as invoices, payments, sales receipts and credit memos.

How do you set up the QuickBooks MCP server?

Setup takes an Intuit developer app, a one-time OAuth handshake, and an entry in your MCP client's config. Intuit does not offer per-user API keys, so even read-only access to your own company needs an app. Start in sandbox, read-only.

1. Create an app on the Intuit Developer Portal. Copy the Client ID and Client Secret from Keys & Credentials (development keys for sandbox).
2. Add a redirect URI. Sandbox accepts http://localhost:8000/callback. Production rejects localhost and needs a public HTTPS callback for the first handshake. The README's common workaround is an ngrok tunnel, used only for that handshake.
3. Create or pick a sandbox company under the portal's Sandbox menu.
4. Clone and build the server.

   git clone https://github.com/intuit/quickbooks-online-mcp-server.git
   cd quickbooks-online-mcp-server
   npm install
   npm run build

5. Configure .env. Copy .env.example to .env and set QUICKBOOKS_CLIENT_ID, QUICKBOOKS_CLIENT_SECRET, QUICKBOOKS_ENVIRONMENT=sandbox. Set all three QUICKBOOKS_DISABLE_* flags to true for a read-only first run.
6. Run npm run auth. Your browser opens, you sign in to the sandbox company, and the refresh token and realm ID are saved to .env. Refresh tokens rotate, and the server writes each new one back.
7. Register the server with your MCP client. For Claude Code, add an entry under mcpServers with "command": "node", the path to dist/index.js, and the same environment variables in its env block.
8. Test with reads. Ask for an aged receivables report or a customer search. Confirm the numbers against QuickBooks before you trust them.
9. Turn on writes deliberately. Flip one flag at a time, in sandbox first. Write down who may use a write-enabled client against production.

Three things trip people up. The redirect URI must match exactly (protocol, host, port, path). On a read-only filesystem, set QUICKBOOKS_TOKEN_STORE_PATH to an absolute, writable path in the host process environment, not in .env. The server keeps running without a browser until the 100-day refresh window lapses, then needs a new handshake.

Where does MCP leave a finance-controls gap, and how does Loopfour close it?

MCP is a connection layer, not a control layer. It answers "can the model reach QuickBooks?" It does not answer "should this write happen, who approved it, and what did the run do?" Auditors ask the second set of questions.

An AI agent decides what to do at runtime. Loopfour does only what was approved.

Loopfour, the deterministic finance workflow automation platform, connects to QuickBooks through its own integration and runs finance workflows as versioned, approved steps. AI handles the parts that need interpretation (reading an invoice PDF, classifying a line). Everything that touches the ledger runs as fixed, programmatic steps. Loopfour is a managed service: we build the workflow, run it, and maintain it.

A typical flow: vendor invoice arrives → line items extracted → approval in Slack → bill posted to QuickBooks → run record kept. The model never holds a write-enabled QuickBooks token. The workflow does, and it only runs the steps that were approved. Some QuickBooks writes need extra care even inside a workflow. Bills, for example, have no DocNumber upsert, so the workflow has to own idempotency (connecting QuickBooks vendor bills).

Loopfour does not ship an MCP server today. Its workflows run on QuickBooks, NetSuite, Stripe and the other integrations now, triggered by a schedule, an event, a person, or an API call. Native MCP support for Loopfour workflows is coming soon.

Go deeper

For how MCP fits a full finance stack (hosts, clients, servers, MCP vs API vs iPaaS, and where approvals belong), read how financial workflow MCP connects AI to ERP and accounting systems with approvals and an audit trail. For the NetSuite equivalent, see what the NetSuite MCP server can and cannot do.