new_tab

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

No annotations are provided, so the description carries full burden. It discloses the key behavior: waits for real load events (unlike the old race-prone approach), the ~10s hardcoded extension load-wait, how 'timeout' only bounds the RPC transport layer (max(timeout,10)+5), and load=False on timeout. This is substantive context, though it doesn't describe the return shape beyond {tabId, loaded}.

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 dense with valuable technical detail and avoids fluff. It's front-loaded with the primary action and returns. Slight structural weakness: the technical caveats about timeout and the extension race are somewhat verbose but earn their place given no annotations exist.

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 no annotations and no output schema, the description does substantial work: it covers purpose, return contract, load-wait behavior, timeout semantics, and the race-condition rationale. It lacks explicit edge cases (e.g., what happens on network error vs timeout) and doesn't fully document url semantics, but is strong given the absence of structural metadata.

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 description coverage is 0%, so the description must compensate. It explains 'url' implicitly (the URL to open, shown in the example), and 'timeout' thoroughly (capped as transport-only). However, url's meaning is only conveyed via the example call, not explicit prose. Timeout gets excellent semantic detail, but url is under-specified relative to the low coverage baseline.

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 it opens a new tab, adds it to the nekoro managed group, switches to it, and attaches. It distinguishes itself from sibling tools like navigate, switch_tab, and list_tabs by specifying the specific resource (new tab) and its unique actions (grouping, attaching, waiting for real load events).

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 explains when to use it — opening a fresh tab and operating on it via helper — and contrasts it with the prior bare Target.createTarget approach. It lists sibling-relevant behavior (switches and attaches) but doesn't explicitly name alternative tools for different scenarios, so no explicit exclusion is stated.

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