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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the guide is free and starts no browser session, and it discloses the shape of returned guidance including fallback behavior for uncatalogued apps. Missing only whether results are cached or app-specific guidance can go stale.

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?

It is a single very long run-on sentence with a colon-separated list, which makes it dense to parse, followed by three short useful sentences. The key instruction ('Call it before the first browser step') is buried at the end of the block. Content earns its place, but the structure could be tighter.

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-parameter guide tool with no output schema, the description covers purpose, timing, scope, fallback for unknown apps, and what the response contains. Cost and side-effect information ('free, no browser session') is present. An agent has enough to call it correctly without further context.

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%, so both parameters (app, task) are already documented, including the Slab default, and the description does not add format or resolution detail beyond that. Baseline 3 applies since the schema does the heavy lifting and the description only implies that app selects workspace-specific 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 specifically that this retrieves guidance on working in an app via Cotlet browser tools, enumerating content returned (which browser, sign-in link, step-by-step method, screens/menus/actions, notes, dedicated tools). It is clearly distinguished from the cotlet_browser_* action siblings as a guidance tool rather than an action. It is dense and front-loaded with 'How to work in an app' rather than a clean verb, but an agent can still tell what it does.

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, which most sibling tools lack. It also covers applicability ('Works for any web app; one outside Cotlet's catalog gets the general method') and cost ('Free, no browser session'). It doesn't explicitly contrast with cotlet_apps or say when NOT to call it, which keeps it below a 5.

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