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

Beyond the read-only, idempotent, and non-destructive annotations, it discloses that the call is free and involves no browser session, preventing the agent from assuming it opens or operates a browser. It also explains the fallback behavior for apps outside Cotlet's catalog and notes the workspace-specific browser and sign-in guidance.

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?

Four compact sentences move from purpose and returned content to invocation timing, coverage and fallback, and finally cost and session behavior. The opening list is dense, but its items are substantive and there is no filler or repetition of the parameter schema.

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 two flat optional parameters fully documented by the schema and safety covered by annotations, the description supplies the missing operational context and describes the guide's contents despite the absence of an output schema. An agent can determine when to call it, what app names are supported, what information to expect, and whether the call has cost or session side effects.

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 schema already fully describes both app and task, including the app default and the request to express the task in the user's words. The description adds meaningful app-value semantics by supporting any web app and explaining what happens for an uncatalogued app, though it adds little further about how task shapes the result.

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?

It identifies the resource as per-app guidance for operating the user's Cloud Browser with Cotlet's browser tools and enumerates useful contents, including browser and sign-in details, steps, screens, menus, actions, and dedicated tools. The required timing and 'no browser session' statement distinguish it from the cotlet_browser_* tools that perform browser operations.

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 exact invocation point, while 'Works for any web app' and the general-method fallback define its scope. It does not explicitly say when the guide is unnecessary or name a sibling such as cotlet_apps for a different discovery need, so it stops short of fully exhaustive selection guidance.

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