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

Annotations declare readOnlyHint=false and destructiveHint=false, meaning the tool writes but is not destructive. The description adds a key behavioral detail: 'It does not move money,' clarifying that this is purely an accounting record with no real-world fund movement. This is beyond what annotations provide.

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?

Three short sentences, each earning its place. The first names the action and target, the second defines the concept, and the third negates a common misunderstanding. No filler.

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 simple two-parameter schema with exhaustive parameter descriptions and the behavioral note about money not moving, the description is complete enough for an agent to invoke correctly. It does not describe return values, but no output schema is provided and none is required for this kind of creation 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 description coverage is 100%, and the entity parameter description already details required fields (TxnDate, Amount, BankAccountRef, CreditCardAccountRef) and restrictions on sensitive data. The tool description adds no parameter-level information; baseline 3 applies.

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?

States the verb 'Create' and the resource 'credit card payment txn in QuickBooks Online'. Clarifies the concept with 'accounting record of a bank payment toward a credit card balance' and distinguishes it from money movement with 'It does not move money.' This is specific enough to separate from sibling tools like create_payment or create_transfer.

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 the use case: recording a bank payment toward a credit card balance. It does not explicitly name alternatives or state when to use vs create_payment/create_bill_payment, but the 'does not move money' clause gives a hint that it is not for actual transfers. This is implicit guidance, not explicit.

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