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

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value beyond them by stating it opens nothing by itself and by describing the shape of the return (screens, buttons, fields), which is important since there is no output schema. It also notes the absence of a public EZ Lawn Biller API, explaining why browser automation is required.

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 core behavior and the handoff to cotlet_browser_* tools are front-loaded in the first two clauses, and the API-status note is relevant supporting context rather than filler. The API paragraph is somewhat long relative to the rest, which costs a point but it still earns its place by preempting an agent's search for an API route.

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?

With no parameters and no output schema, the description must carry the return-value burden, and it does by specifying step-by-step screens, buttons, and fields. The handoff to the browser tools and the no-API caveat together give an agent enough to act correctly, though it does not state what happens if the user's account or session is unavailable.

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 there is no parameter meaning for the description to add; the baseline for a parameterless tool is 4. Nothing in the description misdescribes an input.

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 uses a specific verb ('Returns how to do it... step by step (screens, buttons, fields)') tied to a named resource, the EZ Lawn Biller statement run, and explicitly states the tool 'opens nothing by itself,' so an agent can tell it is a guidance tool rather than an executor. It does not explicitly distinguish itself from similarly named siblings such as ez_lawn_biller_statement_dry_run, statement_preview, or statement_test, which keeps it from a 5.

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 clear usage flow: call this to obtain step-by-step instructions, then perform the actual work with the cotlet_browser_* tools in the user's Cloud Browser. It stops short of stating when to prefer this over the dry_run/preview/test siblings, so the routing guidance is contextual but incomplete on exclusions.

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