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

No annotations are provided, so the description carries the full behavioral burden. It discloses the affected scope and the active-session safety guarantee, but does not state whether cleanup is irreversible, what permissions are required, or what happens to the cleaned directories.

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?

A single front-loaded sentence with no wasted words. The scope and the key exclusion are both stated efficiently.

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 zero-parameter cleanup tool, the description covers purpose, scope, and the active-session exclusion adequately. Minor gaps remain around destructive semantics, permissions, and output behavior, especially since there are no annotations or output schema.

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 tool has zero parameters and an empty input schema. Per the rubric, zero-parameter tools receive a baseline of 4, and there are no parameters whose semantics need additional explanation.

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: 'Clean up inactive/orphaned browser sessions and directories.' The clause 'without affecting active sessions' distinguishes it from close_browser and close_all_browsers.

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?

Clearly implies when to use it: for inactive/orphaned sessions and directories, while excluding active sessions. It does not explicitly name alternatives such as list_sessions or close_browser, so it falls short of a full 5.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the two-phase close (graceful first, force-kill fallback), which is real behavioral context. However, it omits what actually gets destroyed, whether session data/directories are cleaned, permission requirements, and return behavior, which matters for a destructive process-killing tool.

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?

A single front-loaded sentence with no filler; the core action and the fallback behavior are stated compactly. Every clause earns its place.

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 destructive, no-annotation mutation tool with no output schema, the graceful/force behavior is covered but the blast radius is not: it doesn't say what data is removed, whether directories are cleaned, or what the result looks like. Adequate but incomplete for its risk profile.

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 single 'force' param is fully documented in the schema (100% coverage), so the baseline is 3. The description adds modest value by explaining the default non-force path ('tries to close properly first'), which contextualizes what force=true skips, but adds no syntax or format detail beyond the schema.

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 ('close') plus resource ('all active browser sessions'), and the 'all' scope cleanly distinguishes it from the sibling close_browser and from cleanup_sessions. An agent can tell what it does and that it targets every session, not one.

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?

No explicit when-to-use, when-not-to-use, or alternative routing (e.g. close_browser for a single session, cleanup_sessions for leftovers). Usage is only implied by the tool name; the description offers no selection guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose two meaningful traits: the close is 'graceful' and it destroys session data, which is useful. However, it omits whether cleanup is reversible, what happens with an invalid or already-closed session, and whether other sessions are unaffected.

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?

One sentence, front-loaded with the action and resource, with no filler. Every clause ('gracefully', 'clean up session data') carries information.

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 zero-required-param teardown tool with no output schema, the description covers purpose, scope, and the cleanup side effect adequately. It could go further on sibling disambiguation and post-close state, but nothing essential to a correct call is missing.

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 100% and the single optional sessionId already documents its default behavior. The description adds no syntax or semantics beyond the schema, so the baseline 3 applies.

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 ('close') and resource ('browser connection'), plus the side effect of cleaning up session data. It is distinguishable from close_all_browsers by scope ('the browser connection' vs. all), but the description never explicitly contrasts the two siblings.

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 only implied by the name and scope. There is no explicit guidance on when to use this versus close_all_browsers or cleanup_sessions, nor any note about calling it at end of a workflow.

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

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

With no annotations, the description carries the full burden and does disclose the non-obvious mechanics: a floating 'Finish Connect' button, that it persists across redirects, and that capture happens only after manual click. It still omits timeout/failure behavior and whether the call blocks indefinitely while waiting.

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?

Three front-loaded sentences, the interaction model first and the button detail after; little waste beyond the leading emoji. Every sentence conveys usable behavior.

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?

No output schema exists, yet the description never says what 'authentication data' is captured or in what form (cookies, tokens), leaving the return value underspecified. Combined with the silent timeout/failure behavior, a call-blocking interactive tool is only partially covered.

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 100%, so the schema already fully documents url, autoClose, saveToFile, and waitMessage. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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 specific verbs and resource: opens a browser to a URL, waits for manual login, then captures authentication data. The 'INTERACTIVE LOGIN' framing clearly separates it from siblings like launch_browser and navigate_to, which do not perform credential capture.

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 by the description – you use this when a site requires manual authentication and you want the resulting session data. However, it never states when NOT to use it or points to alternatives such as set_storage (when cookies already exist) or launch_browser for unauthenticated browsing.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavioral facts: per-instance session IDs, ports, and isolated user data directories. However, it says nothing about failure modes, whether the call blocks until the browser is ready, lifetimes, or the need to clean up sessions.

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 tightly written sentences with the main action front-loaded and no filler. The second sentence adds isolation context that earns its place.

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?

Adequate for a zero-required-parameter launcher with a fully documented schema, and the mention of session IDs implicitly covers the return value. It is still incomplete on lifecycle: how long the session lives and when to invoke close_browser or cleanup_sessions is left unstated.

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 100% and there is only one optional parameter, so the schema fully documents debugPort including auto-assignment. The description adds no syntax or format detail beyond that, making the baseline 3 appropriate.

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 ('Launch Chrome browser') plus a distinguishing scope ('with session management'), which separates it from siblings like close_browser and list_sessions. It does not explicitly name an alternative, so it stops short of a 5.

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?

There is no explicit guidance on when to launch versus reuse an existing session, nor any note about the relationship to cleanup_sessions or close_browser. Usage is only implied by the tool name and the mention of session IDs.

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

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

With no annotations, the description carries the full burden, but 'List' strongly implies a safe read-only operation and 'active' scopes the result set. It still says nothing about return format, pagination, or what counts as a session (e.g. whether background scripts count).

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?

A single tight sentence with the resource and scope front-loaded and no filler. Nothing could be trimmed without losing meaning.

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 zero-parameter read tool with no output schema, a one-line description is close to sufficient, but it leaves 'active session' undefined and gives no hint about what the result contains. Adequate but with a clear gap.

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 tool takes zero parameters, so the schema cannot carry any parameter meaning and the description has nothing to compensate for. Baseline 4 applies.

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 ('List all active browser automation sessions'), which clearly reads as a non-mutating inspection tool. It does not explicitly differentiate itself from siblings like cleanup_sessions or close_all_browsers, though the verb does most of that work.

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?

No guidance on when to use this versus alternatives such as cleanup_sessions or close_all_browsers, and no stated prerequisites. The agent must infer the use case entirely from the name.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the prerequisite that the browser must be launched first and implies the current page is changed, but it omits side effects such as whether navigation replaces the current page, error handling, and return behavior. The waitUntil parameter is documented only in the schema, not the description.

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 three short sentences, front-loads the core action, and contains no redundant or filler content. Every sentence contributes to understanding the tool's purpose or prerequisite.

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 simple navigation tool with a fully documented schema, the description covers the core action and the key prerequisite. It lacks details about return values and failure modes, but those are minor gaps given the tool's straightforward nature.

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 100%, so the schema already fully documents url, sessionId, and waitUntil. The description adds no parameter-level details beyond what the schema provides, so the baseline score of 3 applies.

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 states a specific verb and resource: 'Navigate to a URL in the browser.' It also clarifies the action with 'open web pages or refresh the current page' and distinguishes itself from the sibling launch_browser by requiring it first.

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?

It gives clear context for when to use the tool (opening web pages, refreshing the current page) and a prerequisite (browser must be launched first using launch_browser). However, it does not explicitly state when not to use it or name alternative tools beyond the launch prerequisite.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses only that the script gets browser-automation access. It says nothing about the fact that a remote URL means executing arbitrary third-party code, what happens on failure, timeout limits, or whether the script can mutate browser/session state.

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?

Three short sentences, front-loaded with the action and resource, with the critical mutual-exclusivity constraint placed last for emphasis. The leading emoji is noise but does not materially bloat the text.

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 7-parameter tool that executes arbitrary code with no annotations and no output schema, the description should explain how results surface (return value, logs, screenshots) and any sandboxing or session implications. It leaves the agent guessing about the execution model beyond the source-of-script rule.

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 100%, so all seven parameters are already documented, including the scriptPath/scriptUrl conflict and the nested args object. The description's "either scriptPath OR scriptUrl (not both)" restates the schema's own constraint rather than adding new meaning, so the baseline 3 applies.

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 (Execute) and resource (a JavaScript file) plus the two accepted sources (local path or remote URL), which is concrete and unambiguous. It does not, however, differentiate itself from the obvious sibling run_script_background, which an agent must choose between.

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?

"Use for complex automation scripts or reusable workflows" gives a rough sense of when this tool fits, but offers no exclusions and never names the alternative (run_script_background for non-blocking execution, or navigate_to for simple navigation). The mutual-exclusivity rule is invocation guidance rather than when-to-use guidance.

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

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

With no annotations present, the description carries the full burden. It does disclose two important traits — that it returns immediately while work continues, and that output is persisted to files — which is real value. But it omits failure behavior, concurrency limits, and whether it requires an existing browser/session, which matters for a 9-parameter automation tool.

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?

Three short sentences, front-loaded with what the tool does before the constraint. The leading emoji is noise, but the prose itself is tight and wastes little.

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 9-parameter tool with nested args and no output schema, the description covers execution semantics and the output-file behavior reasonably. It does not address session/tab lifecycle implications (createNewTab, autoCloseBrowser) or what the returned 'task info' contains, which the absent output schema leaves unexplained.

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 100%, so every parameter is already fully documented, setting the baseline at 3. The description only reinforces the scriptPath/scriptUrl exclusivity that the schema already states, adding no meaning beyond it.

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 (Execute) and resource (a JavaScript file) plus the distinguishing mode ('in the background') and the immediate-return behavior. It does not, however, contrast itself with the sibling run_script, so an agent must infer the foreground/background split on its own.

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 one hard usage rule ('Must provide either scriptPath OR scriptUrl (not both)'), which is genuinely helpful for invocation. It offers no guidance on when a background run is preferable to run_script or when to pass a sessionId, leaving the primary use-case decision to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never says whether existing cookies/storage are overwritten or merged, whether the operation is reversible, what permissions or session state are required, or how errors surface for an 8-parameter mutation tool.

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 tight sentences, front-loaded with the tool's purpose and the preference over evaluate(). No filler or redundant restatement of the name.

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?

Parameters are fully documented in the schema, but for a no-annotation mutation tool the description omits overwrite semantics, scope across tabs/sessions, and failure behavior. Adequate but with clear gaps for a tool this complex.

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 100%, with rich per-field documentation including examples and defaults, so the schema already does the heavy lifting. The description adds no syntax, precedence, or interaction detail (e.g., cookieString vs cookies vs filePath) beyond what the schema states.

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 set (set cookies, localStorage, sessionStorage) and explicitly frames itself as the tool for login/auth state. It differentiates from evaluate(), though that alternative is not among the listed siblings, so differentiation from tools like run_script or get_login is left implicit.

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?

Explicitly says to prefer this over evaluate() for setting login state, which is actionable when-to-use guidance. It stops short of stating when NOT to use it or how it relates to siblings such as get_login or run_script.

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