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

Annotations already establish readOnly, idempotent, non-destructive, non-open-world behavior, so the bar is lower; the description still adds genuinely new facts -- 'Free, no browser session' tells the agent this call has no cost or session side effect, and the itemized return contents ('the app's screens, menus and actions, notes') disclose what the guide contains. No contradiction with openWorldHint=false, since the tool itself opens no external session. It does not say what happens when an app is unknown or how fresh the guide is.

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?

Purpose and the itemized contents are front-loaded, then the timing rule and cost line follow, so an agent gets the essentials in the first clause. The opening sentence is a long comma-chained list that is dense but not wasteful; no sentence is filler.

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?

With only two optional parameters, no output schema, and full annotation coverage, the description carries the right load: it explains what comes back, when to call it, and that it is free. Remaining gaps are modest -- no guidance on a misspelled/unknown app or on whether re-calling after browsing is useful -- but nothing needed to invoke it correctly is missing.

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 description coverage is 100%, with both `app` (name or Cotlet slug, default BambooHR) and `task` (user's words) documented inline, so the baseline is 3. The description adds only indirect meaning -- 'which browser to use for this workspace' hints at why `app` matters -- and says nothing about `task` influencing the returned method, so it does not compensate much beyond the schema.

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 resource (guidance for working inside a web app via Cotlet's Cloud Browser) and enumerates the payload: which browser/sign-in link, step-by-step method, screens, menus, actions, notes, and any dedicated app tools. It is distinguishable from the cotlet_browser_* siblings, which perform actions rather than return guidance. The phrasing is noun-heavy ('How to work in an app...') rather than a clean verb, which keeps it just short of a 5.

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 condition, and 'Works for any web app; one outside Cotlet's catalog gets the general method' sets applicability boundaries. It also notes the app's dedicated tools exist 'when Cotlet has them', nudging the agent toward those siblings. There is no explicit when-not-to-use or a named fallback sibling beyond that hint.

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