connect

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

With no annotations provided, the description carries full burden. It discloses that connect starts/restarts a session, can launch Chrome or attach to an existing browser, and that every other tool depends on a live session. It also mentions the reset behavior (call again if wedged). This is adequate for a setup tool, though it could explicitly state that it closes any previous session.

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 concise (two sentences) and front-loads the key message ('ALWAYS the first call'). However, the first sentence is dense and could be broken into shorter sentences or bullet points for easier scanning. Overall, it is efficient and avoids unnecessary words.

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?

Given the tool's role as a session initiator with 6 parameters and sibling tools that depend on it, the description covers essential aspects: when to call, modes, parameter usage, and recovery behavior. It does not describe return values (no output schema) or error cases in detail, but that is acceptable for a connection setup tool.

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?

The input schema has 100% coverage for all 6 parameters. The description adds value beyond the schema by explaining the purpose of each parameter in context: url loads immediately, mode defaults to 'launch', width/height set viewport, headless only in launch mode, and browserUrl for attach mode with an example. This provides useful guidance.

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 clearly states the tool's purpose: 'start (or restart) the browser session'. It specifies it is always the first call and distinguishes between launching a local Chrome or attaching to an existing browser via browserUrl. This differentiates it from sibling tools that require an active session.

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 explicitly says 'ALWAYS the first call' and instructs when to call it again ('if a tool reports no session or a wedged browser'). It also explains the two modes (launch vs attach) with examples. However, it does not explicitly state when not to use it, though the context implies that if a session is active, it should not be called.

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