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

Annotations already cover safety (readOnly, non-destructive, openWorld) and non-idempotency; the description adds genuinely new context: the browser runs as the signed-in user, existing user tabs are preserved, and the call returns the in-view elements/text with stable element numbers. It doesn't discuss session lifetime, auth prompts, or failure when a site isn't signed in, but the added value is real.

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?

Front-loaded with the action and the ordering instruction, then behavior, then return shape. The trailing Portrait Care action list is useful for routing but reads as a bolt-on and 'Answers the page after it ... with the same numbers' is slightly compressed phrasing.

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 no output schema, the description correctly spends text on what comes back (in-view elements and text, consistent numbering). Two parameters with full schema coverage and complete annotations leave little else an agent needs, though a note on what happens when the site requires login is missing.

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 the 3 baseline is met by default; the description goes further by explaining the observable effect of `url` (opens in the site's existing tab or a new tab, leaving user tabs alone). The `app` parameter's semantics are carried by the schema, not the description.

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?

States a specific verb and resource ('Starts the user's Cloud Browser ... and opens `url`') and names the environment (real Chrome on Cotlet, signed in). The tab-targeting rule ('goes to the site's open tab, else to a new tab') separates it from cotlet_browser_navigate/close without the agent needing to open another schema.

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 the other browser tools, and the `app` sentence points to cotlet_app_guide as the authority for when to set a non-default browser. It stops short of naming the sibling it supersedes (navigate) or when-not to use it, but the ordering guidance is clear.

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