session_start

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

With no annotations, the description carries the full burden and does substantial work: it discloses the origin-locked navigation sandbox, that read_only fakes every click/fill/submit rather than blocking them, that headed surfaces the browser window, and that success_criterion is immutable for the session's lifetime. Missing are the session lifetime/cleanup contract and any failure behavior, which is why it falls short of a 5.

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 opening sentence front-loads the action, and the remaining text is dense with constraints rather than filler — the quoted-example format for success_criterion is the kind of concrete detail that prevents malformed calls. Line-broken layout is slightly ragged but nothing is wasted.

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?

An output schema exists, so return values need no prose. What is missing for a session-lifecycle tool of this complexity is how the session is torn down (session_end), whether concurrent sessions are permitted, and what an invalid start_url does — the session contract is only half-drawn.

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 0%, so the description must compensate — and it largely does: it explains start_url's role in bounding navigation, the exact quoting format required for success_criterion, the fake-behavior of read_only, and the visible-window effect of headed. The 'goal' parameter is never mentioned at all, leaving one of five undocumented.

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 ('Open start_url ... and start a session') plus the actor's browser, so the action is unmistakable. It implicitly separates itself from session_status/session_end by being the opener, but never names a sibling or its position in the session lifecycle explicitly.

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?

Usage is implied rather than stated: the description defines prerequisite constraints (success_criterion is required and fixed, navigation is limited to start_url's origin) but never says when to call this versus session_status or session_end, nor what to do if a session already exists. An agent can infer this is the first call, but inference is all it gets.

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