Skip to main content
QuBe Sync runs a public Model Context Protocol server at:
Connect an AI coding agent to it and the agent knows QuickBooks Desktop the way QuBe Sync does: every operation and field, the errors each one can raise, the webhook your app will receive, and how to write a workflow. It works for anything from “how do I find inactive vendors?” to building your whole integration.

​
Connect your agent

The server speaks Streamable HTTP and needs no authentication.

​
What it can do

The server never touches a QuickBooks connection and never needs an API key. Its tools check parameters, build requests and validate charts, and your agent sends what they build with your key. So there is nothing for the server to leak.

261 operation tools

One per QuickBooks operation: find_customers, create_invoice, update_vendor, record_payment, execute_txn_void… Each checks the arguments against QuickBooks’ schema and returns the API request that runs it.

4 workflow tools

get_workflow_authoring_guide, validate_workflow_chart, list_workflow_templates and get_workflow_template: everything an agent needs to write a workflow and check it. Runs start only on realtime and simulated connections.
Three more are hand-written. match_records builds a match: the request that finds the record a name means in a customer’s company file, POST /api/v2/connections/{connection_id}/matches, checked the way the API checks it, with the answer’s schema and what each tier means. Like the operation tools it never touches a connection, so the agent sends the request with your key. And report_confusion lets an agent tell us when a tool, guide or API response confused it, without sending any keys or customer data. We read those reports to improve the tools. Last, get_integration_checklist returns the integration checklist: every rule an integration has to get right, or one area’s with area, each with what to check in the code, so an agent writing or reviewing your webhook handler has them to hand.

​
What an operation tool returns

Calling create_customer with a name and email returns the request to send, ready to use:
structuredContent
​
string, string, object
The API call, with query for a GET or body. Swap in a real connection_id, add your webhook_url, and send it with your API key.
​
object
Send them too. Each call of a tool gives a fresh Idempotency-Key, so if the 201 never arrives, the same request sent again, key and all, answers with the request already queued instead of queueing a second one. See Retrying a call safely.
​
object
The JSON Schema of the webhook the answer will arrive in, including this operation’s own data and every QuickBooks status code it can fail with, each with what it means and what to do.
The text content repeats the same as a ready-to-run curl command, plus a short guide to handling each webhook state and the rest of the operation’s notes from Intuit’s qbXML reference. The tool’s description carries only their opening paragraph, since a client loads every tool’s description at once. So an agent writing your webhook handler gets the data shape and the error cases from the same call that built the request. Pass "include_qbxml": true to also see the qbXML QuBe Sync will send QuickBooks. That’s for curiosity and debugging only: your app always sends JSON. validate_workflow_chart runs the same checks as POST /api/v2/workflows/validate, except the ones that need your app: the server never has your API key, so it can’t see your workflows. Pass the chart as chart, a JSON object or a string holding one, and the keys of the workflows your app already has as known_workflows. A workflow state that calls a key not in that list is a warning rather than an error, and the key is listed in workflows_to_create: create those in your app before you push this chart, because saving it there checks that each one exists and takes the input you pass. The result is {valid, errors, warnings, workflows_to_create}, and each error or warning has a path into the chart and a message. Errors block saving; warnings are likely mistakes worth a look.

​
Pair it with the CLI

The MCP server tells your agent what to send. The qube CLI lets it send it safely: log in yourself with the default sandbox scope, and your agent can create a simulated connection, run the requests it built, inject faults, and push the workflows it wrote, without ever seeing a secret or a production app.

​
Calling it directly

It’s plain JSON-RPC over POST, so curl works for scripting or debugging. (A GET answers 405.) tools/list returns 100 tools per page. The first page starts with the workflow tools, report_confusion, match_records and get_integration_checklist, then the operations in alphabetical order. Pass nextCursor back as params.cursor for the rest.
The server is public, so don’t send it real customer data. Use it to explore and build requests, then send them yourself with your API key.