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

The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile needs no repeating. The description earns credit for adding genuinely behavioural context that the annotations cannot carry: it explains that the tool returns procedural guidance, that it changes nothing, and that browser automation really is the only path now that the official API returned 404 by 11 Nov 2026. It does not state what a step-by-step instruction response will contain beyond 'screens, buttons, fields', or whether the step list depends on prior browser session state.

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 behaviour is front-loaded in the first two sentences, which is good, but the opening phrase 'from ChatGPT, Claude or any AI agent' is filler, and the closing API paragraph spends most of its length on retrieval details (which paths 404'd, which documents cite QuickBooks) for a single justification: there is no public API. The essential message, that the official API does not exist, could be stated in one clause instead of three lines.

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, this covers the two things an agent needs: what it gets back (step-by-step screen and button instructions) and what to do afterwards (the cotlet_browser_* tools). The remaining gap is that 'Selected' is never defined; nothing says which record must be selected, or whether that selection is established in the browser session rather than in this call.

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 no parameters at all, so there is nothing to disambiguate and the schema already covers it completely. The description correctly does not invent parameter discussion, and it implicitly explains why no arguments are needed: the tool just returns generic step-by-step guidance.

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 the resource and the situation ('Email Selected in the user's own EZ Lawn Biller account') and then discloses the tool's actual behavior: it 'Returns how to do it in EZ Lawn Biller step by step (screens, buttons, fields)'. That is more specific than the title alone, but it never distinguishes this from neighbouring tools such as ez_lawn_biller_resend_selected, ez_lawn_biller_send_email or ez_lawn_biller_compose_email, so an agent cannot tell from the description which entry point to take.

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 provides explicit usage framing: get step-by-step instructions here, because the tool 'opens nothing by itself', then carry the action out with the cotlet_browser_* tools in the EZ Lawn Biller Cloud Browser. That is a clear workflow hand-off and it explicitly excludes the tool from actually performing the send. It does not, however, set this against the other email-related siblings, so the choice among them is left to inference.

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