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

Annotations already declare readOnly, openWorld, non-destructive and non-idempotent; the description adds real context beyond them: this is a real Chrome where the user is already signed in, URL routing reuses the site's existing tab, and the call returns the page view with matching element numbers. It leaves open what happens if the browser is already open, which matters given `idempotentHint: false`.

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-loads the two essential facts (what starts, that it is called first), then the tab-placement and return-value details in compact sentences. The closing Exact Online action list is useful routing signal but is slightly tacked on and reads more like catalog metadata than tool guidance.

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 session-bootstrap tool with no output schema, it covers the essential ground: session start, ordering, tab behavior, what the response contains, and which downstream actions it enables. An agent can call it correctly without opening the schema.

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 `app` (omit by default, only when `cotlet_app_guide` names an app's own Cloud Browser) and `url` (public http/https) are already well documented in the schema. The description adds only tab-placement semantics for `url` and never mentions the `app` parameter at all. Baseline 3 applies when the schema carries the parameter documentation.

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 (a real Chrome) and opens `url`, and adds that it answers with the page's visible elements and text. An agent knows exactly what it gets. It stops short of distinguishing itself from the sibling `cotlet_browser_navigate`, which also opens a URL, so an agent still has to guess between the two.

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?

Gives an explicit ordering instruction, 'Call it first', which is strong when-to-use guidance for a browser session. Also explains tab placement (existing tab for the site, otherwise a new tab) so the user's own tabs are preserved. It never says when NOT to use it, e.g., versus `cotlet_browser_navigate` once the browser is already running.

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