list-invoices

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the tool is read-only and that amounts are integer cents, which helps interpretation. However, it does not disclose pagination behavior, API rate limits, or the single-filter limitation, though these are covered in the schema. The description adds some context but not extensive behavioral insight.

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?

Two concise sentences: the first states purpose and read-only nature; the second lists useful filters and fields. Every sentence adds value, with no filler. The description is front-loaded with the primary action and distinguishes this tool from siblings immediately.

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 an 8-parameter tool with no output schema, the description is adequate. It covers the essential context (read-only, cents, useful filters/fields) while relying on the rich schema for parameter details. It does not describe the return structure beyond field mentions, but the schema's detailed parameter descriptions compensate. Slightly more behavioral guidance (e.g., pagination) would make it fully 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 coverage is high (88%), so the baseline is 3. The description adds semantic context by calling out useful filters (status, due_at, matter_id) and notable fields (amount_cents, amount_paid_cents, outstanding_amount_cents, due_at, pdf_url). This enriches understanding beyond the schema but does not deeply explain parameter syntax or offer additional meaning not already in 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 begins with 'List invoices', a specific verb+resource, and adds 'read-only' to clarify the operation type. It clearly distinguishes from siblings by targeting invoices exclusively, while sibling tools target other entities like contacts, matters, etc.

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 clear context for when to use this tool: when listing invoices. It also highlights useful filters (status, due_at, matter_id) which implicitly guide the user toward common use cases. No explicit exclusions or alternatives are given, but the resource specificity makes this unambiguous.

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