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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely new behavior: it is free and consumes no browser session, which matters for an agent that must budget session usage. It also discloses the fallback behavior for uncatalogued apps, though it does not describe the return shape or how large the guidance output 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?

The opening sentence is a long comma-separated inventory of return contents that buries the core action, and 'how to work in an app by clicking in the user's Cloud Browser with Cotlet's browser tools' restates the title. The trailing short sentences carry the real operational value and could have been front-loaded.

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 annotations covering the safety profile, the description supplies enough for an agent to call this correctly: what it returns, when to call it, and its cost profile. The remaining gap is that it does not say what the response looks like or how to act on the returned guidance.

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 both the app name/slug and the user's task are already documented, and the description adds little parameter-level detail. The clause about apps outside Cotlet's catalog implicitly tells the agent that an arbitrary app name is acceptable, but it never explains how the task parameter shapes the returned guidance.

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 concrete resource — per-app operating guidance for driving a web app in the Cloud Browser — and enumerates what it contains (browser choice, sign-in link, step-by-step method, screens/menus/actions, notes, dedicated tools). It is clearly distinguishable from the action siblings like cotlet_browser_click or cotlet_apps. The phrasing is a sprawling list rather than a crisp verb+resource statement, which keeps it from 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 a concrete trigger, and 'Works for any web app; one outside Cotlet's catalog gets the general method' sets the boundary condition. It does not explicitly point at cotlet_apps for discovering apps or at cotlet_whoami for workspace context, so alternative routing is only partially covered.

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