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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world); the description adds substantial context on top: admission is neither required nor performed, workspace books are never read or changed, non-statement documents are rejected, the call is not metered, and the result is an expiring download handle with format, size and SHA-256. It also discloses polarity behavior and that original references are preserved separately from generated FITIDs.

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?

Purpose is front-loaded in the first sentence and the paragraph structure separates format rules from side-effect/authorization behavior. Slightly verbose, with the format enumeration in prose partly duplicating the enum in the schema, but no sentence is wasted.

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?

An output schema exists and the description still summarizes the meaningful return (expiring download handle, format, size, SHA-256). For a 7-parameter tool with conditional requirements, all the information an agent needs to invoke it correctly — authorization path, rejection case, billing, polarity — is present.

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 already 100%, but the description still adds value by spelling out conditional requirements the schema encodes only structurally: bank_id for checking/savings, intu_bid additionally for QBO, fid as the separate OFX institution identifier, and that none of these are inferred from account numbers. This is above the baseline-3 case where the schema does all the work.

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 a specific verb and resource — 'Converts one authenticated Standard Statement into one interchange file' — and immediately enumerates the closed format set. This is clearly distinguishable from siblings like render_standard_statement or create_download_sessions, which do not produce interchange files.

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?

Gives concrete selection rules: OFX/QBO support checking, savings, and credit-card registers while 'other register kinds require CSV', and csv additionally requires a target. It stops short of naming an alternative sibling (e.g., render_standard_statement) and the condition that would select it, so routing versus siblings is inferred rather than stated.

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