Zovo Average Balance

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

Beyond the annotations, which already declare a safe read-only, idempotent operation, the description discloses important behavior: each calendar day is counted, balances carry forward over days without transactions, and results include a running-balance check, recurring credits, large deposits, Excel output, and a PDF summary. It also explains the relative-change fallback when no opening or running balance is available, which is valuable behavioral context not present in annotations or schema.

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 dense and front-loaded, leading with the use case before input rules and output details. It is somewhat long and reads as a single run-on paragraph, but nearly every sentence contributes actionable information, so the size is mostly justified for an 18-parameter tool.

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 a complex 18-parameter tool with an output schema, the description covers the essential purpose, input fallback strategy, day-counting behavior, fallback results without opening/running balance, and explicit limitations. The output schema handles return structure, so the description is complete enough for an agent to call the tool correctly.

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 adds meaningful usage semantics by prioritizing transactions over file and statement_text, explaining how screenshots and pasted text should be converted, and clarifying that opening/running balance affect whether relative change is returned. This goes beyond restating parameter names and helps an agent choose and populate the right inputs.

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 and resource: calculating average monthly balance, average daily balance, and proof-of-funds figures from transactions. It clearly distinguishes the tool from adjacent capabilities by saying it does not connect to banks, read scans, or issue a bank certificate.

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?

It explicitly says when to use the tool ('when the user wants an average monthly balance calculator...') and gives a clear input preference: put statement rows into transactions, convert pasted text or screenshots into fields, and use file or statement_text only as a fallback. It also states negative boundaries, which helps an agent avoid misrouting unsupported requests.

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