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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuinely new operational facts: it is free and opens no browser session, it works for any web app, and uncatalogued apps fall back to a general method. It does not describe output shape, but with no output schema and a predictable guide payload that is a minor gap.

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?

Roughly 60 words with no filler, and the enumeration of returned contents is informative rather than decorative. The first sentence is a long comma-separated list, so the critical 'Call it before the first browser step' directive lands second rather than 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?

For a zero-required-parameter guidance tool with no output schema, the description covers what is returned, when to call it, fallback behavior for unknown apps, and cost. Nothing essential for correct invocation is missing; only return formatting and re-call guidance are omitted, both of low consequence.

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%, with both 'app' (name or Cotlet slug, default MYOB) and 'task' documented in the schema itself. The description only gestures at inputs via 'which browser to use for this workspace' and 'the app's dedicated tools,' adding no syntax or formatting guidance beyond the schema. Baseline 3 is the correct ceiling here.

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 makes clear this is a guidance-retrieval tool: it returns 'which browser to use for this workspace and the sign-in link, the method step by step, the app's screens, menus and actions.' That distinguishes it from the action siblings (cotlet_browser_click, cotlet_browser_navigate) which perform steps rather than explain them. The opening phrase restates the title rather closely, which slightly blunts an otherwise specific statement.

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' is an explicit trigger with clear placement in the workflow. It also covers the edge case of an app outside Cotlet's catalog receiving the general method. It stops short of naming an alternative or saying when a call can be skipped (e.g., mid-task or after the guide was already fetched).

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