Server Quality Checklist

Tool Scores

• browser_handle_dialogC
  2.2/5.0
  Behavior2/5

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

  Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context, such as whether accepting a dialog may submit a form or whether false dismisses the dialog. Without additional explanation, the destructive implications are vague. No contradiction with annotations exists, but the description does not enrich them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely short, but this is under-specification rather than effective conciseness. It does not front-load any useful scoping or behavior and every word simply repeats the tool name. A one-sentence description that omitted critical context does not earn its place.

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

  Completeness2/5

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

  Given the tool's destructive hint, lack of output schema, and optional promptText parameter, the description is incomplete. It does not explain what happens on accept=false, when promptText is required, or what types of dialogs are handled. The agent would need external knowledge to invoke this correctly in many situations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 both accept and promptText sufficiently. The description itself adds no parameter-level meaning, but because the schema carries the full burden, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose2/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Handle a dialog' merely restates the tool name without specifying what handling entails, such as accepting or dismissing a browser dialog. It lacks the specificity needed to distinguish behavioral outcomes from the name itself. This is tautological rather than informative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool, when not to use it, or how it relates to sibling browser tools. There is no mention of dialogs being modal or that promptText is needed for prompt dialogs. The agent must infer usage entirely from the schema.

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

• browser_console_messagesC
  2.9/5.0
  Behavior2/5

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

  Annotations already mark this read-only and non-destructive, so there is no contradiction. But the description's claim of returning 'all' console messages hides the default behavior: only messages at or above 'info' severity and only since the last navigation unless the 'all' parameter is explicitly true. This is meaningful behavioral information the description fails to convey.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one short sentence with no filler, and the key action and resource are front-loaded. It is concise, though brevity comes at the cost of behavioral precision.

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

  Completeness3/5

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

  The rich parameter schema and read-only annotations cover most invocation needs. Still, there is no output schema and the description does not clarify return format, default filtering, or session vs. navigation scope, so an agent could reasonably invoke it expecting an unfiltered dump on a bare call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so level, all, and filename are already documented in the input schema. The description adds no extra meaning or usage context for any parameter, leaving the baseline score of 3 appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource ('Returns all console messages'), and the tool name makes it clear this is the browser console counterpart to siblings like browser_network_requests. However, the word 'all' overstates actual scope because the level filter and the all=false default mean a plain call does not return every console message.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives, when not to use it, or how it relates to siblings such as browser_network_requests, browser_snapshot, or browser_evaluate. The only usage signal is the implied need for console messages.

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

• browser_dragC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the tool is known to mutate state. The description adds no further behavioral nuance (e.g., whether events fire, whether drop is required, or what happens on failure). It simply restates the action without additional context, leaving the burden largely on 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that directly states the action. It is concise with no unnecessary words. While it is under-specified relative to the tool's complexity, conciseness itself is achieved; a 4 is given for efficient structure, though not maximal because it lacks contextual richness.

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

  Completeness2/5

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

  For a potentially destructive browser interaction with four parameters, the description offers minimal guidance. It does not mention the permission-related semantics of startElement/endElement, nor explain the distinction between target references and human-readable descriptions. Given the absence of an output schema and the complexity implied by destructiveHint, the description is insufficient for an agent to fully understand when and how to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% (all four parameters have descriptions), so the schema already documents each parameter. The tool description does not add extra meaning beyond what the schema provides. Baseline of 3 is appropriate because the description does not compensate or improve upon the schema's parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action (drag and drop) and the resource (two elements). It is specific enough to understand what the tool does, but it does not explicitly differentiate from the sibling tool 'browser_drop', which could be a potential alternative for a simple drop operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like browser_drop or browser_click. It implies a drag-and-drop interaction, but without explicit context or exclusions, an agent may not know when to select this over similar tools.

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

• browser_fill_formC
  2.9/5.0
  Behavior2/5

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

  Annotations already mark the tool as destructive and non-read-only, so the description is not required to restate that. But it adds no behavioral context beyond 'fill' – nothing about side effects, whether it replaces values, whether it can trigger validation, or what happens on error. The description carries none of the additional burden normally expected for a mutating tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, containing no fluff or wasted words. However, it is perhaps too sparse to be genuinely helpful, but for a simple one-liner it is well-structured and front-loaded.

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

  Completeness2/5

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

  Despite the detailed schema, the description lacks context on when and how to use this tool. It does not mention that it handles multiple field types, that it requires a snapshot reference, or whether it is appropriate for a submission flow. An agent would need to inspect the schema and infer usage, leading to an incomplete picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 100% coverage, with every parameter documented (name, type, value, target, element). The description itself adds no information about parameters; it merely restates the purpose. Baseline of 3 is appropriate because the schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('Fill') and a resource ('multiple form fields'), which distinguishes it from single-field tools like browser_type or browser_select_option. However, it is minimal and does not describe the exact behavior beyond the basic action, so it does not fully differentiate among the many browser siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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_type for single fields or browser_select_option for dropdowns. No context is given about prerequisites, such as needing a snapshot or being on a form page.

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

• browser_navigateC
  2.9/5.0
  Behavior2/5

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

  The description adds no behavioral detail beyond what the annotations already provide. It does not mention side effects of navigation such as page unload, waiting for load, redirects, dialogs, or current-tab behavior, and it gives no context on what navigation destroys or changes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded with no filler. It is appropriately sized for such a simple action, though it is also essentially a restatement of the tool title and therefore provides limited informational value.

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

  Completeness2/5

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

  For a browser automation tool with no output schema, the description is incomplete. It does not explain whether the navigation waits for page load, returns a result, operates on the current tab, or interacts with browser history, leaving important behavioral context to the agent's inference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the url property is already described as 'The URL to navigate to'. The description simply restates this without adding format examples, accepted schemes, or edge-case guidance, so it meets the baseline for high schema coverage but adds no extra meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Navigate to a URL' clearly states a specific action and resource, and it implicitly differentiates from browser_navigate_back by focusing on a URL rather than history traversal. However, it does not explicitly name or contrast itself with siblings, so it stops short of full differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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_navigate_back, browser_tabs, or browser_wait_for. The intended use is implied by the verb, but no exclusions or alternative routing are provided.

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

• browser_press_keyC
  2.9/5.0
  Behavior2/5

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

  Annotations already flag destructiveHint=true and readOnly=false, so the agent knows this action can mutate state. The description adds no additional behavioral context such as side effects, focus requirements, or whether a page must be loaded. No contradiction, but little transparency beyond the plain action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single short sentence that is easy to parse and front-loaded with the action. Slight redundancy exists in 'on the keyboard,' but it remains appropriately concise.

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

  Completeness3/5

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

  For a one-parameter tool with a fully documented schema and safety-relevant annotations, the description is minimally adequate. It lacks useful context about keyboard focus and how this differs from browser_type, but the low complexity means the missing detail is not severe.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully documents the single key parameter with a description and examples ('ArrowLeft' or 'a') at 100% coverage. The description adds no parameter details beyond what the schema already provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Press') and resource ('a key on the keyboard'), making the core intent immediately clear. It does not explicitly distinguish itself from the sibling browser_type, which is also keyboard-related, so it is not fully differentiated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 browser_type, browser_click, or browser_fill_form, and no mention of prerequisites such as requiring focus on an element. The intended usage context is left entirely to inference.

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

• browser_typeC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to restate these. However, it adds no additional behavioral context beyond the bare action, such as whether typing replaces existing content, triggers events, or requires focus. The 'slowly' parameter's purpose is documented only in the schema, not the description. This is a mutation tool with no extra transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with zero filler. It communicates the core action efficiently. It could be considered under-specified for the tool's complexity, but conciseness is about minimalism and structure, and this is appropriately succinct.

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

  Completeness2/5

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

  Given the tool has 5 parameters, no output schema, and only annotations for safety, the description leaves out critical context for correct usage: when to use it versus sibling tools, what constitutes a valid target, and any side effects. The schema covers parameters well, but the description does not guide an agent on how to integrate this action into a browser-automation workflow. The absence of usage guidance makes it incomplete for a complex, mutation-capable tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and every parameter (text, slowly, submit, target, element) has a meaningful description. The tool description itself adds no parameter information beyond the schema, but since the schema is thorough, the baseline of 3 applies. The description does not hinder understanding of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Type text into editable element' clearly states a specific verb ('type') and resource ('editable element'), which distinguishes it from most sibling tools like browser_navigate or browser_take_screenshot. However, it does not explicitly differentiate from closely related tools like browser_fill_form or browser_press_key, which also involve text entry. Still, the core 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.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites (e.g., needing an element reference from a snapshot), or why one might choose this over browser_fill_form or browser_press_key. The distinction is left entirely to the agent's inference from parameter names.

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

• browser_closeB
  3.1/5.0
  Behavior2/5

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

  The description only repeats the core action and does not add meaningful behavioral context beyond what the annotations already signal (destructiveHint=true, readOnlyHint=false). It does not explain whether the current tab, all tabs, or the whole browser is closed, nor whether unsaved state is affected. There is no contradiction with 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely short and front-loaded with the only essential content. However, the underspecification of 'page' versus 'browser' makes it slightly less effective than a crisp one-sentence definition could be.

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

  Completeness3/5

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

  For a parameterless operation, 'Close the page' is minimally viable, especially with annotations already marking it as destructive. Still, the scope ambiguity (tab vs. browser) and absence of any note about side effects leave room for an agent to mispredict the tool's impact.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is trivially 100%. A baseline of 4 applies because there is no parameter semantics for the description to clarify.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Close the page.' It is clear enough to distinguish from navigation or resizing siblings, though 'page' is slightly ambiguous (current tab vs. entire browser) and the annotation title says 'Close browser.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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_navigate, browser_tabs, or browser_navigate_back. The description gives no context about prerequisites, expected state, or when not to call it.

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

• browser_clickB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating action. The description adds no new behavioral context—it doesn't mention that clicking may navigate pages, submit forms, or trigger side effects, nor does it disclose the permission requirement implied by the 'element' parameter. Since annotations cover the main risk, this is neutral but not additive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence with no fluff or wasted words. It front-loads the core action without any extraneous content, and every word earns its place.

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

  Completeness2/5

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

  For a tool with 5 parameters, many sibling interaction tools, and no output schema, this description is severely incomplete. It gives no guidance on prerequisites (like needing a page snapshot for the target), permission behavior, or potential side effects of clicking. The one-line description leaves too much for the agent to infer, making it inadequate for correct tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All parameters have schema descriptions, giving 100% coverage, so the schema already documents each parameter. The description adds no additional meaning about parameters—it doesn't clarify how target should be obtained or when to use modifiers. Baseline 3 applies because the schema does the heavy lifting and the description doesn't compensate beyond it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb ('click') and resource ('web page'), but it is generic and does not distinguish this tool from sibling interaction tools like browser_hover or browser_drop. It implies clicking an element but doesn't mention that it targets specific elements from a snapshot, so it lacks the specificity needed to differentiate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use browser_click versus alternatives like hover, press_key, or dragging. The description is a single sentence with no context about prerequisites, such as needing a snapshot to obtain a target reference, or when a click is the appropriate interaction.

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

• browser_evaluateB
  3.2/5.0
  Behavior3/5

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

  Annotations already carry the risk profile (destructiveHint=true, openWorldHint=true), so the agent knows arbitrary JS execution can mutate state and have external effects. The description adds the 'page or element' scope but doesn't disclose specifics like navigation side effects, error behavior, or page mutation consequences. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single front-loaded sentence with zero waste states the core action efficiently. It borders on under-specification since it almost duplicates the title, and one extra sentence distinguishing it from run_code_unsafe would have made it stronger, but as written it is appropriately terse.

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

  Completeness3/5

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

  The annotations are rich and schema coverage is complete, so the description only needs to fill remaining gaps — but it doesn't. The key omissions are the relationship with browser_run_code_unsafe and behavioral outcomes of JS execution (errors, side effects, return format beyond what the filename param notes). Adequate but with a clear gap for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 four parameters — including a clear format for function ('() => { /* code */ } or (element) => { /* code */ }') and the filename/return-behavior note. The description itself adds no parameter meaning beyond what the schema provides, so the high-coverage baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource — 'Evaluate JavaScript expression on page or element' — clearly stating that it executes JS in the page context or against an element. However, it does not differentiate from the sibling browser_run_code_unsafe, which also executes JavaScript; an agent cannot tell the two apart 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.

  Usage Guidelines2/5

  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 this tool versus alternatives. It never mentions browser_run_code_unsafe or the safe-vs-unsafe distinction, nor does it suggest when evaluating JS is preferable to the dedicated interaction tools (click, type, fill_form). The agent must infer usage entirely from the schema and hints.

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

• browser_file_uploadB
  3.2/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false, so the mutation aspect is covered. The description adds no behavioral context beyond 'upload' — it does not disclose file-chooser interaction, side effects, or that omitting paths cancels the chooser. The cancellation detail is only in the schema, not the description.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded, containing no filler or redundant explanation. Six words convey the core action and cardinality.

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

  Completeness4/5

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

  For a one-parameter tool with rich schema coverage and annotations covering the safety profile, the description is nearly sufficient. It lacks explicit context about uploading to the current page via a file chooser, but the schema partially compensates. No output schema exists, but the action is simple enough that a return-value explanation is not critical.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the paths parameter is well described: absolute paths, multiple files, and cancellation behavior when omitted. The description itself adds no parameter meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action ('Upload') and a resource ('files'), and notes single or multiple files. It is not a tautology, but it does not differentiate from sibling tools like browser_drop or explain the target of the upload, so it lacks full sibling distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool instead of alternatives. There is no mention of file-chooser contexts, when browser_drop would be more appropriate, or any exclusions.

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

• browser_resizeB
  3.2/5.0
  Behavior2/5

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

  The annotations already indicate readOnlyHint=false and destructiveHint=true, so the safety profile is covered. However, the description adds no extra behavioral context, such as whether the resize affects the viewport only, whether it is a synchronous operation, or any side effects. Given that annotations are present, the description carries a lower burden, but it still contributes nothing beyond the name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with zero wasted words. It is appropriately minimal for a simple action, and the structure is immediately readable and front-loaded.

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

  Completeness4/5

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

  Given the simplicity of the tool (two numeric parameters, no output schema), the description and schema together provide what an agent needs to invoke it. The action is clear, parameters are self-explanatory, and annotations cover the safety hints. No critical information is missing, though a note about units or scope (e.g., viewport) would make it more complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema describes both width and height with clear explanations ('Width of the browser window', 'Height of the browser window'), so schema coverage is 100%. The description itself does not add any extra semantic detail about units, constraints, or how these parameters are interpreted, justifying the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Resize') and the target resource ('the browser window'). It is specific enough to distinguish from siblings like browser_click or browser_navigate, though it does not elaborate on any nuance such as viewport vs. window frame.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  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 this tool versus alternatives. There is no mention of typical use cases (e.g., testing responsive layouts) or any conditions that would make another tool more appropriate. The lack of any contextual hint leaves the agent to infer usage.

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

• browser_hoverB
  3.3/5.0
  Behavior2/5

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

  Annotations already indicate this is not read-only and is marked destructive, but the description itself adds no behavioral context. It doesn't warn that hovering may trigger JavaScript events, alter page state, or require permission. No contradiction, but no enrichment beyond annotations either.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single short sentence with the action front-loaded. There is no filler or redundant wording; it is appropriately minimal for a simple tool.

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

  Completeness3/5

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

  For a simple hover action with a required target, the description plus schema is mostly adequate. However, the destructiveHint annotation suggests side effects that the description never explains, and there is no output-schema or return-value note. Minor gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and both parameters (target and element) are clearly documented in the schema. The description's 'element on page' loosely maps to the target parameter but adds no syntax, format, or extra meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('hover') and resource ('element on page'), which clearly conveys the core action. It doesn't explicitly differentiate from siblings like browser_click or browser_drop, but the verb is distinct enough to avoid confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied by the verb: use this when you need to hover over an element. However, the description provides no explicit guidance on when to choose hover over click, drag, or drop, and it mentions no exclusions or prerequisites.

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

• browser_tabsB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=true, which aligns with the description mentioning create and close. The description does not add extra behavioral context beyond the action names, but it is consistent with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence that conveys the full purpose of the tool with no wasted words. It lists all operations compactly and earns its place.

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

  Completeness3/5

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

  The tool is moderately complex with four action modes, and the schema covers the parameters while annotations cover the destructive profile. However, the description does not explain what 'list' returns, how 'select' affects the current tab, or when to prefer sibling navigation tools, so some context is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema already documents action, url, and index thoroughly. The description does not add any parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific resource ('browser tab') and lists all four operations it supports (list, create, close, select), so an agent knows what this tool does. It is semantically distinct from siblings like browser_navigate and browser_snapshot, though it does not explicitly call out the difference.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no guidance on when to use this tool versus alternatives such as browser_navigate or browser_close. It simply enumerates operations without context, preconditions, or exclusions.

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

• browser_navigate_backA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is covered. The description adds the 'history' context but does not disclose side effects such as clearing forward history or failing when no previous page exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short, front-loaded sentence with no filler. It conveys the core action immediately.

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

  Completeness4/5

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

  For a parameterless navigation action, the description covers the core behavior. It omits edge-case behavior (no history) and return value, but the low complexity and annotations make this acceptable, though not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the empty schema fully documents that. There is no param info needed in the description, so baseline 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  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 the history'), so an agent knows the action. It does not explicitly contrast with sibling browser_navigate or browser_tabs, but the meaning is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to prefer this over browser_navigate or how to handle missing history. The description simply defines the action, leaving usage context to inference.

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

• browser_wait_forA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds that the tool can wait for appearance, disappearance, or elapsed time, but does not disclose behaviors like polling, timeouts, or behavior when multiple parameters are supplied.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single front-loaded sentence communicates all three wait modes without wasted words. It is easy to parse and directly actionable.

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

  Completeness3/5

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

  The description is adequate for basic invocation but omits important context such as whether parameters are mutually exclusive, whether at least one is required, and what happens on timeout or missing text. Given the zero-required-parameter schema, this leaves meaningful ambiguity for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 each parameter. The description maps prose conditions to the parameters but adds no additional semantic detail beyond what the property descriptions provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (wait) plus the exact resources it operates on: text appearing, text disappearing, or a time duration. It clearly differentiates browser_wait_for from all sibling browser actions, none of which perform waiting.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives, nor does it mention context such as after navigation or before assertions. Usage is only implicit in the nature of a wait operation.

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

• browser_dropA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating operation, and the description does not contradict that. The description adds useful mechanism context (the drop is synthesized as if dragged from outside the page) and the paths/data constraint, but it doesn't disclose failure behavior — what happens if the element isn't a valid drop target, if file paths don't exist, or whether the drop can trigger navigation or form submission.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences totaling roughly 26 words with zero filler. The action is front-loaded, the critical runtime constraint follows immediately, and every word earns its place.

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

  Completeness3/5

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

  The schema documents all parameters and annotations carry the destructive safety profile, so the core invocation is adequately covered. But there is no output schema and the description says nothing about failure modes, prerequisites, or post-drop behavior for a tool flagged destructive — an agent is left guessing at error semantics and what a successful drop returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters (data, paths, target, element) are already documented in the schema. The description adds genuine value by stating 'at least one of paths or data must be provided' — a runtime constraint the schema does not encode, since only target is listed as required. This prevents an agent from constructing a schema-valid call that would fail at execution.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action — 'Drop files or MIME-typed data onto an element' — with a clear verb, resource, and input modality. The clause 'as if dragged from outside the page' helps distinguish it from browser_drag, which handles in-page dragging. However, it doesn't explicitly contrast with browser_file_upload, the other closely-related sibling that also deals with files, so sibling differentiation is mostly implicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The mechanism clause ('as if dragged from outside the page') implies the tool is for simulating external drag-and-drop, which gives some usage context. But the description names no alternatives or exclusion conditions — it never says 'use browser_file_upload for file inputs' or 'use browser_drag for in-page reordering.' With two very close siblings, explicit routing guidance would significantly help an agent select the correct tool.

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

• browser_run_code_unsafeA
  3.7/5.0
  Behavior5/5

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

  The description goes beyond the annotations by explicitly stating that it executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent. This is critical behavioral and security context that the annotations alone do not fully convey. It does not contradict the readOnlyHint=false, openWorldHint=true, or destructiveHint=true annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with zero waste. The primary action is stated first, followed immediately by the essential safety warning. Every word earns its place, and the structure is front-loaded for quick agent comprehension.

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

  Completeness4/5

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

  For a dangerous escape-hatch tool, the description covers the key facts: what it does, where the code executes, and why it is dangerous. The schema fully documents parameters, and annotations cover mutation/destructiveness. The only gap is that it does not describe the return value or how to use this tool in relation to the many sibling browser tools, but the core call-and-invoke information is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already fully documents both parameters (code and filename), including an example for code. The description adds no parameter-level detail, but the schema carries the full burden, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific action and resource: 'Run a Playwright code snippet.' It clearly identifies the tool's function and adds the critical context that it executes arbitrary JavaScript in the Playwright server process. It does not explicitly differentiate from the sibling browser_evaluate tool, though the server-process framing hints at the distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description warns that the tool is unsafe and RCE-equivalent, which implies it should be used with extreme caution, but it gives no explicit guidance on when to prefer this tool over alternatives like browser_evaluate. No when-to-use or when-not-to-use conditions are stated, and no alternative tools are named.

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

• browser_snapshotA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety contradiction exists. The description adds that this produces an accessibility snapshot of the current page, which is useful context, but it does not disclose return structure or any operational behavior beyond that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. The comparison to screenshot is brief and relevant to tool selection.

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

  Completeness3/5

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

  For a low-complexity read-only tool with fully documented parameters, the description is minimally viable. However, there is no output schema, and the description does not explain what the snapshot contains or how to use the returned references, so an agent gets only partial context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters are documented in the schema. The description adds no parameter-specific meaning, but per the baseline, this is acceptable because the schema carries the burden.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Capture accessibility snapshot of the current page.' It also distinguishes itself from the screenshot sibling by stating it is 'better than screenshot,' so an agent can tell it apart from browser_take_screenshot.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'this is better than screenshot' implies a preference/context for using the snapshot over a screenshot, but it does not explicitly state when to use this tool versus other browser inspection tools or when not to use it. The guidance is implied rather than explicit.

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

• browser_select_optionA
  3.8/5.0
  Behavior3/5

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

  Annotations already flag destructiveHint=true and readOnlyHint=false, covering the mutation safety profile. The description adds no extra behavioral context beyond the verb 'select' – it does not mention that selection may trigger events, require the dropdown to be enabled, or that multiple values are handled through an array. Since annotations carry the safety information, the description adds minimal value here.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that immediately conveys the core action. It avoids any fluff or repetition, making it efficient for an agent to parse quickly. There is no unnecessary detail.

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

  Completeness4/5

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

  For a simple dropdown-selection tool with a complete schema and no output schema, the description is largely sufficient. It correctly identifies the operation, though it could hint at how to obtain the target reference or that multiple values are accepted. These details are present in the schema, so the minor omission does not hinder correct invocation in most cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, as all three parameters (target, values, element) have descriptions. The description does not add further meaning about the parameters, such as how values map to labels or indices. With complete schema coverage, the baseline score of 3 is appropriate; the description adds nothing beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb (select) and resource (option in a dropdown), which clearly distinguishes it from sibling tools like browser_click or browser_fill_form. It unambiguously identifies the action without needing to inspect the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  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 such as browser_fill_form or browser_type. The usage is implied from the name and schema, but the description does not mention prerequisites like needing a page snapshot or context for when dropdown selection is preferred over other input methods.

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

• browser_network_requestA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already covered. The description adds useful behavioral context: it returns either full details or a single part depending on `part`, and it links the index to the sibling list output. This is meaningful beyond the schema fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two tight sentences, each earning its place. The main capability is front-loaded, the optional part behavior is stated compactly, and the selection instruction is minimal and actionable.

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

  Completeness4/5

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

  For a read-only detail-retrieval tool with three fully documented parameters and no output schema, the description covers the core behavior and selection mechanism. It does not describe the exact output shape or error behavior for invalid indexes, but the phrase 'full details (headers and body)' gives agents enough to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 three parameters. The description mostly restates the schema's meaning, such as 'part' selecting a part and 'the number from browser_network_requests' matching the schema's index description. It adds little new value beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Returns') and names the exact resource ('full details (headers and body) of a single network request'). It clearly distinguishes this tool from the sibling browser_network_requests by emphasizing 'single' and referencing the numbering source for that list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear, actionable context: use the number printed by browser_network_requests to select a single request, and optionally set `part` to narrow results. It does not explicitly state when not to use the tool, but the reference to the sibling makes the intended workflow obvious.

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

• browser_network_requestsA
  4.2/5.0
  Behavior4/5

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

  Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the result is a numbered list, it is scoped to requests since page load, and the singular sibling is the intended follow-up for details.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no wasted words. The main behavior is front-loaded, and the follow-up instruction is immediately actionable.

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

  Completeness4/5

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

  The description is complete enough for a simple list tool: it states what is returned and how to proceed to details. The optional filename output behavior is left to the schema, which fully covers it, so nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description does not need to re-explain filter, static, or filename parameters. The description adds no parameter-level detail, but the schema fully documents them, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool returns a numbered list of network requests since page load, then immediately differentiates it from the sibling browser_network_request tool. An agent can easily understand what this tool does and how it relates to its singular counterpart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance by telling the agent to use browser_network_request with the returned number to get full details. It does not enumerate alternative conditions, but for a list-and-detail pairing this is sufficient routing information.

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

• browser_take_screenshotA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds a valuable behavioral constraint beyond the annotations: actions cannot be performed based on the screenshot, which changes how an agent should use the result.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with no filler. The core purpose is front-loaded, and the important limitation about browser_snapshot appears in the second sentence. Every sentence earns its place.

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

  Completeness4/5

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

  The description is sufficient for a simple screenshot tool: it states the action, the limitation, and the alternative. The schema thoroughly covers parameters, and annotations cover safety. A minor gap is that the description does not mention what is returned, but with no output schema that is not strictly required.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail, but the schema already documents every parameter including enums, defaults, and the fullPage caveat. The description does not need to repeat what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Take a screenshot of the current page.' It also explicitly distinguishes itself from browser_snapshot by noting screenshots are not for performing actions, helping an agent tell the tools apart immediately.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives direct usage guidance: use this for screenshots, and use browser_snapshot when actions need to be performed. This explicit when-to-use and when-not-to-use guidance leaves no ambiguity about the appropriate context.

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