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

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so the no-side-effects claim is partly redundant, but the description adds genuinely new context: the tool returns procedural guidance (screens, buttons, fields) and requires a follow-up browser tool to actually perform the change. The appended note on the absence of a public EZ Lawn Biller API explains why browser automation is the path. It does not describe the shape or length of the returned steps, but the core behavioral surprise is well disclosed.

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 functional content is front-loaded in the first two sentences, with the API-availability note serving as supporting rationale for the browser-automation workflow. The API research sentence is longer than it needs to be and reads like provenance logging rather than actionable guidance, which costs some tightness.

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 everything an agent needs: what it returns, that it performs no action, and which tool family to use to complete the task. Annotations cover the safety profile and the description covers the workflow handoff, leaving no material gap.

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 and the schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

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 opening sentence names a specific verb and resource ("Reorder stops in ... EZ Lawn Biller"), and the second sentence immediately reframes what the tool actually returns: step-by-step instructions rather than the reorder itself. The only weakness is that the leading clause reads like an action tool, so an agent must read two sentences to learn it is actually a how-to/lookup tool. It is still clearly distinguishable from data-mutation siblings like ez_lawn_biller_add_visit.

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 gives an explicit workflow: call this tool to get the steps, then execute them with the cotlet_browser_* tools against the user's Cloud Browser. It also states the tool "opens nothing by itself," which is a concrete usage constraint. It does not name a non-browser alternative or state when NOT to call it, but the sequencing guidance is clear enough to act on.

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