browser_start

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

The description discloses non-obvious defaults, which is useful. However, with no annotations, it carries the full burden of explaining behavior, and it omits important side effects: whether starting is idempotent, what happens if a session already exists, whether a persistent profile is reused, and how the session is later cleaned up. For a stateful, resource-creating tool, this is a significant gap.

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?

Two short sentences with no filler or repetition of schema content. The key information is front-loaded, and every phrase adds value by stating the action and the non-obvious defaults.

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 tool with 16 parameters, no output schema, and no return-value documentation, the description is far too thin. It does not say what the tool returns, how an agent knows the session is ready, or how the session relates to browser_status and browser_close. An agent could call it repeatedly or assume a session handle is returned when none may be.

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 only 38%, and the description mentions none of the parameters. It does not clarify ambiguous interactions like device vs mobile, browser vs channel, or how userDataDir relates to the default persistent profile. With over half the parameters lacking schema descriptions, the tool description needed to compensate and did not.

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 opens with a specific verb and resource: 'Start a browser session.' It also adds non-obvious launch defaults (patchright, chromium, headed, persistent profile). Among the large browser_* sibling set, it is clearly the lifecycle initializer and not confused with browser_navigate, browser_status, or browser_close.

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 phrase 'Start a browser session' implies that this is the entry point before using other browser tools, but the description never explicitly says 'call this first' or contrasts it with alternatives. There is no guidance about when not to use it, e.g. when attaching to an existing session via cdpEndpoint.

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