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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this by saying it opens nothing by itself, which is the key safety fact for a navigation tool. It also discloses beyond the annotations that the return value is procedural prose, namely screens, buttons, and fields, which matters because there is no output schema. Permissions and rate limits are not mentioned, but they are not material for a pure read.

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 front-loaded with the deliverable and the read-only guarantee, then gives the handoff to the browser tools. The API-availability paragraph supports the design rationale but reads as background; it is one long sentence with several em-dash clauses and some redundant repetition around the account name.

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?

There is no output schema, so the description has to convey what comes back, and it does: step-by-step screens, buttons, and fields, plus the explicit note that nothing is opened. For a zero-parameter, read-only navigational tool, that covers what an agent needs. The remaining gap is the lack of routing against the similarly named sibling dashboards.

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 schema and the description agree that there is nothing to specify. The baseline for a parameterless tool applies. The description correctly implies no input is needed and moves directly to what happens next.

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 concrete verb and resource: it returns step-by-step guidance for the Dashboard in the user's EZ Lawn Biller account and clarifies that it opens nothing itself. That distinguishes it from a data-returning tool. It does not, however, distinguish the dashboard from close siblings such as ez_lawn_biller_customer_dashboard or ez_lawn_biller_export_dashboard, so the agent still has to infer which dashboard 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?

The guidance is clear: get the instructions here, then carry them out with the cotlet_browser_* tools in the user's EZ Lawn Biller Cloud Browser. That gives the agent an explicit next step and a reason to call this tool. It names no exclusions or competing alternatives, but no misleading guidance either.

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