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

Annotations already cover safety (readOnlyHint, destructiveHint=false, openWorldHint) so the bar is lower, yet the description still adds genuinely useful context: the browser is a signed-in Chrome instance, so no auth step is needed, and URL placement reuses an existing tab. It also discloses what comes back ('the elements and text in view, with the same numbers'), which matters because there is no output schema. Minor gap: nothing about failure behavior if the browser cannot start.

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 essential facts — start browser, open URL, call first, what returns — are front-loaded in the first three sentences. The trailing Zendesk action list ('List tickets, Reply to ticket, ...') is retrieval-oriented padding that does not help an agent invoke this tool correctly and slightly dilutes focus.

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-parameter entry-point tool with no output schema, the description covers what it does, when to call it, tab behavior, auth context, and roughly what is returned. The only real omissions are error/failure handling and an explicit boundary against cotlet_browser_navigate.

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% and both `url` (http/https format, example) and `app` (leave out unless cotlet_app_guide names a slug) are well documented in the schema already. The description adds the routing consequence of `url` and hints at the app concept, but says nothing about `app` itself; the baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb and resource ('Starts the user's Cloud Browser ... and opens `url`') and defines the browser concretely as 'a real Chrome on Cotlet, where the user is signed in to their sites'. It does not distinguish itself from the adjacent cotlet_browser_navigate sibling, which an agent might reasonably confuse with this one; 'Call it first' only hints at the split.

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 first' gives an explicit ordering rule relative to all the other browser_* tools. It explains tab placement ('goes to the site's open tab, else to a new tab, so the user's own tabs stay') but gives no exclusion such as 'use cotlet_browser_navigate for subsequent page loads', leaving that boundary to inference.

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