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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partially covered. The description adds nothing beyond the action itself: it does not mention that the click may navigate, open dialogs, or submit data, nor the permission role of the 'element' parameter. Given a destructive, open-world tool, this is a thin description that leaves meaningful behavior undisclosed.

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?

It is a single, front-loaded sentence with zero waste, but it is undersized relative to a six-parameter destructive tool. Conciseness is achieved at the cost of all useful detail.

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, so the description should explain the post-click result (e.g., a new page snapshot). It also omits the session model, the permission flow implied by 'element', and the fact that clicking is open-world and potentially destructive. For a six-parameter, open-world interaction tool, this leaves major gaps.

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 six parameters (button, target, element, session, modifiers, doubleClick) are documented in the schema with enums and defaults. The description adds no extra semantic context for any parameter, 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 ('click') and resource ('web page'), making the action unambiguous. However, it does not differentiate from siblings like browser_hover, browser_drag, or browser_type, and adds no scope detail (e.g., that the target must come from a snapshot).

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 when-to-use guidance, no exclusions, and no named alternatives. It does not say that the target reference must be obtained from browser_snapshot first, nor when to prefer browser_type or browser_fill_form over clicking.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known from structured data. The description does add real value beyond that: it names the exact scope of destruction (tabs, cookies, storage) and carves out an exception that profile sessions retain saved logins on disk. It says nothing about what happens if the session id is unknown or already closed.

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 zero filler; the destruction scope is front-loaded and the profile-login caveat follows as a qualifier. 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 one-parameter destructive tool with no output schema, the description covers the important behavioral question (what is lost, what survives). The remaining gap is routing: nothing tells the agent how this relates to session_close, which is the most likely misuse path given the sibling list.

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% and the single 'session' parameter is documented in the schema as an isolated browser with a 'default' fallback. The description adds no meaning about the parameter, which is the correct baseline when the schema carries the burden.

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?

Specific verb (Close) plus resource (this session), with an enumeration of what is torn down: tabs, cookies, storage. It stops short of distinguishing itself from the near-identical sibling session_close, which an agent would reasonably confuse it with.

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 statement of when to call this versus session_close, or versus simply leaving the session open. Usage is only implied by the verb 'Close'. The default-session behavior (no argument) is also not addressed.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that: it does not mention filtering by level, navigation-scoped versus session-wide retrieval, session isolation, or file-saving behavior, all of which materially affect invocation.

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 single sentence is front-loaded and free of waste. However, for a tool with four parameters and meaningful filtering/session/file behavior, it is under-specified rather than genuinely concise.

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, and the tool has four parameters, one required enum, and session/file behavior. A one-line description covering none of that leaves an agent reliant entirely on the schema and annotations for correct invocation.

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 in the schema, including defaults and enum semantics. The description adds no parameter meaning beyond the schema; if anything, 'all console messages' is slightly at odds with the required level filter.

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 clear verb and resource: it returns console messages. It does not name or distinguish itself from siblings such as browser_network_requests or browser_evaluate, but the core purpose is unmistakable.

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 guidance on when to use this tool versus alternatives, no mention of prerequisites (such as needing an active browser session), and no exclusions. The agent must infer usage entirely from the tool name and schema.

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?

Annotations already disclose that this is a non-read-only, destructive, open-world interaction, but the description adds no behavioral context such as permission requirements, reliance on snapshot references, or what happens when an element is not found. It essentially restates the action without enriching the annotation profile.

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 a single front-loaded sentence with no wasted words. It states the action and the scope immediately.

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?

The schema and annotations are rich enough to make the tool callable, but the description omits important context for a browser interaction tool: it does not mention that element targets come from a page snapshot, nor does it explain drag semantics or failure behavior. Given the complexity, it 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?

Schema description coverage is 100%, so the parameters are well documented in the schema itself. The description adds no parameter-specific meaning, which meets the baseline when the schema does the heavy lifting.

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: 'Perform drag and drop between two elements.' It is clear what the tool does, but it does not distinguish itself from nearby interaction siblings such as browser_drop, browser_click, or browser_hover.

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 guidance on when to use this tool versus alternatives like browser_drop or browser_click, nor any stated prerequisites. The usage is only implied by the action described.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so the risk profile is covered. The description adds the external-drag simulation framing and the required-input constraint, but says nothing about what side effects a drop triggers (upload handlers, navigation, listeners) or the permission role of the 'element' parameter.

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, no filler, with the core action first and the precondition second. 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, open-world interaction tool with a nested 'data' object and no output schema, the description is thin: it omits what a successful drop produces, what the 'element' parameter does for permissions, and whether dropped files must exist locally. Adequate to call, but not complete.

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 baseline is 3, but the description adds a real constraint not encoded in the schema: the schema requires only 'target', while the description imposes that at least one of 'paths' or 'data' must be supplied. That is meaningful beyond what the structured fields say.

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 (drop) and resources (files or MIME-typed data) plus the semantic framing 'as if dragged from outside the page,' which implicitly separates it from browser_drag (in-page drag) and browser_file_upload (file input). It never names those siblings explicitly, so the differentiation is inferable rather than stated.

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 only guidance given is a precondition ('at least one of "paths" or "data" must be provided'), which is a constraint rather than a when-to-use rule. Nothing tells the agent when to prefer this over browser_file_upload or browser_drag, and no exclusions or prerequisites are stated.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the mutation profile is covered. The description adds useful state-management behavior (omitted = unchanged, null = clear), but doesn't explain persistence across navigation, whether a reload is needed, or how session isolation affects the emulation.

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 front-loaded sentences with zero waste: the first states what it does with an example, the second states the state semantics. Nothing redundant.

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 six-parameter, no-output-schema tool, the description covers purpose, example, and reset/omission semantics adequately. The only gap is that it doesn't describe lasting effect or interaction with navigation/reload, which an agent might reasonably wonder about for an emulation 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?

Schema coverage is 100%, so the schema already documents each enum parameter. The description nonetheless adds cross-parameter semantics absent from the schema: omitted values are preserved and null resets an override, which materially guides correct invocation across all six params.

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 (emulate) and resource (CSS media features for the page), with a concrete example (light/dark color scheme). An agent can distinguish this from siblings like browser_resize or browser_evaluate without opening the schema.

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 clarifies state semantics ('Omitted parameters are left unchanged; null clears an override') but gives no explicit when-to-use guidance or alternatives. It doesn't say when emulation is preferable to, say, resizing the viewport or reloading, leaving usage context implied.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, so the safety profile is known, but the description adds nothing about what arbitrary JS execution actually implies: page-context mutation, whether the page can navigate or fire network calls, how async/promises are handled, or what the result looks like. For a deliberately destructive, open-world capability, one sentence of behavioral context is a real gap beyond what the annotations carry.

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 single sentence is front-loaded and free of filler, but 'appropriately sized' cuts both ways: for a destructive code-execution tool, one clause is under-specified rather than efficient. It is concise without being informative.

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?

With five parameters, no output schema, and destructive annotations, the description should at minimum say what evaluation returns (text via filename, or the value) and what context it runs in. None of that is covered, so an agent must infer the entire return and side-effect model from the schema alone.

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 target, element, session, filename, and function are all documented, and the function field even shows the two accepted signatures with and without an element argument. The description's contribution is limited to the phrase 'or element', which only loosely ties the element-scoped form together, 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 a specific verb and resource ('Evaluate JavaScript expression') and adds the scope 'on page or element', so the core action is unambiguous. It does not distinguish itself from a close sibling like browser_run_code_unsafe, leaving the agent to infer the difference between page-context evaluation and running code in the automation context.

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 guidance on when to reach for this tool instead of browser_run_code_unsafe, browser_find, or browser_console_messages, and no stated preconditions (page must be loaded, element must come from a snapshot). The agent is given no exclusions or alternatives whatsoever.

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?

Annotations declare destructiveHint=true and openWorldHint=true, so the safety profile is carried by structured data; the description adds no context about what gets overwritten, whether the upload is one-way, or how the set of files interacts with the page. For a destructive, open-world tool the description contributes essentially nothing.

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 short sentence with no filler, so it is concise, but it is under-specified to the point of being non-informative for a multi-file, session-scoped, destructive operation. Brevity here comes at the cost of content rather than from trimming waste.

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?

With no output schema and a destructive, open-world annotation set, the description should explain the file-chooser workflow and the sibling relationship to browser_drop. Neither is present, leaving the agent to infer the entire invocation context from the schema alone.

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 the baseline is 3; the 'paths' and 'session' semantics, including the cancel-on-omit behavior and session isolation, are fully documented in the schema. The description repeats none of this and adds no meaning of its own.

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 ('Upload ... files'), which is clearer than a bare name, but adds nothing to distinguish it from the sibling browser_drop, which also delivers files into the page. An agent must open both schemas to tell them apart.

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 statement of when to use this versus browser_drop, nor any precondition such as a file chooser needing to be open or a dialog being triggered. The only usage-relevant fact (omitting paths cancels the chooser) lives in the schema, not the description.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the risk profile is covered structurally. The description adds nothing beyond that — no note on what happens to unfilled or existing values, whether submission occurs, or what verification the caller should do afterward.

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 zero waste. It is arguably under-specified rather than wordy, but as a structure it is tight and readable.

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?

This is a destructive, open-world browser mutation with no output schema, and the description says nothing about ordering of fills, element targeting prerequisites from a page snapshot, or what happens on partial failure. For a destructive tool in a large browser toolset, that leaves real gaps.

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%, including per-field guidance for target, type, value, and element, and the session parameter. Baseline 3 applies since the schema already carries all parameter meaning and the description adds none.

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 ('Fill ... form fields') and the word 'multiple' implicitly distinguishes it from the single-action browser_type. It does not name or contrast with any sibling explicitly, but the purpose is unambiguous.

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 indication of when to use this batch fill versus browser_type, browser_select_option, or browser_click. The agent must infer from the name alone that this is the multi-field path.

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?

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value beyond that by disclosing the return format (snippets with surrounding lines, each under its path from the root) and the cost trade-off versus a full snapshot.

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 action and return shape front-loaded and the cost rationale trailing. Every clause contributes — nothing restates the tool name or annotations.

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?

With no output schema, the description must explain return values, and it does (matching nodes plus context lines under their paths). Minor gaps remain: no mention of match limits, truncation, or what an empty result looks like, which matter for an agent deciding whether a miss is real.

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 text/regex/session/filename are fully documented in the schema. The description only alludes to the text-vs-regex choice and adds no syntax, default, or exclusivity detail beyond it; baseline 3 applies when the schema does the heavy lifting.

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 ('Search the accessibility snapshot of the current page') and names both the input forms (text or regex) and the output shape (matching snapshot nodes with surrounding context under their tree paths). This clearly differentiates it from browser_snapshot by framing it as the cheaper locate-an-element path.

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?

Gives a concrete selection rule: use this instead of capturing the whole snapshot 'when you only need to locate an element and its ref.' The alternative is described functionally rather than by sibling name, and no explicit when-not case is given, but the routing signal is unambiguous.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it never says that accepting a dialog commits the action (possibly a destructive confirm), that declining dismisses it, or how prompt input is supplied. With no annotations-vs-text conflict, this is a gap rather than a contradiction.

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 words are not concision but under-specification, matching the low-calibration pattern. There is nothing to front-load because there is essentially no content.

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 mutating, open-world tool with a required boolean that determines whether a page action is committed or cancelled, the description leaves the essential decision logic unexplained. The session isolation and promptText behavior must be inferred entirely from the 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?

Schema description coverage is 100%, so the schema already explains accept, session, and promptText; the baseline of 3 applies. The description contributes no additional semantics, such as what happens if promptText is omitted for a prompt dialog.

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?

"Handle a dialog" is nearly a restatement of the tool name and title. It does identify the resource (a browser dialog) but gives no indication of what handling entails — accepting, dismissing, or supplying prompt text — so an agent cannot distinguish it from siblings like browser_click or browser_press_key without opening the schema.

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 guidance on when a dialog exists or when to call this tool. It does not mention that dialogs block other page actions, nor how to discover a pending dialog (e.g., via browser_snapshot or browser_wait_for), and it names no alternatives.

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?

Annotations declare destructiveHint=true and openWorldHint=true, yet the description never explains what that means for a hover — e.g., that hovering can open menus, trigger tooltips, or change page state. With annotations carrying the safety flags, the description should still add context about side effects, but it adds none.

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?

Five words, front-loaded with the action and object, with zero padding. It is efficient, though the minimalism borders on under-specification rather than tight writing.

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?

The tool is simple and its parameters are fully documented in the schema, so an agent can mechanically invoke it. Still missing are any note about side effects of hovering and how the target reference should be sourced, which matters for a tool flagged as destructive and open-world.

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 'target', 'element', and 'session' parameters are already fully documented in the schema. The description adds nothing beyond that, which is the baseline case when the schema does all the work.

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 gives a specific verb (hover) and resource (element on page), so the basic action is unambiguous. However, it does nothing to distinguish this from closely related siblings like browser_click, browser_drag, or browser_find, all of which also target elements from a page snapshot.

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 guidance on when to use hover versus click, drag, or find, and no mention of prerequisites such as needing a fresh snapshot to obtain a target reference. The agent must infer everything about selection context from the name alone.

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?

Annotations already declare openWorldHint=true, destructiveHint=true, and readOnlyHint=false, so the risky, outward-facing nature is covered structurally. The description adds nothing — it doesn't say whether navigating replaces current page state, whether it blocks until load completes, or that it may discard unsaved form content.

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 words, front-loaded and waste-free, but the brevity comes at the cost of under-specification rather than disciplined editing. It is not verbose; it is simply thin.

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?

The one required parameter is well documented in the schema and the safety profile is in annotations, so an agent can technically call it. However, for a destructive, open-world navigation tool with 29 siblings and no output schema, the description omits what actually happens on invocation (load waiting, state replacement, error behavior).

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 both url and session fully documented inline (including session isolation semantics). The description contributes no additional parameter meaning, which is acceptable at baseline 3 given the schema does the work.

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 "Navigate to a URL" is a verbatim restatement of the tool's title and a near-restatement of its name (browser_navigate). It conveys the verb+resource but adds nothing an agent couldn't infer from the identifier, and it does not distinguish this from browser_navigate_back or browser_tabs.

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 guidance on when to use this versus alternatives such as browser_navigate_back, browser_tabs, or opening a session first. Usage is only implied by the name itself; no preconditions or exclusions are stated.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the description's job is lighter, but it adds nothing beyond the mechanical action. It does not say what happens if there is no prior history (error vs no-op), whether the action is reversible, or that the session is isolated — all relevant for a destructive navigation.

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. It is arguably too terse for the tool's risk profile, but that is a completeness issue rather than verbosity.

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 one-parameter navigation tool with annotations covering the safety profile, the description is barely sufficient. The notable gap is the no-history edge case, which an agent calling this needs to anticipate.

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% and the single 'session' parameter is fully documented there, including default and isolation semantics. The description adds no parameter information, 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 a specific verb and resource ('go back to the previous page') with the scope 'in the history', which cleanly separates it from the sibling browser_navigate (forward navigation). It stops short of explicitly naming that sibling, so the differentiation is implicit rather than stated.

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 guidance on when to use this versus browser_navigate or browser_tabs, and no mention of prerequisites such as needing an existing history entry. The agent must infer usage entirely from the tool 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered and the bar is lower. The description adds only the coarse shape of the return (headers and body vs. a single part); it says nothing about potentially large or binary bodies, or that output format changes when `filename` is used, which are the traits an agent actually needs here.

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 sentences, zero filler, with the primary behavior stated first and the sibling reference second. Every sentence 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?

With no output schema, the description carries the return-value burden, and it does state that headers and body come back. It is not fully complete: the exact serialization (text vs. saved file via `filename`) and behavior for large/binary payloads remain unstated, though these are minor for a read-only fetch-by-index 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?

Schema coverage is 100%, so baseline would be 3. The description nevertheless adds real semantics beyond the schema by explaining the `part` parameter's effect on the return shape ('or a single part if `part` is set') and by tying `index` to the sibling tool's printed numbering.

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 ('Returns full details (headers and body) of a single network request') plus the conditional variant when `part` is set. It explicitly separates itself from the sibling lister browser_network_requests, so an agent can tell list-vs-detail without opening either schema.

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 second sentence routes the agent to the correct prerequisite tool ('Use the number from browser_network_requests'), establishing the intended workflow. It stops short of stating exclusions (e.g., don't use for listing, or what to do when the index is out of range), so it is clear context rather than full when/when-not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context the annotations don't: the results are numbered/indexed and scoped to the current page load, which tells the agent how to chain into the detail tool. It omits the filename-save behavior, but the schema documents that.

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 sentences, zero waste, with the primary behavior front-loaded and the chaining guidance second. Every sentence 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 read-only inspection tool with full annotations and complete schema coverage, the description supplies what's missing: the output is a numbered list and how to expand entries. Slightly short on whether results persist across navigations or how large the list can get, but nothing needed for correct invocation is absent.

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 all four parameters (filter regexp, static toggle, session, filename) are already documented in the schema. The description only adds the numbering concept that connects to the sibling tool, so baseline 3 is 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+resource ('Returns a numbered list of network requests') with explicit temporal scope ('since loading the page'). It also names the sibling browser_network_request and its role, so an agent can distinguish the two without opening either schema.

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 routes the agent: use this tool to get the numbered list, then call browser_network_request with that number for full details. Clear context, though it doesn't mention when the filter/static options select this over other diagnostics like browser_console_messages.

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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is known. The description adds nothing beyond that — it doesn't warn that a key press can submit forms, trigger navigation, or fire dialogs, which is exactly the extra context this destructive tool needs.

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?

It is a single front-loaded sentence with no waste, but its brevity reflects under-specification rather than disciplined concision — there is room for a short clause on modifiers or focus prerequisites.

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, open-world browser action with no output schema, the definition is too thin: it says nothing about what state the page must be in, what side effects may follow, or how it relates to the other ~28 browser tools.

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% and both parameters (key, session) are documented in the schema, including the example formats `ArrowLeft` and `a`. The description contributes no additional meaning, but baseline 3 applies when the schema carries the burden.

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 ('Press a key on the keyboard'), but it is essentially a restatement of the tool name and adds no distinguishing scope. With siblings like browser_type, browser_fill_form, and browser_click, an agent cannot tell from this sentence what makes key-press distinct (e.g., support for modifier chords or special keys).

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 when-to-use guidance, no mention of alternatives such as browser_type for entering text, and no note about requiring a prior focus/snapshot action. The agent must infer everything about sequencing from context.

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?

Annotations declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, but the description adds nothing about what 'destructive' means here (changing viewport state, possible reflow), whether the window must exist, or what the resulting size units are. It simply repeats the annotation title.

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 zero waste and no burying of key information, though its brevity reflects under-specification rather than disciplined editing.

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?

With three parameters, a session-isolation model, and destructive/openWorld annotations but no output schema, the description should mention units, required preconditions (open session), and the visible effect of the resize. None of that is present.

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%, including width, height and the session parameter, so the schema carries the semantics and baseline 3 applies. The description adds no units (pixels vs CSS px), no min/max bounds, and no explanation of how width/height interact with the session parameter.

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 concrete verb and resource ('Resize the browser window'), so an agent knows the general action, but it is essentially a restatement of the name and title with no differentiation from siblings such as browser_emulate_media or browser_take_screenshot (where viewport size matters).

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 guidance on when to use this versus alternatives, no mention that a browser/session must already be open, and no indication of whether resizing affects screenshots or snapshots. The agent must infer all usage context.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered; the description adds genuinely new context by explaining WHY — arbitrary JS runs in the server process and is RCE-equivalent. It stops short of stating consequences (workspace filesystem access, credential exposure) or that the snippet's return value is passed back.

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, zero filler, with the risk warning placed immediately after the purpose so it cannot be missed before the agent crafts a snippet.

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?

The danger is well communicated and parameters are self-documenting, but with no output schema the description never states that the returned value of the async function is surfaced to the caller, nor whether side effects persist across sessions. Adequate but with a visible gap for a high-risk 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?

Schema coverage is 100%, so all three parameters (code, session, filename) are fully documented in the schema, including the precedence rule when both code and filename are supplied. The description adds nothing beyond that, which matches the baseline for fully documented schemas.

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?

Specific verb+resource ('Run a Playwright code snippet') with an explicit safety qualifier naming the execution context (Playwright server process). It is distinguishable from page-scoped siblings like browser_evaluate, though it never names that sibling to make the contrast airtight.

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 when-to-use guidance and no explicit alternatives — the description never says to prefer browser_evaluate or session-scoped tools for normal interaction. The 'Unsafe' label hints at last-resort use but leaves the routing decision entirely 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond the annotation data, such as whether selection triggers change events, how multi-select behaves, or what happens when values do not match options.

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. It is efficiently structured, though the brevity borders on under-specification rather than optimal concision.

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?

The tool has four parameters, full schema descriptions, and annotations covering safety and openness. The description is minimally adequate but omits useful context about permission requirements for the 'element' parameter and the practical distinction from other form-interaction tools.

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 parameters are documented directly in the schema. The description mentions 'dropdown' and 'option' but adds no syntax, format, or matching semantics beyond what the schema already provides.

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 ('Select') and resource ('an option in a dropdown'), so the basic action is clear. It does not distinguish this from siblings like browser_fill_form, browser_type, or browser_click, which also interact with form elements.

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?

Provides no guidance on when to use this tool versus alternatives such as browser_fill_form, browser_type, or browser_click. The agent must infer that this is for select/dropdown elements from the word 'dropdown' alone.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description contributes the relative-value claim versus screenshots, but says nothing about snapshot size, verbosity, truncation, or what the returned tree looks like — relevant for a tool with no output schema.

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 compact sentence with no wasted words; the purpose leads and the comparative claim follows. The run-on comma splice makes it slightly less polished but not less usable.

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 read-only browser tool with five optional parameters and no output schema, the agent is left guessing about the return format (text accessibility tree) and whether output can be large enough to warrant the filename option. Adequate but thin given the parameter surface.

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 every parameter (boxes, depth, target, session, filename) is already documented in the schema. The description adds no additional semantics, which is the expected baseline when the schema does the heavy lifting.

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: 'Capture accessibility snapshot of the current page'. It also positions the tool relative to a sibling capability ('better than screenshot'), though it does not name the actual sibling tool (browser_take_screenshot) or browser_find.

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 clause 'this is better than screenshot' implies a preference over browser_take_screenshot but gives no condition under which the alternative is still correct, and no guidance on when to prefer browser_find or browser_evaluate for extracting page data.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered upstream. The description adds nothing beyond repeating the action list: it does not say that 'close' discards tab state, that 'list' is a harmless read within an otherwise destructive tool, or that the four modes have very different risk profiles.

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 zero filler; the verb enumeration comes first. It is efficient, though the terseness is part of why usage context is thin rather than a fault of structure.

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?

This is a multi-mode tool bundling a safe read ('list') with destructive operations ('close'), with no output schema and no annotations explaining per-mode differences. Given the crowded sibling set (browser_navigate, browser_close, session_create), the one-line description leaves the agent without enough context to route between tools confidently.

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%, and every parameter (url, index, action, session) has a documented meaning including conditional use ('used for close/select', default session semantics). The description adds no parameter meaning 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?

The description names the resource (browser tab) and enumerates the four supported verbs (list, create, close, select), so the agent knows exactly what capability it exposes. It does not differentiate from close siblings such as browser_navigate or browser_close, which a reader might reasonably confuse with 'new' and 'close' here.

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 guidance on when to pick this tool over browser_navigate for opening a URL or browser_close for shutting down, nor any stated preconditions such as requiring an existing page. The agent is left to infer that 'new' supersedes navigation behavior.

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?

Annotations already declare this as a safe read-only, open-world operation. The description adds important context beyond annotations: the screenshot is visual output and cannot be acted upon, so agents must not confuse it with DOM/interaction data from browser_snapshot.

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 two short sentences with the main purpose front-loaded and no wasted wording. The limitation and alternative are stated immediately after the purpose.

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 screenshot tool with rich schema coverage and safety annotations, the description gives enough guidance to select and invoke it correctly. The main minor gap is that it does not describe the return value or where the screenshot is saved, though the filename parameter hints at this.

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 documents all seven parameters, including format, scale, target, filename, and fullPage. The description adds no parameter-specific semantics, which is acceptable when the schema is this complete.

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: taking a screenshot of the current page. It also distinguishes the tool from its sibling browser_snapshot by explaining that screenshots cannot be used to perform actions, so an agent can route correctly without opening either schema.

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 a clear usage boundary: use browser_snapshot when you need to perform actions, and use this tool only to capture a screenshot. It does not explicitly state when to prefer full-page or element screenshots, but the core alternative is named.

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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds only 'editable element' as a constraint and never says whether existing text is replaced or appended, nor what happens on failure or with submit=true — a real gap for a destructive write 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 tight sentence with no filler and the core action front-loaded. Its brevity is efficient, though it edges toward under-specification rather than genuine conciseness.

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 six-parameter, destructive, open-world mutation tool with no output schema, the description should explain replacement semantics, session targeting implications, and interaction with submit. None of that is present, so an agent can call it but cannot predict its effects confidently.

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 every parameter including the nuanced 'slowly' and 'submit' flags is documented in the schema itself. The description contributes nothing additional, which matches the baseline 3 when the schema does the work.

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 ('Type') and resource ('text into editable element'), which is clearer than the bare name alone. It does not, however, distinguish itself from sibling tools like browser_fill_form or browser_press_key, leaving the agent to infer the boundary.

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 guidance on when to use this versus browser_fill_form, browser_press_key, or browser_select_option, and no prerequisites (e.g. needing a snapshot-derived target) are stated. The agent must infer usage entirely from the name and schema.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral modes of waiting for text or time, but does not explain timeout behavior or what happens when the condition is not met.

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 a single efficient sentence with no wasted words. The core action and wait conditions are front-loaded.

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 parameterized browser wait tool with full schema coverage and annotations, the description is largely complete for selection and invocation. The main omission is timeout or failure behavior, but the schema covers individual parameters and annotations cover safety.

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 parameter meanings are already documented in the schema. The description echoes the wait conditions covered by text, textGone, and time but adds no additional syntax or constraint details 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?

The description uses the specific verb "Wait" and names the three wait conditions: text appearance, text disappearance, or elapsed time. It is clear what the tool does, though it does not explicitly contrast itself with sibling browser tools.

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 states the wait modes but gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer usage context from the tool name and schema.

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?

Annotations already flag destructive/openWorld/non-idempotent, so the description adds real context beyond them: tasks run concurrently server-side, each in an isolated session, and per-task output should be kept small. The key cross-step constraint (a task cannot use snapshot refs it hasn't seen) is a genuinely non-obvious behavioral trait. It does not discuss aggregate failure behavior across tasks, which would have made this a 5.

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?

Four dense sentences, front-loaded with the purpose and the concurrency model, then the targeting constraint, then the output-size tip. No filler and every sentence carries actionable content.

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 nested, high-complexity batch tool with no output schema, the description covers the mental model (independent sessions, concurrent execution), the main pitfall (snapshot refs), and output trimming. Remaining gaps such as result shape per task and cross-task error aggregation are either covered by the schema's `output`/`stopOnError` descriptions or minor.

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 83%, so the baseline is 3, but the description adds construction guidance for the required `tasks` parameter: steps run in order, each step targets a tool by name, and element targeting must use selectors rather than unseen refs. That is meaning beyond the schema's field-level text.

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 ('Run many browser tasks at the same time in ONE call') and immediately clarifies granularity: each task is an ordered list of browser_* steps in its own session. This clearly distinguishes it from the single-action browser_* 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?

Gives concrete use cases ('visit or scrape many pages at once', 'repeat a flow across sessions') and points to workarounds (CSS selectors, browser_evaluate, browser_run_code_unsafe) when snapshot refs are unavailable. It does not explicitly say when not to use it, e.g. for a single task where individual browser_* tools suffice.

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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: memory is freed, and profile sessions persist saved logins to disk — telling the agent that closing is not uniformly lossy.

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 zero filler, and the scope statement precedes the caveat about persistence. Every clause carries information an agent actually needs.

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?

With annotations covering destructiveness and idempotency, full schema coverage, and no output schema, the definition is nearly self-sufficient; the persistence note fills the main remaining behavioral gap. Minor omission: no returned identifier or error behavior when a named session does not exist.

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 both parameters are already documented in the schema, including the session name pattern. The description only echoes the one-vs-all distinction without adding format, precedence, or conflict behavior (e.g., what happens if both are supplied), so it lands at the 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?

Specific verb+resource: closes sessions and frees their memory, with the one-vs-all scope stated up front. It does not distinguish itself from the sibling browser_close, which an agent could easily confuse with closing a whole 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 phrase 'one session, or all' implies the choice between the `session` and `all` parameters, which is adequate minimum-viable guidance. There is no explicit statement of when to prefer this over browser_close, session_list, or session_create, nor any exclusion or 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: each session has isolated cookies/storage/tabs, and a session materializes implicitly on first browser_* call with an unknown id. It does not say what happens when the requested session id already exists or how many concurrent sessions are allowed, which matters given idempotentHint=false.

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 sentences, front-loaded with the core action before the caveat and the use-case list. The parenthetical isolation detail and per-option phrases all earn their place; only the use-case sentence is slightly dense with five items packed together.

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 10-parameter creator with no output schema, the description covers purpose, isolation semantics, the implicit-creation behavior, and the intent of the distinguishing options, while the rich schema handles formats and bounds and the annotations handle safety. Nothing an agent needs in order to call it correctly is clearly 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 80%, so a baseline of 3 is already earned by the schema. The description goes past it by giving the intent behind the notable options — headed for watching/logging in by hand, profile for logins that survive restarts, cloneFrom for starting a worker already logged in — though viewport, userAgent and timezoneId are left entirely to 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 and resource — 'Open a new isolated browser session' — and immediately defines what isolation means (own cookies, storage and tabs). Against siblings like session_list and session_close, an agent can tell this is the creator without opening any schema.

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?

Enumerates concrete selection reasons (headed window, saved profile, device emulation, blockResources, cloneFrom) and adds an important 'when not needed' note that any browser_* call with a new session id auto-creates a default session. It stops short of naming the complementary siblings (session_close, session_list) or stating cleanup expectations, so it is clear context rather than full routing.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds useful return context by naming mode, tabs, and busy status, though it omits ordering or pagination behavior.

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 a single efficient sentence with the main purpose and returned fields front-loaded. Every phrase 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 zero-parameter read-only listing tool, the description plus annotations provide enough context to call it correctly. Although there is no output schema, the description names the key returned attributes.

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, so there are no parameter semantics to explain; baseline 4 applies. Schema description coverage is 100%, leaving nothing ambiguous for the agent to supply.

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 gives a specific verb/resource (List open sessions) and states the returned attributes (mode, tabs, busy). It is clear what the tool does, though it does not explicitly differentiate itself from session_create or session_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?

There is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The usage is only implied by the name and one-line description.

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