Skip to main content
Glama
RPasquale

lightbulb-mcp

by RPasquale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

quickbooks_trial_balance_report

Read-onlyIdempotent

Retrieve QuickBooks trial balance reports to reconcile GL balances and support period-end close review.

Instructions

Fetch the QuickBooks trial balance report for GL tie-out and close review.

Args: start_date: Report start date (YYYY-MM-DD). end_date: Report end date (YYYY-MM-DD). accounting_method: Accounting method: Accrual or Cash. columns: Optional report columns to request. project_id: Authenticated Project UUID. project_ref: Exact project correlation reference. connector_account_ref: Project-bound connector account alias. idempotency_key: Stable business-action identity. effect: Required and must be read; Spring verifies it. approval_ref: Approved platform task UUID when resuming a write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
effectYes
columnsNo
end_dateNo
project_idNo
start_dateNo
project_refNo
approval_refNo
idempotency_keyNo
accounting_methodNo
connector_account_refNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / approval_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Approval Ref"
+}
    • addedInput schema / properties / connector_account_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Connector Account Ref"
+}
    • addedInput schema / properties / effect
      Added value: +{
+  "const": "read",
+  "title": "Effect",
+  "type": "string"
+}
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Idempotency Key"
+}
    • addedInput schema / properties / project_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Id"
+}
    • addedInput schema / properties / project_ref
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Project Ref"
+}
    • addedInput schema / required
      Added value: +[
+  "effect"
+]
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior, so the description's burden is lighter. It adds that 'effect' must be 'read' and that Spring verifies it, which is useful, but the 'approval_ref... when resuming a write' line is confusing for a read-only report and no additional operational behavior (pagination, date-range handling, auth) is disclosed. No direct contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose sentence is front-loaded and the parameter list is compact, with one gloss per argument and no repeated schema boilerplate. The list is necessarily long due to 10 parameters, and only the 'approval_ref' note feels misplaced.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with an output schema, the description covers purpose and parameters but omits selection guidance among the large report-tool sibling set and several behavioral details (default date range, auth prerequisites). It is minimally viable but not fully complete for a complex report tool in a very crowded tool list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the parameter-documentation load and it compensates reasonably: it gives date formats, the Accrual/Cash enum, optionality of columns, and identity/context parameter meanings. A few entries remain vague (e.g., 'columns', 'project_ref'), but the overall gloss is meaningfully beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb ('Fetch'), names the exact QuickBooks report ('trial balance'), and states its intended business use ('GL tie-out and close review'). The tool name plus resource makes it distinguishable from the many other quickbooks_* report siblings and from xero_trial_balance_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'for GL tie-out and close review' clause gives a clear use context, but the description never says when not to use it or what alternative report tool to prefer (e.g., quickbooks_report, quickbooks_balance_sheet_report, xero_trial_balance_report). No exclusions or routing guidance are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools