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

Annotations already declare readOnly/idempotent/non-destructive and a closed world, so the safety profile is covered. The description adds information annotations cannot: it is 'Free, no browser session', meaning no Cloud Browser session is opened or billed by this call — a genuinely useful operational fact for an agent deciding whether to call it casually. It does not describe output length or how the returned method should be consumed.

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 call-to-action and the free/no-session fact are front-loaded and the sentences are short. The opening sentence is a dense comma-spliced enumeration that is harder to parse than needed, and the trailing Pirate Ship action list reads as catalog detail rather than selection guidance.

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 no output schema, the description carries the return-value burden and does so: it names the browser/sign-in info, the step-by-step method, screen and menu notes, and any app-dedicated tools. Combined with the explicit pre-step trigger and app-coverage note, an agent has everything needed to call it correctly.

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%, so baseline is 3, but the description adds real meaning: it explains what the 'app' value changes (catalog app versus an outside app that only gets the general method) and enumerates the concrete action coverage for Pirate Ship (rates, bulk labels, import orders, tracking, refunds). The 'task' parameter's effect is left implicit.

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 a specific function: return guidance on how to operate a web app via Cotlet's Cloud Browser, and it enumerates the payload (browser choice, sign-in link, step-by-step method, screens/menus/actions, notes, app-specific tools). This distinguishes it from the concrete browser action siblings (cotlet_browser_click, cotlet_browser_navigate) which perform steps rather than explain them. The phrasing 'How to work in an app' echoes the title somewhat, but the body makes the resource concrete.

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 point, and 'Works for any web app; one outside Cotlet's catalog gets the general method' sets expectations for the fallback case. It implies not calling it repeatedly by anchoring to the *first* step, but it never states exclusions or names a sibling to use instead for a specific sub-need.

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