lightbulb-mcp

by RPasquale

Overview Schema Source Related Servers Discussions Admin

Python

Remote

quickbooks_list_payments

Read-onlyIdempotent

Retrieve QuickBooks payments within a date range to analyze cash movement and reconcile accounts.

Instructions

List QuickBooks payments for cash movement and reconciliation analysis.

Args: from_date: Start date (YYYY-MM-DD). to_date: End date (YYYY-MM-DD). max_results: Maximum number of payments to return. 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

Name	Required	Description	Default
`effect`	Yes
`to_date`	No
`from_date`	No
`project_id`	No
`max_results`	No
`project_ref`	No
`approval_ref`	No
`idempotency_key`	No
`connector_account_ref`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.1Sep 7, 2026

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"
+]
```

First observedv0.1.0Jun 25, 2026

TDQS

A3.6/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. The description adds that 'effect' must be 'read' and that Spring verifies it, plus notes on idempotency and approval_ref. The approval_ref line about 'resuming a write' is confusing in a read-only tool, but it does not directly contradict the readOnlyHint annotation.

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 one-sentence purpose is front-loaded and the Args block is organized and mostly scannable. It earns its place, though the approval_ref line is tangential for a read-only list operation and could be removed or clarified.

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

Completeness4/5

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

With an output schema present and annotations covering safety, the description need not enumerate return fields. It covers the operation purpose and every parameter well enough to construct a call. Minor gaps are the lack of explicit optionality for date filters and any pagination behavior, but defaults are in the schema.

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?

Schema coverage is 0%, so the parameter descriptions carry the full burden, and this description does provide a one-line semantic for every parameter, including date formats and the required effect value. Some definitions are terse ('Exact project correlation reference') but the description substantially compensates for the absent schema descriptions.

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

Purpose4/5

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

The opening line names a specific verb and resource: 'List QuickBooks payments', and adds a purpose ('cash movement and reconciliation analysis'). It is clear about what the tool does, though it relies on the tool name to distinguish it from sibling listers like xero_list_payments.

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 phrase 'for cash movement and reconciliation analysis' gives a use context, and the QuickBooks qualifier implies the connector. However, there are no explicit when-to-use/when-not-to-use instructions, alternatives, or exclusions, so an agent must infer the decision among many list_payments siblings.

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

Deploy Server