session_start

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

No annotations exist, so the description bears the full transparency burden. It does honestly disclose the key behavioral trait — state persists across commands like a real person's browser tab. However, it omits meaningful behavioral caveats: resource cost/latency of spinning up a live session, what happens if a session already exists, whether only one session can be active, timeout behavior, or any rate limits. The description is accurate but not rich enough for the resource-heavy operation it describes.

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 description is compact and front-loaded: purpose first, then state semantics, then forward/backward commands, then status. Three short sentences accomplish a lot with no real waste. The only minor ding is that the forward-slashed list of command names, while informative, becomes a bit dense and could have been structured more cleanly.

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 stateful session-management tool, the description explains the lifecycle very well (start → interact → close/status) and intentionally doesn't need to explain return values since an output schema exists. However, it misses critical stateful details such as single-session semantics, re-entry behavior if called twice, or consequences of forgetting session_end. These gaps matter for a stateful, potentially resource-leaking tool, so the description is adequate but incomplete.

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?

With 0% schema coverage, the description had to compensate for the two parameters. It only implicitly covers 'url' via 'opens URL,' and it's completely silent on 'max_chars' (a non-obvious parameter whose default of 6000 is unexplained). It also doesn't clarify why both parameters are optional or what the default behavior is when URL is omitted. The description adds no real meaning for the parameters the schema marks as optional.

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 uses a specific verb+resource construction — 'Starts a LIVE session: opens URL in persistent tab of serve-worker' — and clearly differentiates itself from sibling tools by emphasizing persistent state across commands (scroll, input, clicks live between commands, 'like a human in one tab'). This distinguishes it from stateless siblings like fetch_page and browser_navigate, and it clearly states the session-scoped resource it manages.

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?

The description gives explicit workflow context: it names the follow-up commands (session_navigate, session_click, session_type, etc.), the close command (session_end), and the status command (session_status), essentially teaching an agent the usage lifecycle. However, it never explicitly contrasts this with the stateless alternatives (e.g., 'use fetch_page for one-shot reads') or states when NOT to use a session, so it stops short of full when/when-not coverage.

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