Provides read-only access to QuickBooks Online data including customers, vendors, invoices, bills, and chart of accounts, allowing AI assistants to query financial information.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@qbo-mcp Find customers with 'Acme' in their name"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
# qbo-mcp
The Model Context Protocol server for QuickBooks Online. Plug Claude into your books — customers, vendors, invoices, bills, and the chart of accounts — read-only, in five minutes.
Roughly seven million businesses keep their books in QuickBooks Online. Intuit publishes a capable REST API but no official MCP server, so every team that wants Claude (or any MCP-aware AI assistant) to see their books ends up writing the same OAuth-and-pagination glue from scratch.
If you use Claude to operate finance day-to-day — chasing AR, sanity-checking AP, prepping for a board update — that gap is the difference between "how much did Acme owe us at the end of March?" working out of the box and "how much did Acme owe us at the end of March?" requiring a custom integration.
qbo-mcp closes that gap. It's a tiny, well-tested, MIT-licensed MCP server that exposes eight read-only QBO endpoints to any MCP client. Built from years of running production QBO automation against real money flow — every edge that surfaced in production (token rotation, 429 backoff, mid-page expiry, query-string escaping) is handled in client.py so you don't have to learn it the hard way.
Related MCP server: qbo-mcp
Wire this server into Claude Code, Claude Desktop, or any MCP host, then ask things like:
"Find every customer matching 'Acme' and show me their balances."
"How much do we owe WidgetCo right now? List the open bills."
"Pull all unpaid invoices created this month and group them by customer."
"What does our chart of accounts look like? List every Bank and Other Current Asset account with its current balance."
"Compare last week's bill volume to the same week last month."
Claude reads your books directly. No copy-paste, no spreadsheets, no custom pipelines.
Tool | What it does |
| Find customers by display name (substring, case-insens). |
| Fetch one customer by Id. |
| Find vendors by display name. |
| Fetch one vendor by Id. |
| List invoices in a date window, optionally open/paid. |
| Fetch one invoice by Id, including line items. |
| List bills in a date window, optionally open/paid. |
| Return the active chart of accounts with balances. |
Write endpoints (create invoice, create bill, post journal entry) are intentionally not in v0.1. They are planned for v0.2 once read-only ergonomics settle. We will not ship a write tool that reaches into your books until the read surface has been beaten on for a release cycle.
pip install qbo-mcpv0.1 ships from this repository. PyPI publication is pending — for now, install with
pip install git+https://github.com/alveyautomation/qbo-mcpor clone and runpip install -e .locally.
QBO uses OAuth 2.0 with rotating refresh tokens. You only do this dance once, then qbo-mcp keeps itself authenticated forever (as long as it runs at least once every 100 days). Total time: about 60 seconds.
Create an app at https://developer.intuit.com/. Pick the Accounting scope. Copy the client_id and client_secret.
Visit the OAuth Playground at https://developer.intuit.com/app/developer/playground. Select your app, pick the environment (Sandbox or Production), and click Get Authorization Code. Sign in to the QuickBooks company you want to expose.
Exchange the code for tokens — the Playground does this for you. Copy:
refresh_token (long string, lasts 100 days of inactivity)
realmId (numeric, identifies your QBO company)
Save them to .env:
QBO_CLIENT_ID=ABxxxxxxxxxxxxxx
QBO_CLIENT_SECRET=xxxxxxxxxxxxxxxx
QBO_REFRESH_TOKEN=ABxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
QBO_REALM_ID=1234567890123456
QBO_ENVIRONMENT=production # or "sandbox"That's it. The first tool call exchanges the refresh token for an access token; subsequent calls reuse the cached access token until it expires (~55 minutes), at which point the client refreshes silently.
Refresh-token rotation: Intuit issues a new refresh token on every refresh and immediately invalidates the old one. If your deployment runs in a single long-lived process, this is invisible. If your deployment restarts often (containers, serverless), persist the rotated token. Subscribe to
QBOClient(on_refresh_token_rotated=…)to capture every rotation. See SECURITY.md for the full story.
Add to ~/.claude/claude_code_config.json (or your project's MCP config):
{
"mcpServers": {
"qbo": {
"command": "qbo-mcp",
"env": {
"QBO_CLIENT_ID": "ABxxxxxxxxxxxxxx",
"QBO_CLIENT_SECRET": "xxxxxxxxxxxxxxxx",
"QBO_REFRESH_TOKEN": "ABxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"QBO_REALM_ID": "1234567890123456",
"QBO_ENVIRONMENT": "production"
}
}
}
}Restart Claude Code. The eight qbo_* tools will appear in any new session.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows) and add the same mcpServers block as above. Restart the desktop app.
Every tool returns a JSON envelope:
{ "ok": true, "data": { ... } }
{ "ok": false, "error": "human-readable message" }qbo_search_customersqbo_search_customers(query: str, limit: int = 50)Substring match against Customer.DisplayName. The query is escaped before embedding into QBO's query language, so apostrophes (O'Brien) and underscores (acme_test) are safe.
Example response:
{
"ok": true,
"data": {
"customers": [
{ "Id": "1001", "DisplayName": "Acme Corp", "Balance": 1250.00 }
],
"count": 1,
"query": "acme",
"limit": 50
}
}qbo_get_customerqbo_get_customer(customer_id: str)Fetches the full customer record by Id. Returns data: null when the Id does not exist (404).
qbo_search_vendors / qbo_get_vendorSymmetric to the customer pair, but against the Vendor entity.
qbo_search_invoicesqbo_search_invoices(
date_from: str, # ISO date "YYYY-MM-DD"
date_to: str, # ISO date "YYYY-MM-DD"
status: str | None = None, # "open" | "paid" | None
limit: int = 200, # max 2000
)Window is inclusive on Invoice.TxnDate. The status filter is a convenience over QBO's Balance field — "open" returns invoices with Balance > 0, "paid" returns invoices with Balance = 0.
Pagination is handled transparently: QBO's query endpoint requires explicit STARTPOSITION / MAXRESULTS clauses, and the client walks pages until either limit is reached or the upstream returns a short page. The response includes limit_reached: true when limit was the stopping condition.
qbo_get_invoiceqbo_get_invoice(invoice_id: str)Returns the full invoice record (with Line[]), or data: null for a 404.
qbo_search_bills / qbo_get_invoice parityqbo_search_bills mirrors qbo_search_invoices but against the Bill entity (vendor-side). Same date semantics, same status filter.
qbo_get_chart_of_accountsqbo_get_chart_of_accounts()Returns every active account in the realm. Each record includes Id, Name, AccountType, AccountSubType, Classification, and CurrentBalance among other QBO fields. Useful for grounding any "where did this transaction post?" question.
git clone https://github.com/alveyautomation/qbo-mcp
cd qbo-mcp
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e ".[dev]"
pytest # 50+ tests, ~3sPre-commit hooks (gitleaks, trufflehog, ruff, formatter, tenant-fingerprint scrubber):
pip install pre-commit
pre-commit installIntegration tests against a real QBO sandbox realm are gated behind QBO_INTEGRATION_TESTS=1. They are not required for normal contribution.
Failed to refresh QBO access token — refresh token has been rotated out from under you, or the app's client_id / client_secret is wrong. Refresh tokens are invalidated as soon as a new one is issued, so if two processes share a refresh token, whichever one refreshes first wins. Solution: persist rotated tokens (see on_refresh_token_rotated) or run only one server per refresh-token credential.
Missing required environment variables — the server tried to start before its .env was loaded. Either export the vars in the parent shell, or ensure your MCP host config includes them in the env block.
Empty results despite known data — confirm QBO_ENVIRONMENT matches the credential. A sandbox refresh token against the production API host (or vice versa) will authenticate but return an empty company.
Slow large date windows — QBO's query endpoint paginates at a hard cap of 1000 rows per page. The client walks pages transparently, but a 5-year invoice scan still means many round-trips. Consider tightening date_from / date_to or filtering by status.
Transient QBO error: HTTP 429 — Intuit's rate limiter kicked in. The client retries automatically with exponential backoff; if you see this surface in tool output, you've exceeded the configured QBO_MAX_RETRIES. Bump it or slow down your queries.
Issues and pull requests welcome. Please:
Run pytest before opening a PR (pip install -e ".[dev]").
Run pre-commit run --all-files.
Keep additions to v0.1 scope read-only. Write endpoints land in v0.2.
Synthetic data only in tests — no real customer names, vendor names, or realm IDs.
MIT — see LICENSE.
qbo-mcp is an unofficial, third-party integration. It is not endorsed by, affiliated with, or supported by Intuit Inc. "QuickBooks" and "QuickBooks Online" are trademarks of Intuit Inc. Use at your own risk; verify behavior against your realm before depending on it for production decisions.
Return the full chart of accounts (active only).
Returns:
JSON envelope. data.accounts is the list of account records,
each carrying Id, Name, AccountType, AccountSubType,
Classification, and CurrentBalance among other QBO fields.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden for behavioral disclosure. It mentions 'active only' filtering and the return envelope structure, which adds some value, but lacks details on authentication, rate limits, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that front-load the purpose and immediately provide useful details about the return format. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list retrieval tool with no parameters and an output schema, the description adequately covers purpose and return structure. However, it could mention any potential limits or authentication requirements for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. The description does not need to explain parameters, and the baseline for no params is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and resource 'full chart of accounts', and specifies that it returns only active accounts, distinguishing it from siblings that focus on individual entities like customers or invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusion criteria. The decision must be inferred from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full record for a single customer.
Args: customer_id: QBO Customer.Id (string-encoded integer per Intuit's API).
Returns:
JSON envelope. data is the customer record, or null on 404.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return envelope structure and that null is returned on 404, but lacks detail on side effects, auth needs, or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only three lines covering purpose, argument, and return behavior. It is well-structured using Args/Returns labels, and every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is complete: it specifies the input, the output envelope, and the null case. An output schema exists (as per signals) so detailed return fields are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant value by specifying that customer_id is a 'string-encoded integer per Intuit's API'. This clarifies the expected format beyond the schema's simple type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the full record for a single customer' with a specific verb and resource. It is distinct from sibling tools which target different entities (e.g., invoices, vendors) or search variants, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs a complete customer record by ID. While no explicit when-not or alternatives are given, the context is clear and the sibling tools cover other resources, so it adequately guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full invoice detail including line items.
Args: invoice_id: QBO Invoice.Id.
Returns:
JSON envelope. data is the invoice record, or null on 404.
| Name | Required | Description | Default |
|---|---|---|---|
| invoice_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a read operation returning null on 404, which is helpful. However, it omits any mention of permissions, rate limits, or side effects beyond the basic retrieval behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but structured with Args and Returns sections, and the main purpose is front-loaded. No extraneous text. It earns a high score for efficiency, though could be slightly more terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema (though not shown), the description covers the key behavior: fetching full details, handling 404, and the return envelope. It is complete enough for an agent to understand the tool's basic role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description states 'invoice_id: QBO Invoice.Id,' adding meaning that it is the identifier type. This partially compensates for the lack of schema descriptions, but no further details on format or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch full invoice detail including line items,' which is a specific verb and resource. It distinguishes from sibling tools like qbo_search_invoices (for listing) and qbo_get_customer (for different resource) by targeting a single invoice retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have an invoice_id and need full details, but it does not explicitly contrast with search_invoices or provide when-not-to-use scenarios. No explicit guidance on alternatives is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full record for a single vendor.
Args: vendor_id: QBO Vendor.Id.
Returns:
JSON envelope. data is the vendor record, or null on 404.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return format (JSON envelope with 'data'), specifies null on 404, and implies read-only behavior. This provides sufficient transparency, though could mention idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus structured Args/Returns, front-loading the main purpose. Every sentence adds value with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still provides essential details (null on 404) and parameter clarification. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds 'QBO Vendor.Id' to clarify the vendor_id parameter. This explains the exact value required, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the full record for a single vendor', specifying the action, resource, and scope. It distinguishes from sibling QBO tools like qbo_search_vendors by focusing on a single vendor retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a vendor ID is available, but does not explicitly state when to use this tool versus alternatives like qbo_search_vendors. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search vendor bills with TxnDate in [date_from, date_to] inclusive.
Args: date_from: ISO date (YYYY-MM-DD), start of TxnDate window. date_to: ISO date (YYYY-MM-DD), end of TxnDate window. status: Optional balance filter. "open" returns bills with a non-zero balance; "paid" returns bills with Balance == 0. Omit (null) for both. limit: Cap on yielded bills (1-2000, default 200).
Returns:
JSON envelope. data.bills is the list of bill records.
| Name | Required | Description | Default |
|---|---|---|---|
| date_from | Yes | ||
| date_to | Yes | ||
| status | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format ('JSON envelope. data.bills'), inclusive date range, optional status filter, and limit cap. This is fairly transparent for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, but a bit verbose (7 lines). It is efficient enough and front-loads key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so description needn't detail return values, but it does mention the envelope. It covers all parameters and their constraints. Missing explicit error handling or pagination, but adequate for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates fully. It explains date_from and date_to as ISO dates with inclusive window, status options (open/paid/null), and limit range (1-2000, default 200), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches vendor bills with a date range, specifying the resource and action. It distinguishes from siblings like qbo_search_invoices by focusing on bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (search bills by date range) and provides details on the status filter. It lacks explicit when-not-to-use or alternatives, but the context from sibling tools is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search customers by display name (substring, case-insensitive).
Args:
query: Free-text fragment matched against Customer.DisplayName
via QBO's LIKE '%query%' operator.
limit: Cap on returned customers (1-1000, default 50).
Returns: JSON envelope: {"ok": true, "data": {"customers": [...], "count": N}}.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the underlying LIKE operator and return envelope. No mention of authentication or rate limits, but these are less critical for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus structured Args/Returns. It is front-loaded with the purpose and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still provides the return structure (JSON envelope) which is helpful. All aspects of the tool are addressed: purpose, parameters, and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds full context: query is matched via LIKE operator, limit has range 1-1000 and default 50. This adds significant meaning beyond the schema's type declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search customers by display name (substring, case-insensitive)', specifying the verb, resource, and matching method. This distinguishes it from siblings like qbo_search_bills which search different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameters and their behavior, but does not explicitly state when to use this tool over alternatives. However, sibling tools operate on different entities, so usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search invoices created in [date_from, date_to] inclusive.
Args: date_from: ISO date (YYYY-MM-DD), start of TxnDate window. date_to: ISO date (YYYY-MM-DD), end of TxnDate window. status: Optional balance filter. "open" returns invoices with a non-zero balance; "paid" returns invoices with Balance == 0. Omit (null) for both. limit: Cap on yielded invoices (1-2000, default 200).
Returns:
JSON envelope. data.invoices is the list of invoice records.
| Name | Required | Description | Default |
|---|---|---|---|
| date_from | Yes | ||
| date_to | Yes | ||
| status | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It explains the status filter semantics (open vs paid) and return structure, but it does not disclose side effects, authentication needs, rate limits, or whether the operation is read-only. The description adds marginal behavioral context beyond the parameter list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections (Args and Returns). Each sentence adds necessary information without redundancy. It efficiently covers parameters and output structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description covers parameter semantics and return envelope. It lacks details on pagination, sorting, or error handling, but the output schema likely fills some gaps. For a search tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the meaning, format, and defaults for all parameters: ISO dates for date_from/date_to, status optional values, limit cap and default. This adds significant meaning beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches invoices by date range using 'Search invoices created in [date_from, date_to] inclusive.' It clearly identifies the resource (invoices) and action (search). However, it does not explicitly distinguish from sibling tools like qbo_search_bills, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as qbo_get_invoice (single invoice) or qbo_search_bills (bills). There is no 'when-to-use' or 'when-not-to-use' language.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search vendors by display name (substring, case-insensitive).
Args: query: Free-text fragment matched against Vendor.DisplayName. limit: Cap on returned vendors (1-1000, default 50).
Returns: JSON envelope: {"ok": true, "data": {"vendors": [...], "count": N}}.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and adequately discloses the search behavior: substring, case-insensitive matching on DisplayName. It also specifies the return envelope format. However, it omits potential error conditions or limitations beyond the cap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose followed by structured Args and Returns sections. Every sentence adds value without redundancy, ideal for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects) and the presence of an output schema (with return format described), the description covers the complete input-output contract. It includes the query behavior, parameter defaults, and response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter: 'Free-text fragment matched against Vendor.DisplayName' for query and 'Cap on returned vendors (1-1000, default 50)' for limit, adding essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Search vendors by display name (substring, case-insensitive)', providing a specific verb and resource with search criteria. It naturally distinguishes from sibling tools like qbo_get_vendor (single vendor fetch) and qbo_search_customers (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as qbo_get_vendor, qbo_search_customers, or qbo_search_invoices. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0qbo_get_chart_of_accountsqbo_get_customerqbo_get_invoiceqbo_get_vendorqbo_search_billsqbo_search_customersqbo_search_invoicesqbo_search_vendorsScored across 8 tools
Each tool targets a distinct entity or operation: get tools retrieve single records by ID, search tools list with filters, and chart of accounts is a separate list. No overlap in purpose.
All tools follow the consistent pattern `qbo_<verb>_<noun>` where verb is `get_` or `search_`, and nouns are plural for search (customers, vendors, invoices, bills) and singular or collective for get (customer, invoice, vendor, chart_of_accounts).
8 tools cover core QBO entities (accounts, customers, vendors, invoices, bills) without being overwhelming. The count is well-scoped for a focused accounting server.
Only read operations are provided (get and search). Missing critical mutation tools (create, update, delete) for any entity, which severely limits the server's utility for typical accounting workflows.
QuickBooks Online in Claude and ChatGPT: 221 tools, full ledger, multi-company, Canada + US, FR/EN.
QuickBooks MCP Pack — query customers, invoices, and accounts via QuickBooks Online API.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
