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 by structured data. The description adds nothing beyond the action itself: it does not explain side effects like form submission, navigation, or permission prompts for specific elements.

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 short sentence with no wasted words. However, for a tool with six parameters and multiple sibling interactions, such extreme brevity means it is under-specified rather than ideally 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?

The schema and annotations are rich enough to cover parameter details and safety hints, but the description still omits essential context for correct invocation: when clicking is appropriate versus dragging or hovering, and what side effects to expect on a live page. No output schema exists, so return values do not need explanation, but behavioral and selection guidance are 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 description coverage is 100%, so the input schema fully documents all six parameters, including ref, button, modifiers, sessionId, and doubleClick. The description adds no parameter-level meaning, so the baseline of 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?

The description states a specific verb ('click') and resource ('web page'), so the core action is immediately clear. However, it does not differentiate this tool from siblings like browser_drag, browser_hover, or browser_type, leaving the agent to infer when clicking is preferred over those alternatives.

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 offers no guidance on when to use browser_click versus alternatives such as browser_drag, browser_hover, or browser_type. It also omits any prerequisites, such as obtaining a valid element reference from a page snapshot before 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, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it doesn't say whether unsaved page state is lost, whether the session survives, or what happens if no page is open.

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 phrase with no wasted words, but it is under-specified rather than genuinely concise; the brevity leaves scope ambiguous instead of front-loading useful constraints.

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 one fully documented optional parameter, an annotations-covered destructive profile, and no output schema, the structured data carries most of the load. The missing piece is what exactly is destroyed and how this differs from session_close, which is the one thing an agent most needs here.

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 parameter (sessionId) is fully documented in the schema, including the 'omit to use the active session' default. The description contributes no additional parameter meaning, 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+resource ('Close the page'), which is clearer than a tautology, but the annotations' title ('Close browser') conflicts in scope with the description ('page'), and nothing distinguishes this from session_close or browser_tabs. An agent cannot tell from the text alone whether this closes a tab, a page context, or the whole browser 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?

There is no when-to-use guidance and no mention of the closely related siblings session_close (closes a session) or browser_tabs (may close tabs). The agent must infer the boundary between closing a page and closing a session entirely from the names.

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 safety is covered structurally. The description adds nothing beyond that — no note about the default lookback window, the level cascade behavior, or that output may be written to a file instead of returned inline.

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 five-word sentence is maximally concise and front-loaded, but here brevity comes at the cost of accuracy and utility rather than earned economy. There is no wasted sentence, but there is also almost 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 4-parameter tool with no output schema, the description omits the return format (text vs. saved file) and the scope defaults that determine what the agent actually receives. The misleading word 'all' makes the gap worse, since an agent could reasonably expect a full-session dump by default.

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 fully documents 'all', 'level', 'filename' and 'sessionId', including the level cascade and the default lookback window. The description contributes no additional parameter meaning, 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 clear verb and resource ('Returns all console messages'), so the agent knows it reads console output. However, 'all' is inaccurate: the schema shows the default returns only messages since the last navigation and only levels at or above the requested severity. It also does not distinguish itself from the sibling browser_network_requests.

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 reach for this tool versus browser_network_requests, browser_evaluate, or browser_snapshot. There is no mention of prerequisites such as having an active page or session, and no exclusions.

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 further behavioral context such as permission requirements, effects on page state, or interaction constraints, leaving it with minimal added value beyond the structured annotations.

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 contains no wasted words, making it appropriately sized for a tool with a clear core action. It could be slightly more informative without becoming bloated, but it avoids unnecessary repetition.

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 full schema coverage and annotations covering safety, the description is minimally adequate for invoking the tool correctly. However, it omits important contextual details such as when the tool should be chosen over siblings and any constraints around element references or session handling, leaving gaps for an agent unfamiliar with browser automation.

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 each parameter's meaning and requirements are fully documented in the schema. The description only implies a start and end element, adding negligible semantic detail beyond what the structured parameter descriptions provide. A baseline 3 is appropriate when the schema carries this 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 ('perform drag and drop') and clearly identifies the operation as being between two elements. It is distinct from sibling tools like browser_click and browser_hover, but it does not explicitly name or contrast those siblings, keeping it just 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 guidance on when to use this tool versus alternatives such as browser_click, browser_hover, or browser_fill_form, nor any prerequisites or exclusions. The usage is only implied by the tool name and description, which is insufficient for confident selection.

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 known. The description adds nothing beyond that: it does not warn that arbitrary code runs in page context, that DOM mutations persist, or that return values must be serializable (the filename fallback is only in the 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?

One efficient, front-loaded sentence with no filler. It is appropriately sized, though arguably terse to the point of under-specification for a destructive execution tool.

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 what comes back (text result, or file when filename is given) and the serialization constraint. For a destructive, arbitrary-code tool with a required function parameter, this is a meaningful 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?

Schema description coverage is 100%, so the function signature, element ref, filename and sessionId semantics are already documented. The phrase 'on page or element' lightly signals that element changes the function signature, but adds no detail beyond the schema. 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 and resource: evaluate a JavaScript expression against a page or element. That is clearer than a restatement of the name, but it offers no differentiation from the close sibling browser_run_code, which an agent must otherwise infer from schemas.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives such as browser_run_code or browser_console_messages. The agent must guess which execution tool is appropriate from 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 readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that - no mention of file chooser interaction, session targeting behavior, or what happens when the operation is invoked without a pending chooser.

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 wasted words, and the core action is front-loaded. It is efficient, though arguably under-specified rather than genuinely well-structured.

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 two-parameter tool with full schema coverage, complete annotations, and no output schema, the description is minimally adequate. It omits the file-chooser interaction model and session context, which are the main behavioral nuances an agent would need.

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 (paths, sessionId) are already fully documented, including the 'file chooser is cancelled if omitted' behavior. The description adds no additional parameter 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?

The description states a specific verb (upload) and resource (files), and adds cardinality ('one or multiple'). This is clear enough to know the operation, but it does not differentiate from siblings or mention the browser/file-chooser context that the name implies.

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, nor any prerequisites (e.g., that a file chooser must be open or that a page is waiting on input). The agent is left to infer all triggering conditions.

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. The description adds no behavioral context beyond annotations, such as what happens on failure, how refs are validated, or whether form submission occurs.

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 short phrase with no verbosity, but it is essentially a restatement of the tool name and provides no structural elaboration. It is concise but arguably too sparse to be considered well-structured for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is destructive, open-world, and interacts with dynamic web forms, the description lacks necessary context such as when to use it versus browser_type, the need for a page snapshot to obtain refs, or any session-related behavior. Annotations and schema cover safety and parameters, but usage context 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 description coverage is 100%, and the schema thoroughly documents the fields array and sessionId. The description adds no parameter-level meaning, so the baseline of 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?

The description states a specific verb and resource: 'fill' and 'multiple form fields.' It is clear what the tool does. However, it does not differentiate from sibling tools like browser_type or browser_select_option, which likely handle single-field or option-specific interactions.

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 prerequisites such as requiring a page snapshot, and no mention of limitations or exclusions. The description only states the action.

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, readOnlyHint=false, and openWorldHint=true, so this is a mutating, potentially destructive action — yet the description discloses nothing about side effects, what accepting vs dismissing does, or irreversibility. The description carries the full behavioral burden here and adds zero context.

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 is not conciseness but under-specification. There is no wasted sentence, but there is also no substance — the text fails to earn its place as a tool description.

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 browser action with no output schema and no annotations that explain behavior, the description is completely inadequate. It omits the dismiss/accept semantics, prompt-text requirement, and session targeting that an agent needs to call it correctly.

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 all three parameters (accept, sessionId, promptText) are documented in the schema itself. Baseline 3 applies; the description adds no parameter meaning 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 'Handle a dialog' restates the tool name and title rather than explaining the operation. It does not distinguish this from siblings in any meaningful way beyond the word 'dialog', and gives no hint of what 'handle' entails (accept vs dismiss vs supply prompt text).

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 call this tool, no mention of when a dialog appears, and no alternatives or prerequisites. An agent must infer everything 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 provide the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), so the description only needs to add context. It adds none – no disclosure of what hover triggers, what state changes or reveals elements, or whether a wait/follow-up is needed. It does not contradict the annotations, but it contributes no behavioral information.

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 phrase is front-loaded and wastes no words, but it is under-specified rather than genuinely concise. There is no wasted text, yet also not enough substance to earn a higher score.

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 an interactive page tool with no output schema and annotations that oddly flag it as destructive, the description is too thin: it omits what hovering accomplishes, whether it triggers navigation or state change, and any prerequisites for the ref. An agent can call it mechanically but lacks the context to know when it is appropriate.

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 ref, element, and sessionId are all documented in the schema itself. The description adds no syntax, format, or semantic detail beyond the schema, 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 (hover) and resource (element on page), so an agent can identify the action. It does not distinguish this from siblings like browser_click or browser_drag, leaving the differentiation to the agent to infer.

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 when hovering is required (e.g. to reveal menus or tooltips), and no reference to alternatives such as browser_click. Nothing tells the agent when this tool is the right choice over the other 24 browser/session tools.

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 nothing beyond them: it never warns that the current page state is discarded, that navigation reaches the open web, or how it interacts with the current session. With annotations present the bar is lower, but zero added behavioral context merits a low score.

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 as short as possible and front-loads the action, which is good, but the single sentence largely duplicates the title and earns little of its place. Conciseness here shades into under-specification.

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 navigation tool flagged destructive and open-world, with no output schema, the description omits whether the call blocks until the page loads, what happens to existing page state, and how it relates to the active session. Annotations carry the risk labels but the operational picture is 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%, with both 'url' and 'sessionId' documented in the schema, so the baseline is 3. The description contributes no additional semantics such as URL format, whether relative paths are accepted, or what 'active session' means in practice.

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 a specific verb and resource ('Navigate to a URL'), so the core action is unambiguous. However, it is essentially a restatement of the tool name and the annotation title, and it gives no differentiation from close siblings like browser_navigate_back or browser_tabs. Minimum viable rather than genuinely informative.

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 when to prefer browser_navigate_back, and no note about starting versus reusing a session. The agent must infer all routing from sibling names 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=false, destructiveHint=true and openWorldHint=true, so the safety profile is carried by structured data. The description adds nothing beyond the bare operation – it doesn't say what happens when there is no history entry (no-op vs. error), whether it waits for load, or how it interacts with 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?

A single short sentence that front-loads the action and contains no filler. Nothing could be trimmed without losing the core 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-required-parameter navigation tool with full schema coverage and no output schema, the description is nearly sufficient. The only meaningful gap is the absence of failure/no-history behavior, which is minor given the annotations cover the mutation 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?

There is a single optional parameter (sessionId) documented at 100% schema coverage, including the 'omit to use the active session' default. The description adds no further meaning, so the baseline of 3 applies – 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 (go back) and resource (previous page in browser history), making the operation unambiguous. It doesn't explicitly contrast itself with the sibling browser_navigate (forward navigation to a URL), but the distinction is obvious from the wording.

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 phrase 'previous page in the history' – an agent can infer this is for retreating one step in session history. However, there is no explicit when-to-use versus browser_navigate, nor any note about the condition when no prior history exists.

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 safety is covered. The description adds one genuinely useful behavioral fact, the capture window ('since loading the page'), but says nothing about output form, volume limits, or that results are per-session — gaps the annotations do not fill.

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 scope constraint appears immediately. It is arguably too terse for a six-parameter tool, but nothing in the text is wasted.

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 is minimal: it conveys what is returned and the capture window, but omits how results are shaped, whether pagination or truncation applies, and the need for an active page/session. Annotations and the rich schema cover much of the rest, keeping this at a minimally adequate level.

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 (filter, static, filename, sessionId, requestBody, requestHeaders) is self-documenting. The description adds no parameter meaning beyond the schema, 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 ('Returns all network requests') plus a meaningful temporal scope ('since loading the page'). It is clearly distinguishable from write-oriented siblings like browser_click or browser_navigate, though it does not explicitly contrast with the nearest sibling, browser_console_messages.

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 no when-to-use guidance, no prerequisites (e.g. that a page must be loaded first), and never names an alternative tool for related diagnostics. The intended usage is only weakly implied by the phrase 'since loading the page'.

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, and the description adds nothing on top of them – no indication that a keypress acts on whatever is currently focused, that it can trigger destructive page actions, or how the session target interacts with behavior. The description carries zero behavioral value and contradicts nothing, so it sits at the bottom 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?

A single front-loaded sentence with no wasted words, which is structurally clean. But the terseness reads as under-specification rather than genuine conciseness – nothing beyond the minimum verb+resource is included.

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 browser-input tool flagged destructive and open-world, with no output schema and no guidance in the description, an agent lacks the context to call it safely (focus requirements, session behavior, what a keypress may trigger). The structured fields alone do not cover this 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?

Schema description coverage is 100%: the schema explains both the `key` parameter (e.g. `ArrowLeft` or `a`) and `sessionId` (omit to use active session). The description adds no syntax or naming detail 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 gives a concrete verb+resource ('Press a key on the keyboard'), so the basic action is unambiguous. However, it offers no differentiation from close siblings like browser_type or browser_fill_form, which also send keyboard input, leaving an agent to infer the boundary. Vague-but-adequate: purpose is stated, the distinction from siblings is not.

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 statement of when to use this tool versus browser_type (typing text) or browser_fill_form, and no preconditions such as the need for an element to be focused first. Usage must be entirely inferred from the name. This is the 'no guidance' tier.

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, and the description adds nothing beyond them — no note that resizing is reversible, no effect on in-flight page state, no mention of units or constraints. The bar is lower with annotations, but the description contributes essentially zero behavioral context.

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, front-loaded with the verb and resource, with no wasted words. It is efficient but arguably under-specified rather than merely 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?

For a small three-parameter mutation tool with no output schema and full schema coverage, the description is minimally adequate. The notable gap is that no unit or range information for width/height appears anywhere, which the agent would need to resize correctly.

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 width, height, and sessionId are already documented in the schema, establishing a baseline of 3. The description adds no extra meaning, notably omitting whether width/height are pixels, CSS pixels, or device pixels.

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 (Resize) and resource (the browser window), so the agent knows exactly what the tool does. No sibling differentiation is offered, but browser_resize is the only resize tool among the siblings, so ambiguity risk is low.

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 resize versus other viewport-affecting operations, no mention of the optional sessionId semantics or when to omit it, and no prerequisites. The agent must infer usage 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?

Annotations already declare destructiveHint=true, openWorldHint=true and readOnlyHint=false, so the risk profile is covered structurally. The description adds nothing beyond that — it never warns that arbitrary code executes in the page context, nor explains what the snippet returns. With annotations carrying the safety load, this is a minimal-value 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?

A single four-word fragment is admirably front-loaded and waste-free, but it is under-specified rather than genuinely concise — there is no room left for required context.

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 an arbitrary-code-execution tool with no output schema, the definition should say what the snippet's return value becomes and confirm page/session scoping. Neither is present, leaving the agent guessing about results and side effects.

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 schema richly documents code, filename (including the precedence rule when both are given) and sessionId. Baseline 3 applies since the description itself adds no parameter meaning.

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 Playwright code snippet"), so an agent understands this executes arbitrary Playwright/JS against a page. It does not distinguish itself from siblings like browser_evaluate or the dedicated action tools, but the purpose is clear.

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 reach for this generic escape hatch versus the dedicated tools (browser_click, browser_type, browser_evaluate) or when to supply code vs filename. The agent must infer that this is a fallback for actions no sibling covers.

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 agent knows this mutates page state. The description adds nothing beyond that: it does not mention that selection may replace existing values, permission requirements via the 'element' param, or session targeting. It is consistent with (not contradictory to) the annotations, but contributes no extra behavioral context.

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 efficient, though its brevity borders on under-specification rather than ideal 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 simple destructive mutation tool, annotations cover the safety profile and the schema covers all parameters, so the essentials are present. Still, the description omits that multiple values can be selected and any permission/reference-sourcing context, leaving it minimally adequate.

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 fully documents ref, values, element, and sessionId; baseline is 3. The description adds no syntax, single-vs-multi selection detail, or reference-sourcing guidance 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 agent knows the core action. However, it does not differentiate from siblings such as browser_fill_form or browser_type, which could plausibly also set dropdown values, so an agent cannot tell it apart without opening schemas.

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 exclusions, and no naming of alternatives like browser_fill_form or browser_type. Usage is only inferred from the verb 'Select'.

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 by structured data. The description adds only the promotional claim that it is 'better than screenshot' — no information about return format, snapshot size, or the interaction with the active session that the annotations do not already imply.

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 the core action front-loaded and no padding. The trailing comparative clause is useful for routing, though it is phrased as an unsupported opinion rather than an operational distinction.

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 low-complexity, zero-required-parameter tool with a fully documented schema and annotations covering safety, the definition is close to sufficient. The main gap is that there is no output schema and the description never indicates what a snapshot returns, which is the one thing an agent cannot infer from structured fields.

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 depth, filename and sessionId each documented in the schema. The description adds nothing about these parameters (e.g. default depth, markdown output implications), so the schema carries the full burden and 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 and resource ('capture accessibility snapshot of the current page'), which is unambiguous and distinct from the visual sibling browser_take_screenshot, which it names. It does not, however, describe what the snapshot contains (roles, names, tree structure), leaving the resource only partially characterized.

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?

'this is better than screenshot' implicitly routes the agent away from browser_take_screenshot, so a preferred alternative is signaled. But there is no explicit condition for when this tool is appropriate versus when a screenshot is actually needed (e.g. visual rendering, layout), and no mention of prerequisites like an active page session.

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 agent knows this can destroy state. The description does not disclose what 'close' destroys, whether 'select' affects focus, or any side effects. It merely restates the operations listed in the enum, adding no behavioral context beyond the annotations.

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?

Extremely concise single sentence that front-loads all operations. No 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?

Given the annotations cover safety profile and the schema covers parameters, the description is minimally adequate. However, for a tool with multiple operations and destructive potential, the description could explain return values (e.g., list returns tab info) and the effect of each action, which 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 description coverage is 100%, so the schema fully documents parameters (index, action, sessionId). The description adds nothing beyond what the schema provides; 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 set of verbs (list, create, close, select) on a clear resource (browser tab). It's distinguishable from siblings like browser_navigate, though it doesn't explicitly contrast with them.

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 like browser_navigate (which could also open tabs). No mention of prerequisites or conditions.

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 establish readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds the useful limitation that the result is view-only and not actionable, but says nothing about what is actually produced (inline image vs. file written to disk) despite the filename 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, zero filler, and the core purpose is front-loaded ahead of the disambiguation note.

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 6-parameter capture tool with no output schema, the description plus annotations plus a fully documented schema cover most of what an agent needs. The only real gap is the return behavior (image content vs. saved file path), which matters given the filename parameter.

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 ref/element pairing rule and fullPage constraint is already documented. The description adds no parameter-level detail, 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 ('Take a screenshot of the current page') and explicitly distinguishes itself from the sibling browser_snapshot, which handles action-driving. An agent can route between 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?

Gives a clear negative constraint ('You can't perform actions based on the screenshot') and names the correct alternative (browser_snapshot). It lacks a positive statement of when a screenshot is the right choice (e.g., visual verification, capturing state for a human), so it stops just short of full when-to-use coverage.

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 structurally. The description adds nothing beyond that – no mention of permission requirements for element interaction, session behavior, or what happens on submit.

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 zero waste and the core action front-loaded. Nothing to trim, though it is arguably too terse rather than too long.

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 6 parameters, no output schema, and annotations covering the safety profile, the fully-documented schema carries most of the load. Still, a browser-interaction tool with this many overlapping siblings would benefit from at least one line on when it applies versus fill_form or press_key.

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 including the subtle 'slowly', 'submit', and 'element' options are already documented in the schema. The description adds no parameter meaning beyond that, 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 states a specific verb (type) and resource (text into editable element), which is clear on its own. However, it does nothing to distinguish this tool from close siblings like browser_fill_form or browser_press_key, both of which overlap with typing behavior.

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 choose browser_type over browser_fill_form, browser_press_key, or browser_select_option. The agent is left to infer selection criteria 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds almost no behavioral context beyond the annotation title 'Wait for' — no timeout ceiling, no statement of what happens on failure, no disclosure whether waiting blocks other session actions.

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 the verb front-loaded and zero filler. Nothing is repeated from the schema or annotations beyond the necessary purpose statement.

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-parameter wait primitive with no output schema, the description is serviceable but leaves the timeout/failure behavior and the parameter combination rules unstated — the two things an agent most needs to invoke it correctly.

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 four parameters are already documented; baseline 3 applies. The description's enumeration of appear/disappear/time loosely maps to text/textGone/time, but it adds no precedence or exclusivity rule that the schema lacks.

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 ('wait for') plus the three distinguishable conditions it can wait on (text appearance, disappearance, elapsed time). No sibling in the list does waiting, so the tool is unambiguous within the set, though it never explicitly positions itself against its neighbors.

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 three wait modes imply when to use the tool, but nothing states the constraints an agent actually needs: whether text/textGone/time are mutually exclusive, whether at least one is required (required list is empty), or what to do when the condition is already satisfied.

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 carry destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description still adds genuine value by naming the concrete consequence — all tabs and state are lost — which tells the agent this is irreversible session teardown rather than a reversible close.

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 front-loaded and the destructive consequence immediately after. 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 single-required-param destructive tool with no output schema and full annotation coverage, the description supplies what the structured fields cannot: the scope of loss. It stops short of routing guidance relative to browser_close and session_list, which keeps it from a 5.

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?

Only one parameter and schema description coverage is 100%, so the schema fully documents sessionId. The description adds nothing about the identifier's format or source (e.g. from session_create/session_list), making this the baseline case where structured fields do 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 and resource ('Close a browser session') plus the implementation-level effect ('dispose its browser context'), which makes the target object unambiguous. The sibling browser_close exists, however, and the description never contrasts session-level closing with page-level closing, leaving a small ambiguity an agent must resolve by inference.

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 when-to-use guidance: nothing says to use this when tearing down a whole session versus browser_close for a tab/page, nor that it should precede or follow session_switch. Usage is only weakly implied by the terminal 'state will be lost' phrasing.

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 usefully adds the isolation semantics (fresh isolated browser vs. inheriting cookies/logins from an external Chrome). It does not explain why this create operation carries destructiveHint=true or what happens to an existing session with the same sessionId.

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, front-loaded with the action and then the mode branch, with an inline example. No filler or repetition.

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 no-output-schema creation tool the description covers the essential decision (attach vs. fresh launch) and points at a real endpoint format. It leaves the cookiesFile path and the lifecycle relationship to session_close largely unaddressed, which an agent would need for full confidence.

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 three parameters are already documented, and the description's cdpEndpoint explanation largely restates the schema's own 'inherits all cookies and logged-in sessions' note. cookiesFile is not mentioned in the description at all, so it adds little beyond the structured fields.

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 ('Create a new browser session') and adds the two operating modes, so the tool is easy to place among the browser_* action tools. It does not, however, differentiate itself from the potentially overlapping sibling session_import_cookies, which also touches session bootstrapping with cookies.

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 explicit conditional guidance: pass cdpEndpoint to attach to a running Chrome with existing logins, omit it to launch a fresh isolated browser, with a concrete localhost example. It is silent on the third mode (cookiesFile) and on when to prefer session_import_cookies over passing cookies at creation time.

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 destructive/openWorld/readOnly=false, and the description adds meaningful context beyond them: platform constraint (macOS decrypt), and the required user interaction ('If a captcha appears, the user must complete it in the visible browser window'). It stops short of saying whether existing session cookies are overwritten.

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 short sentences, each earning its place: what it does, the platform mechanism, when to use it, and the operational caveat. Purpose is front-loaded before workflow and caveats.

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, no-output-schema tool, the description covers mechanism, prerequisite platform, and the captcha failure path. It omits edge cases such as keychain prompts, locked Chrome DBs, or how imported cookies interact with an existing session's cookies.

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 'domain' (substring matching) and 'sessionId' (default to active session) fully documented in the schema. The description adds no parameter-level detail beyond that 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?

States a specific verb+resource ('Import cookies from the user's real Chrome browser into a session') and adds the mechanism (decrypts Chrome's encrypted DB on macOS). This is clearly distinguishable from sibling session tools like session_create or browser_navigate.

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 explicit conditions ('Use this to access sites the user is already logged into') and the follow-up workflow ('After importing, navigate to the site'). It does not, however, name an alternative or state when NOT to use it (e.g., versus logging in manually via browser_type).

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 by structured data. The description adds that only *active* sessions are returned and that one is flagged as current, which is useful return-shape context in the absence of an output schema, but there is no pagination, ordering, or auth detail.

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; every clause (list, active sessions, current marker) 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-parameter read tool with full annotation coverage, the description supplies the essentials: scope (active sessions) and the key returned distinction (which is current). Ordering and result-format details are absent, but no output schema exists and the gap is minor for this complexity level.

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 baseline of 4 applies. Nothing in the description is needed to explain call syntax, and it correctly stays silent on inputs.

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 ('List') and resource ('active browser sessions') and adds a distinguishing detail — which session is currently active. An agent can tell it apart from session_create, session_close, and session_switch from the description alone.

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 rather than stated: listing sessions is the natural precursor to session_switch or session_close, but the description never names those siblings or gives a when-to-use condition. Adequate but leaves routing 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 declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely useful behavioral context beyond that: this tool mutates persistent state that affects all later calls lacking an explicit sessionId. It does not clarify whether the prior session is closed or whether invalid IDs error, so it stops at 4.

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. The core action is front-loaded and the consequence follows 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?

For a one-parameter tool with full schema coverage and annotations covering the safety profile, the description is close to sufficient: it explains the action and its lasting effect. It omits what happens to the previous session and error behavior on an unknown ID, which would round it out.

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% for the single parameter, so the schema already documents sessionId. The description adds functional meaning (this session becomes the default for later calls) but no format, validation, or error semantics, so 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 (Switch) and resource (active session), which is clearly distinct from the session_create, session_list, and session_close siblings. It doesn't explicitly name those siblings, so it falls just short of 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?

The second sentence implies when this matters ('subsequent tool calls without an explicit sessionId'), which conveys the usage context. However, there is no explicit when-to-use / when-not-to-use guidance, no prerequisites, and no statement of what happens to the previously active session.

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