Server Quality Checklist

Tool Scores

• browser_handle_dialogD
  1.4/5.0
  Behavior1/5

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

  The description adds no behavioral context beyond what annotations already declare (readOnlyHint=false, destructiveHint=true). It does not explain what happens on accept vs. dismiss, how promptText is used, or any side effects or failure modes. Without this, the agent must rely entirely on guesses.

  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 only three words, which is under-specification rather than concise effectiveness. It omits necessary information and fails to earn its place as a standalone description. The structure does not help the agent understand the tool's behavior.

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

  Completeness1/5

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

  Given the tool's complexity (dialog handling with accept boolean and optional promptText) and lack of output schema, the description is severely incomplete. It does not explain how to use the tool correctly, what happens in various scenarios, or the expected outcome, leaving the agent with insufficient information.

  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 already provides 100% coverage with clear descriptions for both accept and promptText. The description text adds nothing about parameters, but the baseline for full schema coverage is 3, so this is an appropriate score.

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

  Purpose1/5

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

  The description 'Handle a dialog' is essentially a restatement of the tool name 'browser_handle_dialog' and provides no specifics about what handling entails (e.g., accept, dismiss, provide text). It fails to distinguish this tool from sibling browser actions or clarify its unique role in dialog management, making it nearly tautological.

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

  Usage Guidelines1/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, such as how to detect a dialog, whether to accept or dismiss, or how it fits with other browser tools. No alternatives or exclusions are mentioned anywhere in the description.

  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.6/5.0
  Behavior2/5

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

  The description adds no behavioral traits beyond what annotations already provide. Annotations indicate readOnlyHint=true and destructiveHint=false, but the description doesn't mention defaults, the 'all' parameter's effect, or that it can save to a file. It is essentially a restatement of the title.

  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, efficient and front-loaded. However, it is under-specified, omitting important behavioral details, so it loses a point for being too terse.

  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 3 parameters with meaningful options (level, all, filename) and no output schema, the description is incomplete. It fails to hint that messages can be filtered by severity, retrieved from session start, or saved to a file. The word 'all' conflicts with the default filtering behavior.

  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 adds no additional meaning about the parameters (level, all, filename), relying entirely on the schema.

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

  Purpose3/5

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

  The description states a clear verb+resource ('Returns all console messages'), but the word 'all' is misleading because the tool supports filtering by level and scope (since last navigation vs. entire session). It doesn't differentiate from sibling tools like browser_network_requests, though the resource itself is unique.

  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 vs. alternatives, any prerequisites (e.g., browser must be open), or exclusions. It is a single statement with no usage context.

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

• browser_clickC
  2.8/5.0
  Behavior2/5

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

  The description is a basic action statement and adds no behavioral context beyond what the annotations already convey (readOnlyHint=false, destructiveHint=true). It does not disclose potential side effects, permission requirements, or what happens after the click, so it offers minimal additional transparency.

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

  Conciseness3/5

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

  The description is a single, concise sentence with no wordiness, which earns points for brevity. However, it is so minimal that it lacks useful structural elements like specifics on target or modifiers, making it only average in structure.

  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 complexity (5 parameters, no output schema, many sibling tools), the description is severely incomplete. It omits any context about target references, permission flows, or behavioral effects, relying entirely on the schema and annotations. This is insufficient for an agent to use the tool confidently.

  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 provides full descriptions for all parameters (100% coverage), so the description does not need to explain them. The description itself adds little to parameter understanding, but the schema already carries the semantic load, resulting in a 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 ('Perform click') and the resource ('a web page'), which is specific enough to understand the tool's basic purpose. However, it does not distinguish this tool from sibling tools like browser_hover or browser_press_key, so it lacks sibling 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, nor any mention of prerequisites such as obtaining a page snapshot or needing an exact target element reference. The description simply states the action without any context for appropriate usage.

  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?

  The description adds no behavioral detail beyond what annotations already convey (destructive, not read-only). It does not mention side effects, permission requirements, or that elements must be visible, leaving the agent to infer these from 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.

  Conciseness5/5

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

  The description is a single, concise sentence that is front-loaded with the key action. There is no wasted text.

  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 drag-and-drop operation with four parameters and no output schema, the description is too minimal. It doesn't explain how targets are specified or what happens after the action, relying entirely on the schema. More context would be needed for reliable 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?

  Schema description coverage is 100% and each parameter (startTarget, endTarget, startElement, endElement) has a clear description. The tool description adds no additional parameter meaning, which is acceptable given full schema coverage.

  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 'Perform drag and drop between two elements' clearly states the action and resource (two elements). It uses a specific verb phrase, but does not distinguish itself from the sibling tool 'browser_drop'.

  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 provided on when to use this tool versus alternatives like browser_drop, browser_click, or browser_hover. The description simply states what it does without explaining context or prerequisites.

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

• browser_file_uploadC
  2.9/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what annotations already declare. Annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not explain side effects (e.g., opening a dialog, replacing files) or any authorization requirements.

  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, succinct sentence with no fluff or redundancy. It is front-loaded and easy to parse, though it could be marginally more informative without losing conciseness.

  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?

  The description is too sparse to be complete for a mutation tool with no output schema. It does not mention return values, what happens after upload, or the file chooser interaction. The schema covers parameter details, but the overall tool behavior remains under-specified.

  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 thoroughly explains the 'paths' parameter, including the conditional behavior of omitting it. The description itself adds no extra semantic information, 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 clearly states the tool uploads one or multiple files, which is a specific verb and resource. It does not explicitly distinguish from sibling tools like browser_drop, but the action of uploading is distinct enough in the context of browser file operations.

  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 such as browser_drop. It neither mentions the file picker context nor advises on prerequisites or scenarios where upload is appropriate.

  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 indicate destructiveHint=true and readOnlyHint=false, so the tool is known to be a write operation. The description adds no behavioral context beyond the basic action, such as how fields are matched, whether the page must be snapshotted, or side effects. Since no additional context is provided, the score is low.

  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 sentence with no wasted words, but it is arguably too terse. It is front-loaded, yet it lacks detail that would make it a 5. Similar to the 'update_drive' example, one efficient sentence earns a 4.

  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?

  The tool handles a complex input schema with multiple field types and nested objects, yet the description gives no information about prerequisites (like needing a snapshot), return behavior, or how it interacts with the page. This is inadequate for a tool with this complexity. The lack of an output schema compounds the issue.

  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 each parameter (target, name, type, value, element). The description adds no extra semantics beyond the schema. Per the rubric, baseline 3 is appropriate 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.

  Purpose4/5

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

  The description 'Fill multiple form fields' clearly states a specific action (fill) and a resource (form fields), but it does not explicitly distinguish this from sibling tools like browser_type or browser_select_option. The word 'multiple' hints at its scope, but a clearer differentiation would earn a 5.

  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 that it is for filling multiple fields at once or that browser_type/browser_select_option are for single-field interactions. This leaves the agent without clear usage context.

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

• browser_hoverC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate destructiveHint: true and readOnlyHint: false, signaling potential side effects, but the description adds no additional behavioral context (e.g., that hovering may trigger JavaScript events or alter page state). No extra value beyond the annotations is provided, and no contradiction 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?

  The description is a single, front-loaded sentence with no unnecessary words. 'Hover over element on page' is appropriately sized for a simple action, 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?

  Despite the tool's apparent simplicity, the annotation destructiveHint: true suggests potential negative side effects that are not explained. The description omits any mention of prerequisites (e.g., needing a page snapshot), potential effects, or relationship to other tools, leaving the context incomplete for an 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?

  The input schema fully covers both parameters (target and element) with clear descriptions, so schema coverage is 100%. The tool description adds no parameter-specific insights, 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 'Hover over element on page' clearly states the action (hover) and the target (element on page), which is specific and distinguishes it from siblings like browser_click or browser_drag. However, it does not explicitly contrast with alternatives, 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 other browser interaction tools such as browser_click or browser_drag. The description simply states the action without providing context or exclusions, leaving the agent to infer appropriate usage.

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

• browser_resizeC
  2.9/5.0
  Behavior2/5

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

  The description does not disclose any behavioral traits beyond what the annotations already state (destructiveHint=true, readOnlyHint=false). It adds no context about side effects, state changes, or implications, so the description fails to enrich the agent's understanding beyond the tool's title.

  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, making it concise and front-loaded. However, it is extremely minimal, providing only the action without any elaboration, which slightly reduces usefulness.

  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?

  Given the simplicity of the tool and the presence of annotations (destructiveHint, openWorldHint) and full parameter descriptions in the schema, the description is adequate for basic understanding. However, it omits potential details like units or the distinction between viewport and outer window, leaving minor gaps.

  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%, with both width and height having descriptions ('Width of the browser window' and 'Height of the browser window'). The tool description adds no extra parameter semantics, such as units or value ranges, 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 'Resize the browser window' uses a specific verb and resource, clearly indicating the tool's action. It distinguishes itself from sibling tools like browser_navigate or browser_snapshot, though it lacks additional scope detail (e.g., whether it affects the viewport or the entire window).

  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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer usage solely from the tool name.

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

• browser_press_keyB
  3.1/5.0
  Behavior2/5

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

  Annotations indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating action. However, the description adds no behavioral context beyond that, such as potential side effects like submitting forms or triggering navigation.

  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 short sentence, 'Press a key on the keyboard', which is front-loaded and free of unnecessary words. Every word earns its place, though it adds minimal information beyond the title.

  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 simple with one documented parameter and annotations, so the description is minimally sufficient. However, it lacks context about when to use this tool versus browser_type and does not mention potential side effects, leaving some gaps.

  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 fully describes the 'key' parameter with examples like 'ArrowLeft' and 'a', giving 100% coverage. The description adds no additional parameter meaning, which is acceptable given the schema already documents it well.

  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 tool presses a keyboard key, which is a specific verb+resource action. It distinguishes from mouse actions like browser_click and browser_hover, but does not explicitly differentiate from browser_type, which is for typing text.

  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 such as browser_type or browser_click. There is no mention of scenarios where keyboard input is appropriate or when to avoid it.

  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 declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, covering the risk profile. The description adds the scope 'on page or element' but does not disclose additional behavioral details like potential DOM modifications, network requests, or permission prompts. Since annotations cover the main safety aspects, a midpoint score is appropriate.

  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 sentence with no unnecessary words. It is concise and to the point, earning its place by stating the core functionality without fluff.

  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 having a moderately complex execution tool, the description is overly terse. It does not mention how results are returned (text vs. file), the impact of providing target/element, or any caveats about running arbitrary JavaScript. The schema and annotations cover some details, but the description leaves significant gaps for an agent deciding how to invoke this tool safely and 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?

  The input schema provides descriptions for all four parameters (target, element, filename, function), achieving 100% coverage. The tool description does not add any extra meaning beyond the schema, so it meets the baseline but does not exceed 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 clearly states the verb 'Evaluate' and the resource 'JavaScript expression on page or element', giving a specific action and scope. However, it does not differentiate this tool from the sibling 'browser_run_code_unsafe', which also executes code, so it loses one point.

  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_run_code_unsafe or other browser interaction tools. It does not mention prerequisites such as needing a page snapshot for element targeting, nor does it explain when file saving vs. text return is appropriate.

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

• browser_navigateB
  3.2/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. While annotations already indicate destructiveHint=true, the description could mention that navigation replaces the current page or may trigger redirects, but it does not.

  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 filler. It is appropriately sized for a simple one-parameter tool and gets to the point 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?

  Given the low complexity, full schema coverage, and annotations covering the destructive nature, the description is nearly complete. It lacks only usage context, which is already penalized separately, so overall completeness is good.

  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 parameter 'url' is already described as 'The URL to navigate to.' The description adds no extra meaning, so it stays at the baseline 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 'Navigate to a URL' clearly states the action and target resource. It is specific enough to distinguish from browser_navigate_back, though it does not explicitly contrast with that sibling.

  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 provided on when to use this tool versus alternatives like browser_navigate_back or browser_click. The description only states what it does, not the intended context or exclusions.

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

• browser_typeB
  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, covering the safety profile. The description adds no additional behavioral context beyond restating the action, but it does not contradict the annotations. No extra disclosure like side effects or permission requirements is provided.

  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, succinct sentence that directly conveys the core action. Every word is purposeful and there is no redundancy or filler.

  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 complexity (5 parameters, destructive annotation, and many sibling tools), the description is under-specified. It does not explain when to use it, how it differs from similar tools, or any potential side effects. The schema covers parameter syntax but not usage context, leaving the agent without enough information for correct selection.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The description does not elaborate on parameters like 'slowly' or 'submit', but the schema already documents them adequately, so no additional semantics are necessary.

  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' uses a specific verb and resource, clearly indicating the action. However, it does not distinguish from sibling tools like browser_fill_form or browser_press_key, which may also involve text input, lacking explicit scope 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?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of suitable contexts, exclusions, or references to sibling tools, leaving the agent to infer usage 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.

• browser_select_optionB
  3.4/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the basic action, such as side effects, permission requirements, or handling of multiple values. Annotations already indicate destructive and open-world behavior, but the description itself fails to disclose any additional traits about how the dropdown selection is performed.

  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 short sentence, with no redundant information. It is perfectly front-loaded and every word is purposeful, though it may be too brief to be fully helpful.

  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 tool's simplicity, the schema's thorough parameter descriptions, and annotations covering safety, the description is mostly complete. However, it omits any mention of how multiple values are handled on single-select dropdowns or how targets are acquired, which could be inferred from the schema but are not explicitly stated.

  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 already provides full descriptions for all three parameters (target, values, element), achieving 100% coverage. The description offers no additional guidance or clarification about parameter formats, relationships, or edge cases, so it adds no value beyond the schema.

  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's function with a specific verb ('Select') and resource ('option in a dropdown'), distinguishing it from sibling browser interaction tools like browser_click or browser_type. It leaves no ambiguity about the tool's purpose.

  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 over alternatives, such as browser_type or browser_click, nor does it mention prerequisites like obtaining target references from a snapshot. There are no exclusions or contextual hints, leaving the agent to infer usage from the name and schema.

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

• browser_tabsB
  3.4/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the operation list; it does not mention consequences of closing a tab or whether select changes the active tab. The annotations already indicate destructive potential, so the description carries no additional transparency value.

  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 sentence with no filler, front-loading the main actions. It is appropriately minimal for the tool's simple scope.

  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 multi-action tool, the description sufficiently names all operations, and the schema fills in parameter details. It is complete enough for basic tool selection, though additional context on side effects would improve usability.

  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 covers all three parameters with descriptions (100% coverage), so the tool description adds no parameter-level meaning. The description does not reference url, index, or action specifics beyond the operation names.

  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 lists four specific operations (List, create, close, select) on the browser tab resource, clearly distinguishing it from siblings like browser_navigate or browser_close. The verb+resource structure makes the tool's purpose immediately apparent.

  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 such as browser_navigate or browser_close. It simply enumerates actions without indicating priorities, prerequisites, or exclusions.

  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.6/5.0
  Behavior4/5

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

  Beyond the annotations (destructiveHint, readOnlyHint), the description adds crucial context: it executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent. This warns about the actual risk and execution environment, which is valuable transparency. 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.

  Conciseness5/5

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

  The description is two sentences with zero waste. It leads with the core purpose, then immediately gives the critical safety warning. Perfectly sized 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?

  With annotations covering safety and the schema covering parameters, the description adequately rounds out the tool by explaining the execution context and RCE risk. No output schema exists, so explaining return values is not required, but the lack of mention of return behavior is a minor gap.

  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 provides full descriptions for both parameters (code and filename), so schema coverage is 100%. The description does not add additional parameter semantics, 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 clearly states the tool's purpose: 'Run a Playwright code snippet.' This is a specific verb+resource combination, though it does not explicitly contrast with browser_evaluate or other siblings to highlight its uniqueness beyond the 'unsafe' warning.

  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 explicit guidance on when to use this tool versus alternatives. The 'Unsafe' label implies caution but does not mention any exclusions or better-matched sibling tools, leaving the agent to infer appropriate usage without concrete direction.

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

• browser_closeA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, so the agent knows this is a destructive operation. The description adds no further context about what is destroyed (e.g., current tab vs. entire browser session) or potential side effects, but given the simplicity, a baseline score of 3 is appropriate.

  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 short sentence, 'Close the page,' which is extremely concise and front-loaded. Every word earns its place with no redundancy.

  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 tool with no parameters and no output schema, the description is minimal but leaves ambiguity about the scope (e.g., does it close the current tab or the whole browser?). Additional context about the extent of the action would improve completeness, though it is not severely lacking.

  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?

  With zero parameters, the baseline is 4 as per the rubric. There is no parameter information needed, and the description correctly omits any parameter semantics.

  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 'Close the page' clearly states a specific verb and resource, uniquely distinguishing this tool from all sibling browser tools. It is unambiguous and immediately conveys the tool's function.

  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, nor does it mention prerequisites or typical use cases. It simply states the action without contextual direction.

  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.8/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, but the description adds no extra behavioral context. It does not disclose what happens if history is empty, whether the page load is awaited, or any side effects beyond 'go back'. Since the description simply restates the action without enriching the annotation info, the score is low.

  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 directly states the tool's purpose without wasted words. It is appropriately concise for a stateless navigation action.

  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 tool's simplicity (no params, no output schema) and the annotations covering destructive behavior, the description is mostly complete. It lacks explicit mention of edge cases like empty history, but for a trivial action this is acceptable.

  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 is empty, so the baseline is 4. The description correctly omits parameter details, and no additional meaning is needed for a parameterless tool.

  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 'Go back to the previous page in the history' clearly states a specific action (go back) and a resource (previous page in history). It distinguishes itself from siblings like browser_navigate (which goes to a specified URL) and browser_close (which closes the browser).

  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 description provides no explicit guidance on when to use this tool versus alternatives. It only defines the action, implying it should be used for history navigation, but does not state exclusions or mention alternative tools like browser_navigate.

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

• browser_snapshotA
  3.9/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 the safety profile is covered. The description adds the 'accessibility snapshot' concept and the comparison to screenshots, but does not disclose behavioral details like return structure, which is acceptable given the strong 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 immediately states the action and resource, then adds a useful comparison. No wasted words.

  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 simple with well-described parameters, but the description does not clarify what an 'accessibility snapshot' returns or how to use the snapshot tree, especially with no output schema. Some gaps remain in understanding the tool's response.

  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 already well documented. The description adds no additional parameter semantics, but the baseline of 3 is appropriate since the schema carries the full 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 ('Capture') and resource ('accessibility snapshot of the current page'), clearly distinguishing it from sibling browser_take_screenshot. The phrase 'better than screenshot' reinforces its specific purpose.

  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 provides a clear comparison to screenshots ('better than screenshot'), which implicitly directs when to use this tool over a major alternative. However, it does not mention other alternative tools like browser_find or browser_evaluate, so the guidance is limited but not misleading.

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

• browser_dropA
  4/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. The description adds the 'as if dragged from outside the page' mechanism and the required condition for paths/data, but does not disclose side effects, permission requirements, or what triggers, beyond what annotations imply.

  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 concise sentences, action front-loaded, no filler. The first sentence states the tool's purpose, and the second sentence provides a crucial constraint, making every word useful.

  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 moderate-complexity mutation tool with no output schema, the description covers the core action, input constraint, and drop origin. It does not elaborate on element compatibility or return values, but the schema already details parameter formats.

  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%, but the description adds the essential 'At least one of paths or data must be provided' constraint, which is not in the schema. It also clarifies that 'data' is a MIME-typed map, reinforcing the schema's examples.

  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 'Drop' and clearly identifies the resource: 'files or MIME-typed data onto an element'. It distinguishes from sibling tools like browser_drag by explicitly noting 'as if dragged from outside the page', which frames the unique behavior.

  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 description gives context (simulating an external drag) but does not explicitly state when to choose this over alternatives like browser_file_upload or browser_drag. The 'At least one of paths or data must be provided' is a parameter rule, not an usage guideline comparing to siblings.

  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
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that it can return either full details or a single part via the 'part' parameter, which is useful context beyond the annotations. However, it does not describe error behaviors or what happens when the index is invalid, leaving some gaps.

  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, front-loaded with the main purpose, and every word earns its place. It efficiently communicates the tool's function and the key usage hint.

  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 read-only retrieval tool with strong annotations and full schema coverage, the description is largely complete. It explains the core behavior and the source of the index. It omits details like return format or error cases, but the annotations and schema compensate, so the overall context is sufficient.

  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 parameters are well documented. The description adds extra meaning by explaining that the 'index' comes from browser_network_requests and that 'part' can restrict the output to a single part. This goes beyond the schema's basic field descriptions.

  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 full details of a single network request, with a specific verb ('Returns') and resource ('details of a single network request'). It also distinguishes itself from the sibling tool browser_network_requests by emphasizing 'single' and referencing its index.

  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 instruction to 'Use the number from browser_network_requests' provides clear context for when to use this tool, linking it to the list tool. It does not explicitly mention alternatives or exclusions, but the usage context is clear enough for an agent to select it appropriately.

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

• browser_wait_forA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds the three waiting modes (appear, disappear, time), which are the core behavioral traits. It does not mention timeout behavior or error handling, but with annotations this is a minor gap.

  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 all essential information without any filler. It is appropriately concise and well-structured.

  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 tool is simple, has no output schema, and annotations cover safety. The description covers the main usage modes. However, it does not specify default timeout behavior or what happens if the wait condition is not met, which could be useful but is not critical given the tool's simplicity and the presence of a 'time' parameter.

  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 input schema has 100% coverage with descriptions for all three parameters. The description reinforces the schema by clearly mapping 'text' to appearance, 'textGone' to disappearance, and 'time' to a duration, adding semantic context beyond the raw schema properties.

  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 action ('Wait') and the target resources (text to appear, disappear, or a time to pass). It clearly distinguishes this tool from siblings like browser_find or browser_evaluate by focusing solely on waiting behavior.

  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 description implies usage when you need to wait for a condition, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or common scenarios. No exclusions are provided, so it is adequate but not explicit.

  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.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by noting the temporal scope ('since loading the page') and the output format ('numbered list'), which are behavioral traits not present in annotations. No contradiction.

  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, front-loaded with the primary action and scope, followed by a precise cross-reference to the sibling tool. No redundant or filler content; 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 tool is simple, and the schema covers parameters thoroughly. The description tells the agent what output to expect (numbered list) and how to get full details. It doesn't explain return structure in depth, but with no output schema and good annotations, this is mostly 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?

  Schema description coverage is 100%, so all three parameters (filter, static, filename) are fully documented in the schema. The description does not add additional meaning beyond what the schema 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.

  Purpose5/5

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

  The description clearly states the tool's function: 'Returns a numbered list of network requests since loading the page.' It uses a specific verb ('Returns') and resource ('network requests'), and the scope 'since loading the page' distinguishes it from the sibling browser_network_request, which provides full details for a single request.

  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 explicitly guides usage to an alternative: 'Use browser_network_request with the number to get full details.' This tells the agent when to use this tool (to get a list) and when to switch to the sibling (for details). It clearly maps the workflow.

  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=true and destructiveHint=false, so the safety profile is covered. The description adds a key behavioral trait beyond this: screenshots are not actionable and should be used only for visual inspection. This is valuable context that annotations don't convey, although it doesn't detail other behavioral aspects like return values or file saving behavior.

  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 exactly two sentences, with the purpose front-loaded and the crucial usage caveat following immediately. Every sentence earns its place with no wasted words.

  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 tool with 6 parameters and no output schema, the description provides enough context for selection: it states the purpose, gives an alternative, and the schema handles parameter semantics. However, it doesn't mention what the tool returns (e.g., an image file path), but the tool name and filename parameter imply this. It is reasonably complete but could be slightly more explicit about the output.

  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 6 parameters are already well-documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, thus it meets the baseline of 3 without adding extra value.

  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 precisely what the tool does: 'Take a screenshot of the current page.' This is a specific verb + resource, and it clearly distinguishes from sibling tools like browser_snapshot by noting the screenshot cannot be used for actions, making its purpose unambiguous.

  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 explicit usage guidance: 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This directly tells the agent when NOT to use this tool and names the alternative (browser_snapshot), fulfilling the when-to-use vs alternatives criterion.

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

• browser_findA
  4.5/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds valuable behavioral details: it returns matching nodes with surrounding context, shows paths from the tree root, and notes the cost savings versus full snapshot. This goes beyond annotations and gives the agent a clear model of execution and output.

  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, information-dense sentence. It front-loads the core action, then efficiently packs in the return format, context snippets, path display, and cost comparison. Every clause earns its place with no fluff or repetition.

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

  Completeness5/5

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

  The tool is simple (two optional parameters, no output schema, read-only). The description explains what it returns, how results are presented, and why you'd use it over a full snapshot. No major gaps remain for an agent to invoke or interpret the tool 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%: both 'text' and 'regex' have detailed descriptions including case sensitivity, substring matching, flags, and mutual exclusivity. The description only reiterates the 'either/or' constraint, adding no new parameter-level insight. Baseline for high coverage is 3, and nothing here lifts it higher.

  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 opens with a specific verb and resource: 'Search the accessibility snapshot of the current page for text or a regular expression.' This clearly states what the tool does and immediately distinguishes it from sibling tools like browser_snapshot (which captures the whole snapshot) by focusing on search within the snapshot.

  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 explains when to prefer this tool: 'cheaper than capturing the whole snapshot when you only need to locate an element and its ref.' This implies the alternative is browser_snapshot. It also provides a crucial usage constraint: 'Provide either text or regex, not both.' However, it does not explicitly state when not to use it or name other alternatives, so it's not a full 5.

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