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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false), and the description corroborates them by stating it 'opens nothing by itself' – so no contradiction, and it resolves the ambiguity of what readOnly means for a tool named 'edit'. It also explains why browser tools are required (no public EZ Lawn Biller API documented, with 404 evidence). It does not describe the shape or length of the returned instructions.

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 purpose and the browser-tool handoff are front-loaded and earn their place. The final sentence cataloguing 404 responses for /api, /developers and /docs plus the QuickBooks FAQ detail is investigative provenance that consumes roughly a third of the text and could be compressed to 'no public API exists; use browser tools.'

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?

It covers the return format at a high level (step-by-step screens, buttons, fields) and the follow-up tooling, which is the right shape for an instruction-returning tool with no output schema. But with zero parameters it never says how the specific customer is selected or communicated to the browser tools, and it doesn't say whether the steps are account-specific or generic.

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?

With zero parameters and 100% schema coverage, there is no parameter meaning to add, so the baseline of 4 applies. The description does not address the obvious consequence of having no inputs – namely how the target customer is identified – but that is a completeness issue rather than a parameter-semantics one.

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 names a specific verb+resource ('Edit customer in the user's own EZ Lawn Biller account') and then clarifies the actual mechanics: it 'Returns how to do it in EZ Lawn Biller step by step ... and opens nothing by itself.' That second sentence is what makes the tool's real behavior distinguishable, since the name implies the tool performs the edit. Sibling edit tools target different resources (estimate, visit, template), so resource-level differentiation is adequate, though no sibling is named explicitly.

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 follow-on path ('then do it with the cotlet_browser_* tools in the user's EZ Lawn Biller Cloud Browser'), which tells the agent this is a preparatory guidance step rather than the action itself. However, it offers no when-not guidance, no prerequisite such as locating the target customer first (customer_search/customer_list), and no statement about what to do if the user's account is not connected.

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