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

Annotations already declare readOnly/ idempotent/ non-destructive/ closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts: 'Free, no browser session' tells the agent this costs nothing and does not open a browser (relevant given cotlet_balance and cotlet_browser_open siblings), and it enumerates the app coverage for Rosy Salon Software. It does not describe the response shape, which keeps it from 5.

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?

No filler sentences, but the lead sentence is a long run-on that stacks a colon-list of deliverables before the agent learns the one imperative that matters ('call it before the first browser step'). Reordering so the imperative comes first and the returned-content list second would make it materially easier to scan.

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 two-optional-param read-only guide with no output schema, the description covers what it returns, when to call it, that it is free and sessionless, and its app coverage — enough for correct invocation. Only the form/size of the returned guidance is unstated, a minor gap since no output schema exists to carry it.

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?

Schema coverage is 100% with only two optional, self-documented parameters, so the baseline is 3. The description goes beyond the schema by explaining what happens for an app outside Cotlet's catalog (you get the general method) and by naming the concrete action coverage for the default app, which clarifies what the 'app' parameter actually buys you.

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 states the resource precisely: a how-to guide for driving a web app in the Cloud Browser, returning which browser/sign-in link to use, the step-by-step method, screens/menus/actions, notes, and any app-specific dedicated tools. It is distinguishable from the cotlet_browser_* siblings (it is the pre-step guide, not an action) and from the rosy_salon_software_* siblings (which are the dedicated tools it points to). The phrasing is dense and indirect rather than a clean verb+resource, which keeps it at 4.

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?

'Call it before the first browser step in an app' gives an explicit trigger, and 'before the first' implicitly tells the agent not to re-call it on later steps. 'Works for any web app; one outside Cotlet's catalog gets the general method' sets scope clearly. No sibling is named as an alternative for a different situation, so it falls short of 5.

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