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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, but the description adds genuinely non-derivable facts: the tool performs no browser action itself, its output is procedural guidance rather than data, and EZ Lawn Biller has no public API (with the evidence: 404 on /api, /developers, /docs, and QuickBooks as the only named integration). That last point explains why the browser tools must be used.

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 and the 'opens nothing' caveat are front-loaded, followed by the follow-up action, which is the right order. The closing sentence on API research is longer than it needs to be, but it carries substantive justification rather than 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?

For a zero-parameter, read-only guidance tool with no output schema, the description covers what the response contains (steps, screens, buttons, fields) and what to do next. The only real omission is disambiguation from the near-identically named statement siblings.

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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter meaning for the description to add or omit. Nothing in the description conflicts with the empty, additionalProperties:false 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 states a specific verb and resource: it returns step-by-step instructions ('screens, buttons, fields') for handling statements in the user's EZ Lawn Biller account, and explicitly says it 'opens nothing by itself'. That distinguishes it from an action tool, but it never differentiates itself from close siblings such as ez_lawn_biller_statements or ez_lawn_biller_statements_to_print, so an agent cannot tell from the description alone which statement tool to pick.

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 gives a usable sequence: call this to learn the steps, then execute with the cotlet_browser_* tools in the Cloud Browser. There is no when-not guidance and no naming of the sibling tools that would be the alternative for actually retrieving, printing, or emailing statements, so the routing decision is left implicit.

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