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

The annotations already say readOnlyHint=true, openWorldHint=true and destructiveHint=false; the description adds more context: the browser is authenticated as the user, the URL takes over the site's open tab before a new one is created, and the user's own tabs are preserved. It also discloses the return: the page's elements and text in view, with matching numbers. This is more than the annotations say, though auth failure and expiry behavior go unmentioned.

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 fronts the imperative action and the 'call it first' ordering, then goes on to the tab behavior and the result. Four short sentences with little filler. The closing Omio action list is somewhat promotional, but it grounds the tool in a concrete app context and can help with tool selection.

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 still says what comes back ('the elements and text in view, with the same numbers'), which is what an agent needs after calling. It also covers sequencing, session identity, and tab placement, all in one small package.

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 3 is the baseline. The description adds value on top: it explains where the URL is rendered (the site's open tab if present, otherwise a new tab), which is real behavior obtained through this parameter. The `app` semantics are already handled well by the schema itself.

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 definition names a concrete action ('Starts the user's Cloud Browser') and is specific about what that browser is: 'a real Chrome on Cotlet, where the user is signed in to their sites'. The phrase 'opens `url`' pins down the resource. This separates the tool from session-less siblings such as cotlet_browser_navigate, which acts on an already-started browser.

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' is an explicit sequencing rule that tells the agent when to use this tool rather than a later browser step. The constraint on `app` ('Only when cotlet_app_guide names an app's own Cloud Browser') gives a concrete condition for the less common mode. The definition never says when not to use this tool, however; for example, it does not contrast it with cotlet_browser_navigate once a session already exists.

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