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

Beyond the annotations (readOnlyHint, idempotentHint, non-destructive, closed-world), the description discloses the important behavior that it 'opens nothing by itself' and returns instructions rather than data, so the agent knows it must chain into browser tools. It also documents the absence of a public EZ Lawn Biller API with specific evidence (404s on /api, /developers, /docs), which explains why browser automation is the only path. 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 core workflow statement is front-loaded and dense, but the opening is a sentence fragment and the API-status paragraph, while justifying the browser path, is verbose for the value it adds. The content mostly earns its place, yet the phrasing could be tightened considerably without losing information.

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, no-output-schema guidance tool, the description covers what is returned, what side effects do not occur, and what to do next, which is nearly everything an agent needs. The remaining gap is that it never states the guidance is generic (unscoped to a particular account record) despite having no parameters to target one.

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 nothing for the description to disambiguate; baseline applies. It could have noted that because it takes no arguments, the returned guidance is generic rather than scoped to a specific customer or job, but that is a minor omission.

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 definition makes clear that this returns step-by-step how-to guidance (screens, buttons, fields) for service notes in EZ Lawn Biller rather than the notes themselves, which is a crucial distinction the name alone would obscure. The opening sentence is an elliptical fragment ('Service notes in the user's own EZ Lawn Biller account from ChatGPT, Claude or any AI agent') that reads more like a marketing tagline than a verb+resource statement, and no sibling such as customer_notes or pin_notes is referenced for differentiation.

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 explicitly routes the agent through a two-step workflow: call this to get instructions, then execute with the cotlet_browser_* tools in the EZ Lawn Biller Cloud Browser. That is concrete when-and-how guidance. It stops short of stating when-not to use it or how it relates to the many sibling *_notes tools.

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