El servidor del Protocolo de Contexto de Modelo (MCP) para QuickBooks Online. Conecta Claude a tu contabilidad —clientes, proveedores, facturas, recibos y el plan de cuentas— en modo de solo lectura, en cinco minutos.
Aproximadamente siete millones de empresas llevan su contabilidad en QuickBooks Online. Intuit publica una API REST capaz, pero no un servidor MCP oficial, por lo que cada equipo que quiere que Claude (o cualquier asistente de IA compatible con MCP) vea sus libros termina escribiendo desde cero el mismo código de pegamento para OAuth y paginación.
Si utilizas Claude para gestionar las finanzas del día a día —perseguir cuentas por cobrar, verificar cuentas por pagar, preparar actualizaciones para la junta directiva—, esa brecha es la diferencia entre que "¿cuánto nos debía Acme a finales de marzo?" funcione de inmediato y que "¿cuánto nos debía Acme a finales de marzo?" requiera una integración personalizada.
qbo-mcp cierra esa brecha. Es un servidor MCP pequeño, bien probado y con licencia MIT que expone ocho endpoints de solo lectura de QBO a cualquier cliente MCP. Construido a partir de años de ejecutar automatización de QBO en producción contra flujos de dinero reales; cada caso extremo que surgió en producción (rotación de tokens, retroceso 429, caducidad a mitad de página, escape de cadenas de consulta) se maneja en client.py para que no tengas que aprenderlo por las malas.
Related MCP server: qbo-mcp
Conecta este servidor a Claude Code, Claude Desktop o cualquier host MCP, y luego pregunta cosas como:
"Busca todos los clientes que coincidan con 'Acme' y muéstrame sus saldos."
"¿Cuánto le debemos a WidgetCo ahora mismo? Enumera las facturas pendientes."
"Extrae todas las facturas impagadas creadas este mes y agrúpalas por cliente."
"¿Cómo es nuestro plan de cuentas? Enumera todas las cuentas bancarias y de otros activos corrientes con su saldo actual."
"Compara el volumen de facturas de la semana pasada con la misma semana del mes anterior."
Claude lee tus libros directamente. Sin copiar y pegar, sin hojas de cálculo, sin tuberías personalizadas.
Herramienta | Qué hace |
| Busca clientes por nombre visible (subcadena, sin distinguir mayúsculas/minúsculas). |
| Obtiene un cliente por Id. |
| Busca proveedores por nombre visible. |
| Obtiene un proveedor por Id. |
| Enumera facturas en un rango de fechas, opcionalmente abiertas/pagadas. |
| Obtiene una factura por Id, incluyendo partidas individuales. |
| Enumera recibos en un rango de fechas, opcionalmente abiertos/pagados. |
| Devuelve el plan de cuentas activo con saldos. |
Los endpoints de escritura (crear factura, crear recibo, publicar asiento de diario) están intencionalmente no incluidos en la v0.1. Están planificados para la v0.2 una vez que la ergonomía de solo lectura se estabilice. No lanzaremos una herramienta de escritura que acceda a tus libros hasta que la superficie de lectura haya sido probada durante un ciclo de lanzamiento.
pip install qbo-mcpLa v0.1 se envía desde este repositorio. La publicación en PyPI está pendiente; por ahora, instala con
pip install git+https://github.com/alveyautomation/qbo-mcpo clona y ejecutapip install -e .localmente.
QBO utiliza OAuth 2.0 con tokens de actualización rotativos. Solo haces este proceso una vez, luego qbo-mcp se mantiene autenticado para siempre (siempre que se ejecute al menos una vez cada 100 días). Tiempo total: unos 60 segundos.
Crea una aplicación en https://developer.intuit.com/. Elige el ámbito Accounting. Copia el client_id y el client_secret.
Visita el OAuth Playground en https://developer.intuit.com/app/developer/playground. Selecciona tu aplicación, elige el entorno (Sandbox o Producción) y haz clic en Get Authorization Code. Inicia sesión en la empresa de QuickBooks que deseas exponer.
Intercambia el código por tokens: el Playground lo hace por ti. Copia:
refresh_token (cadena larga, dura 100 días de inactividad)
realmId (numérico, identifica tu empresa de QBO)
Guárdalos en .env:
QBO_CLIENT_ID=ABxxxxxxxxxxxxxx
QBO_CLIENT_SECRET=xxxxxxxxxxxxxxxx
QBO_REFRESH_TOKEN=ABxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
QBO_REALM_ID=1234567890123456
QBO_ENVIRONMENT=production # or "sandbox"Eso es todo. La primera llamada a la herramienta intercambia el token de actualización por un token de acceso; las llamadas posteriores reutilizan el token de acceso en caché hasta que caduca (~55 minutos), momento en el cual el cliente se actualiza silenciosamente.
Rotación de tokens de actualización: Intuit emite un nuevo token de actualización en cada actualización e invalida inmediatamente el anterior. Si tu despliegue se ejecuta en un único proceso de larga duración, esto es invisible. Si tu despliegue se reinicia a menudo (contenedores, serverless), persiste el token rotado. Suscríbete a
QBOClient(on_refresh_token_rotated=...)para capturar cada rotación. Consulta SECURITY.md para conocer la historia completa.
Añade a ~/.claude/claude_code_config.json (o a la configuración MCP de tu proyecto):
{
"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"
}
}
}
}Reinicia Claude Code. Las ocho herramientas qbo_* aparecerán en cualquier sesión nueva.
Edita ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) o %APPDATA%\Claude\claude_desktop_config.json (Windows) y añade el mismo bloque mcpServers que arriba. Reinicia la aplicación de escritorio.
Cada herramienta devuelve un sobre JSON:
{ "ok": true, "data": { ... } }
{ "ok": false, "error": "human-readable message" }qbo_search_customersqbo_search_customers(query: str, limit: int = 50)Coincidencia de subcadena con Customer.DisplayName. La consulta se escapa antes de incrustarse en el lenguaje de consulta de QBO, por lo que los apóstrofes (O'Brien) y los guiones bajos (acme_test) son seguros.
Ejemplo de respuesta:
{
"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)Obtiene el registro completo del cliente por Id. Devuelve data: null cuando el Id no existe (404).
qbo_search_vendors / qbo_get_vendorSimétrico al par de clientes, pero contra la entidad Vendor.
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
)La ventana es inclusiva en Invoice.TxnDate. El filtro status es una conveniencia sobre el campo Balance de QBO: "open" devuelve facturas con Balance > 0, "paid" devuelve facturas con Balance = 0.
La paginación se maneja de forma transparente: el endpoint de consulta de QBO requiere cláusulas explícitas STARTPOSITION / MAXRESULTS, y el cliente recorre las páginas hasta que se alcanza el limit o el upstream devuelve una página corta. La respuesta incluye limit_reached: true cuando limit fue la condición de parada.
qbo_get_invoiceqbo_get_invoice(invoice_id: str)Devuelve el registro completo de la factura (con Line[]), o data: null para un 404.
qbo_search_bills / paridad de qbo_get_invoiceqbo_search_bills refleja qbo_search_invoices pero contra la entidad Bill (lado del proveedor). Mismas semánticas de fecha, mismo filtro de estado.
qbo_get_chart_of_accountsqbo_get_chart_of_accounts()Devuelve cada cuenta activa en el reino. Cada registro incluye Id, Name, AccountType, AccountSubType, Classification y CurrentBalance, entre otros campos de QBO. Útil para fundamentar cualquier pregunta de "¿dónde se registró esta transacción?".
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, ~3sHooks de pre-commit (gitleaks, trufflehog, ruff, formateador, depurador de huellas de inquilino):
pip install pre-commit
pre-commit installLas pruebas de integración contra un reino sandbox real de QBO están protegidas detrás de QBO_INTEGRATION_TESTS=1. No son necesarias para la contribución normal.
Failed to refresh QBO access token — el token de actualización ha sido rotado sin que te dieras cuenta, o el client_id / client_secret de la aplicación es incorrecto. Los tokens de actualización se invalidan tan pronto como se emite uno nuevo, por lo que si dos procesos comparten un token de actualización, el que se actualice primero gana. Solución: persiste los tokens rotados (consulta on_refresh_token_rotated) o ejecuta solo un servidor por credencial de token de actualización.
Missing required environment variables — el servidor intentó iniciarse antes de que se cargara su .env. Exporta las variables en el shell principal o asegúrate de que la configuración de tu host MCP las incluya en el bloque env.
Resultados vacíos a pesar de datos conocidos — confirma que QBO_ENVIRONMENT coincide con la credencial. Un token de actualización de sandbox contra el host de API de producción (o viceversa) se autenticará pero devolverá una empresa vacía.
Ventanas de fechas grandes lentas — el endpoint de consulta de QBO pagina con un límite estricto de 1000 filas por página. El cliente recorre las páginas de forma transparente, pero un escaneo de facturas de 5 años sigue significando muchos viajes de ida y vuelta. Considera ajustar date_from / date_to o filtrar por status.
Transient QBO error: HTTP 429 — el limitador de velocidad de Intuit se activó. El cliente reintenta automáticamente con retroceso exponencial; si ves esto en la salida de la herramienta, has superado el QBO_MAX_RETRIES configurado. Auméntalo o ralentiza tus consultas.
Las propuestas y solicitudes de extracción son bienvenidas. Por favor:
Ejecuta pytest antes de abrir una PR (pip install -e ".[dev]").
Ejecuta pre-commit run --all-files.
Mantén las adiciones al alcance de solo lectura de la v0.1. Los endpoints de escritura llegarán en la v0.2.
Datos sintéticos solo en pruebas: sin nombres de clientes reales, nombres de proveedores o IDs de reino.
MIT: consulta LICENSE.
qbo-mcp es una integración de terceros no oficial. No está respaldada, afiliada ni apoyada por Intuit Inc. "QuickBooks" y "QuickBooks Online" son marcas comerciales de Intuit Inc. Úsalo bajo tu propio riesgo; verifica el comportamiento contra tu reino antes de depender de él para decisiones de producción.
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.
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.
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
