quickbooks_list_accounts

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds genuinely novel context beyond those annotations: it explains that fresh executions return 'bounded live provider output' while replays return a 'durable digest/count commitment,' and it flags this as a 'governed finance read.' This is meaningful behavioral disclosure, though it could clarify what the digest/count commitment concretely contains.

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 front-loaded with purpose, followed by a one-sentence behavioral summary, then a structured Args block. The structure is logical and the Args list earns its place given the 0% schema coverage. The behavioral sentence is jargon-dense ('bounded live provider output', 'durable digest/count commitment'), which slightly reduces clarity but not structure quality.

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?

With an output schema present, return-value documentation is not the description's job, and the annotations cover the safety profile. The description covers all parameters, names the governance/read nature, and hints at output bounding. The main gap is that 'bounded' and 'durable digest/count commitment' are left vague, so an agent cannot fully anticipate response shape or limits without additional platform knowledge.

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%, so the description must carry the parameter-documentation burden, and it does: the Args block gives each of the 8 parameters a concise semantic (e.g., 'project_ref: Exact project correlation reference', 'effect: Required and must be read; Spring verifies it'). This compensates well for the empty schema descriptions, though a couple of entries (effect, approval_ref) are terse and only fully understood in the platform's broader context.

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 a specific verb ('List'), a specific resource ('QuickBooks chart of accounts'), and an explicit use case ('for GL and statement analysis'). The QuickBooks prefix cleanly distinguishes it from sibling connectors like xero_list_accounts and myob_list_accounts, and the resource type separates it from other quickbooks_list_* tools.

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 context through 'for GL and statement analysis' and the QuickBooks naming prefix, but it does not explicitly state when to use this tool versus alternatives, nor does it name exclusions. An agent must infer platform selection from the tool name rather than from any stated guidance.

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