Blinkwire

by 81117105108108

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, and overlapping actions are differentiated by target (element vs coordinates) or scope (single vs all). A few pairs like browser_close and browser_tabs could be confused, but descriptions are clear enough.
Naming Consistency3/5
All tools share the browser_ prefix and snake_case, but the verb/noun ordering is inconsistent: browser_navigate and browser_click are verb-first, while browser_cookie_list and browser_localstorage_get are noun-first. This makes the naming pattern somewhat predictable but not fully uniform.
Tool Count1/5
With 56 tools, the surface is far beyond the typical well-scoped range and crosses the 50+ extreme threshold. Many low-level operations could be consolidated or hidden behind higher-level actions.
Completeness5/5
The toolset covers the main browser automation needs: navigation, interaction, forms, snapshots, storage, network, tabs, cookies, console, and batch operations. It is hard to identify a major missing capability for general browser automation.
Average 4/5 across 56 of 56 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'destructiveHint: false' directly contradicts the description's explicit deletion action. Deleting a cookie is a destructive operation, and the annotation misleads the agent about the tool's impact. This is a serious inconsistency that undermines trust.
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 at one sentence, which is appropriate for a simple action. It is front-loaded with the key verb and object. However, the brevity comes at the cost of missing crucial context, though the structure itself is clean.
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 lacks essential operational details such as the cookie scope (current domain, path), whether it affects all matching cookies or just one, and any side effects on the page or session. Given that the tool deletes data, this missing context makes it difficult to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'name' is described as 'Cookie name' in the schema, and the description simply repeats that without adding details about required domain/path, optional attributes, or how the cookie is uniquely identified. This leaves the agent guessing about the exact cookie to target.
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 'Delete' and the resource 'one cookie by name', which distinguishes it from the sibling tool 'browser_cookie_clear' that deletes all cookies. However, it does not specify the domain or path scope, leaving slight ambiguity about which cookie is targeted.
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_cookie_set' or 'browser_cookie_clear'. It does not mention that this deletes a single cookie while other tools handle bulk operations or retrieval, so the agent has to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Remove' but the annotation destructiveHint is false, which contradicts the clearly destructive nature of deleting a localStorage key. Additionally, no side effects, return values, or irreversible consequences are mentioned, leaving important behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It follows a clear subject-verb-object structure and is easy to parse.
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 omits important context such as what happens if the key does not exist, whether the operation returns a success indicator, and that the action permanently removes data. For a destructive operation, this missing information leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter description ('localStorage key') is essentially a restatement of the parameter name and adds no meaningful details about key format, required uniqueness, or valid values. The schema coverage is high but the semantic value is low.
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 ('Remove') and the target ('one localStorage key'), making the primary purpose unambiguous. However, it does not explicitly distinguish itself from related storage tools like clear or set, relying on the tool name for that context.
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 such as browser_localstorage_clear or browser_localstorage_set. The description does not mention typical use cases, prerequisites, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral details beyond the bare action, such as whether the drag includes mouse-down/move/up, how coordinates are interpreted (viewport vs page), or any side effects. The annotations only provide readOnlyHint=false and destructiveHint=false, which offer minimal insight.
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 unnecessary words or repetition. It directly states the action and subject, making it highly efficient.
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 absence of an output schema and the simplicity of the tool, the description is adequate but lacks explicit context about the coordinate system (e.g., viewport-relative vs page-relative) and whether a drop event is included. It does not fully prepare an agent for edge cases or expected 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?
The schema descriptions cover all four parameters (Start X, Start Y, End X, End Y), so schema coverage is 100%. The tool description adds no additional meaning beyond rephrasing 'from one viewport coordinate to another,' which aligns with the parameter names but does not enrich understanding of coordinate semantics or units.
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 the resource ('viewport coordinate to another'), making the tool's purpose understandable. However, it does not explicitly distinguish itself from sibling tools like 'browser_drag' or 'browser_mouse_move_xy', so the differentiation is implicit rather than explicit.
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?
The description provides no guidance on when to use this tool versus alternatives, such as 'browser_drag' for element-based dragging or 'browser_mouse_move_xy' for moving without dragging. No conditions or use cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=true), the description adds no information about side effects, error behavior (e.g., missing key), or return format. It is minimally transparent.
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 very concise and front-loaded, with no unnecessary words. However, it is so short that it lacks useful detail, preventing a perfect score.
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 incomplete for an agent: it does not mention what happens if the key does not exist, whether the value is returned as a string, or any browser context specifics. Given the simple nature, more context would be expected.
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, and the parameter description ('sessionStorage key') is mostly redundant with the parameter name. The description does not add meaningful semantic detail 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 action ('Read') and resource ('one sessionStorage key'), which is specific and distinguishes it from sibling tools like set, delete, or list operations.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., sessionstorage_list or localstorage_get). It only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations already indicate readOnlyHint=false (a write operation) and destructiveHint=false (not destructive). The description merely restates the title without disclosing side effects like overwriting existing values or failure modes, so it adds no value.
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 sentence and is concise, but it is essentially a restatement of the title, adding little value. It is appropriately short but does not 'earn its place' because it lacks substantive 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?
For a simple set operation with two well-documented parameters and no output schema, the description is minimally adequate. However, it omits any mention of overwriting behavior, error conditions, or when to use sessionStorage over localStorage, leaving the agent without important 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 both key and value are adequately described in the schema. The description adds no parameter-specific detail, but the schema carries the load, meeting 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 clearly states the action ('Write') and the resource ('one sessionStorage key'), which is distinct from localStorage or other storage types. However, it is very terse and could be more specific about overwriting behavior, though it's adequate for basic clarity.
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_localstorage_set or browser_sessionstorage_delete. No context, no exclusions, no mention of prerequisites or conditions—leaving the agent to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Read' adds no new behavioral information. It does not disclose what happens when the key is missing, whether the value is returned as a string or JSON, or any error behavior. Given the annotations, the bar is lower, but the description contributes nothing beyond a restatement of the read-only nature.
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, 'Read one localStorage key.' It is front-loaded with the action and resource, with no wasted words. This 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 trivial single-parameter read operation, the description is minimally adequate. However, there is no output schema, and the description does not mention the return format (e.g., string value, null if missing) or any error conditions. While annotations cover the safety profile, an agent may need to know the return behavior to handle results correctly. This is a minor gap for a simple tool but prevents a higher score.
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%, so the 'key' parameter is fully documented in the schema. The description's phrase 'localStorage key' simply repeats the schema description without adding format, syntax, or expected value details. Per the baseline for high coverage, a 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 states a specific verb ('Read') and a resource ('localStorage key'), clearly indicating the action. It does not explicitly differentiate from sibling tools like browser_localstorage_list or browser_sessionstorage_get, but the tool name and description are unambiguous enough for an agent to understand the 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?
There is no guidance on when to use this tool versus alternatives. The description does not mention conditions for use, exclusions, or mention any sibling tools (e.g., browser_localstorage_list for listing all keys). An agent is left to infer the appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Read' is consistent. The description adds no extra behavioral context, such as behavior for non-existent cookies or return format. Since the annotations cover the safety profile, a 3 is appropriate—it's not contradictory but adds minimal value beyond 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?
A single, front-loaded sentence with no filler. It states the action and the key parameter succinctly, making it easy for an agent to parse quickly.
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 one-parameter read operation with no output schema, the description is adequate. It doesn't specify return value or error behavior, but given the simplicity, this may be acceptable. Mentioning the return value could improve completeness, but it's not a critical 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?
Schema description coverage is 100% (the 'name' parameter has 'Cookie name' description). The tool description repeats 'by name', adding no new semantic detail. Baseline 3 is correct when schema already documents the parameter; no additional constraints or format are provided.
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 'read' on a resource 'cookie' and specifies 'one cookie by name', which clearly distinguishes it from siblings like browser_cookie_list (list all) and browser_cookie_set. However, it doesn't explicitly mention alternatives, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need a specific cookie's value by name. It doesn't explicitly state when not to use it or mention alternative tools, leaving the agent to infer from context. Given the large sibling set, explicit routing would be helpful but is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=true, destructiveHint=false) — saving a PDF does not mutate page state. It adds the 'current page' scoping constraint beyond the annotations, but does not disclose output-file behavior (where the file lands, overwrite semantics, or any confirmation). Annotations carry the safety profile; the description adds modest scope context.
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 efficient sentence with zero waste, directly stating the operation and its scope. Nothing extraneous.
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 low-complexity save tool with zero required parameters, 100% schema coverage, and no nested objects or output schema, the description plus schema is nearly sufficient. The only gap is the absence of any statement about the return value or file-handling outcome, which is minor for a simple print-to-PDF operation.
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 five optional parameters (scale, format, filename, landscape, printBackground) are already documented in the schema. The description adds no parameter-level meaning, so the baseline 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 specific verb ('print') and resource ('current page'), clarifying that the operation exports the currently-loaded page to a PDF. This differentiates it from image-based siblings like browser_take_screenshot, though it does not explicitly name that sibling. It's clear but leaves sibling differentiation 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?
Usage context is implied — an agent would select this when it needs a PDF export of the current page — but the description gives no explicit when-to-use/when-not guidance and does not reference alternatives such as browser_take_screenshot for image output. Adequate but relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description adds context by stating it stubs responses and that mocking can be restarted by re-adding. It does not contradict annotations, but it does not disclose details like scope, persistence, or interactions with existing routes. The added 're-adding' note is useful but limited.
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 filler. The primary action is front-loaded, and the second sentence provides a useful behavioral note. 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?
While the core function is clear, the description lacks context about how this tool relates to other routing tools (e.g., browser_unroute, browser_route_list) and the lifecycle of the mock (e.g., does it persist across navigations? What happens on duplicate patterns?). An agent would need to infer these details from sibling names, which is not ideal. The description is incomplete for safe and correct usage.
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 parameters (body, status, headers, pattern, contentType) are already documented in the schema. The description adds no additional parameter-specific information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Stub responses for URLs matching a pattern.' It uses a specific verb (stub) and resource (responses for URLs), distinguishing it from related tools like browser_route_list and browser_unroute. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need to mock network requests) but does not explicitly compare it to alternatives or state when not to use it. It mentions 'Restart mocking by re-adding the route,' which hints at a lifecycle but lacks explicit guidance on selecting this tool over siblings like browser_unroute or browser_route_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While the description clearly states the destructive effect (deleting all cookies), it directly contradicts the annotation 'destructiveHint: false'. This inconsistency reduces transparency about the tool's side effects and could mislead an agent about the action's severity.
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 conveys the entire purpose without extraneous words or redundancy.
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 action, the description covers the essential effect. However, it does not mention potential side effects (e.g., clearing cookies across all browser contexts) or confirm the action's irreversibility, though this is minor given the simple nature of the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool schema has no parameters, so there is nothing to clarify. The description appropriately omits parameter details, and no additional explanation is needed.
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 'Delete every cookie in the browser' is specific and unambiguous, clearly distinguishing this tool from sibling cookie functions (e.g., browser_cookie_delete which removes a single cookie).
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 does not provide any guidance on when to use this tool versus alternatives like browser_cookie_delete or browser_cookie_set. It only states what the tool does, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions 'one settle for the whole form', implying it waits for the page to settle after filling. It does not describe side effects such as validation, auto-submit, or error behavior, and the annotations provide little additional clarity.
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, using only two short sentences with no filler or redundant information.
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 enough to distinguish this from single-field tools like browser_type and select_option, and it conveys the main batching benefit. It lacks details about selector syntax and supported input types, but remains usable for typical form-filling scenarios.
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 settle parameter is clearly described. The fields parameter describes the expected shape as {target, value} or {target, values} for multi-selects, but does not clarify what target refers to or the value types, leaving some ambiguity.
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?
Clearly states the action (fill form fields) and the scope (many fields in one call), with an explicit benefit. The term 'target' in the fields parameter is not defined, but the overall 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Positions the tool as the fastest way to complete a form and mentions one round-trip and one settle, giving agents a strong signal to use it for multi-field forms. It does not explicitly contrast with browser_type or select_option, but the sibling tool list makes the alternatives apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral detail about merging CLI flags and environment variables, but the read-only nature is already covered by the readOnlyHint annotation. It does not disclose additional side effects or nuances 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, concise sentence with no redundancy or irrelevant details, making it highly efficient and well-structured.
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?
For a simple getter with no parameters or output schema, the description is fully sufficient. It states what is returned and the data source, leaving no critical gaps for an agent to use 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?
The tool has no parameters, so schema coverage is trivially complete. The description adds no parameter-specific information, aligning with the baseline for high coverage.
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 action ('Return the resolved configuration') and its source ('after merging CLI flags and environment variables'), leaving no ambiguity about what the tool does.
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 explicit guidance on when to use this tool versus alternatives among the many sibling tools. It simply describes the function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint and destructiveHint annotations. It does not add extra behavioral details such as whether the list is sorted, paginated, or includes only user-defined routes, but the annotation covers the core safety aspect.
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 unnecessary words. It is front-loaded with the action and object, making it easy to parse quickly.
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 zero-parameter list operation, the description is sufficient. It does not need to explain return values or side effects since it is a simple read-only query. The absence of an output schema is not problematic here.
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 no parameters, so there is nothing to describe. The baseline score of 4 applies as there is no ambiguity or missing parameter information.
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 'Show the active mocked routes' clearly states the action (show) and the object (active mocked routes). It is specific enough to distinguish from generic listing, though it does not explicitly differentiate from sibling tools like browser_route_list's purpose is obvious.
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 no explicit guidance on when to use this tool versus alternatives. However, for a simple read-only list operation, the context of sibling tools (browser_route, browser_unroute) implies usage, but it is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description says 'Remove every sessionStorage key', a destructive action, but destructiveHint is false, creating a direct 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?
Single clear sentence with no extraneous information; front-loaded verb and object.
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?
For a parameterless clear operation, the scope ('current origin') and action are fully specified; no output schema means return details are not necessary.
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?
No parameters exist, and schema coverage is complete; baseline 4 applies. Description adds no parameter details because none are needed.
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?
Clearly states the exact action: remove every sessionStorage key for the current origin. No ambiguity about scope or target.
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?
Does not explicitly say when to prefer this over related storage tools such as browser_sessionstorage_delete, though the name and description make primary use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already indicate a non-read-only, non-destructive write. The description adds useful scope context ('on the current page') and clarifies that it may overwrite an existing cookie, which is transparent about the 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 a single, concise sentence that fully captures the tool's purpose without extraneous detail. It is appropriately sized for a simple operation.
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?
There is no output schema, so no return value explanation is needed. The description adequately conveys the operation and scope, but does not mention potential error conditions or prerequisites, which are likely implied by the browser 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 coverage is 100% with each parameter having a basic description (e.g., 'Cookie name', 'Cookie value'). The tool description does not add further meaning beyond the schema, so a baseline score 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 action (create or overwrite) and the resource (cookie on the current page). It distinguishes from sibling cookie operations like get, list, and delete by explicitly mentioning creation/overwrite.
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 does not mention when to use this tool versus alternatives such as browser_cookie_get or browser_cookie_delete. No explicit usage conditions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutating) and destructiveHint=false (not destructive), which aligns with a drag-and-drop action. However, the description does not mention side effects like triggering events or moving elements, though this is not critical for such a common operation.
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 contains all necessary information without fluff. It is well-structured and easy to parse.
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 of the tool, the description is complete enough for an agent to invoke it correctly. No output schema is present, but a drag-and-drop action typically returns a status or nothing, and the description does not need to detail that. Minor gap: no mention of success/failure behavior, but not essential.
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% (both startTarget and endTarget are described). The parameter descriptions 'Source element ref or CSS selector' and 'Target element ref or CSS selector' are clear and self-explanatory. The tool description adds no additional meaning 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 action: 'Drag and drop from one element to another.' It is specific and distinguishes itself from element-based actions like click and hover, and from coordinate-based drag (mouse_drag_xy) and drop actions.
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 does not explicitly mention when to use this tool over alternatives such as mouse_drag_xy or drop. It is implied that this is for element-based drag-and-drop, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Remove every localStorage key', which is destructive and irreversible to localStorage, yet the annotation destructiveHint is false. This is a direct 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?
The description is a single concise sentence that directly communicates the tool's behavior without unnecessary detail.
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?
For a zero-parameter tool, the description provides enough context to know exactly what will happen when invoked. No further details are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there are no parameter details to describe. Nothing additional is needed.
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 exact action—remove every localStorage key for the current origin—and is distinct from sibling tools like localStorage_delete or sessionstorage_clear.
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 'every localStorage key' implies this is for clearing all localStorage data, but it does not explicitly mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool writes, aligning with readOnlyHint=false, but it does not mention potential overwriting of existing keys or persistence behavior; annotations provide minimal additional side-effect detail.
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 redundant information, front-loading the action and resource.
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 two-parameter setter with no output schema, the description is adequate, though it omits minor context such as overwrite semantics or return value.
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 fully describes both parameters (key and value), and the description adds no extra meaning beyond what is in the parameter 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 action ('Write') and the resource ('one localStorage key'), which distinguishes it from sibling tools like browser_localstorage_get, browser_localstorage_delete, and browser_localstorage_clear.
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 for storing a value in localStorage, but it does not explicitly state when to choose it over related get/delete/clear tools or mention any context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating the action is a state-changing but non-destructive operation. The description does not add further behavioral context (e.g., behavior when no forward page exists). Since annotations cover the basic safety profile, a 3 is appropriate for this simple action.
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 no wasted words. It is front-loaded with the core action and resource, making it immediately clear.
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, side-effect-free navigation tool with no output schema, the description is sufficient to understand the operation. It doesn't mention edge cases (e.g., no forward history), but given the simplicity and annotations, 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 coverage is 100% (empty schema). With no parameters to document, the description naturally adds nothing here. Baseline for 0 params is 4, and the description does not need to compensate.
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 forward to the next page in the history' clearly states a specific verb and resource, distinguishing it from sibling tools like browser_navigate_back (backward navigation) and browser_navigate (general navigation). It is unambiguous and actionable.
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 (e.g., having navigated back first) or exclusion criteria. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not disclose side effects such as re-running scripts, losing unsaved form state, or triggering network requests. Minimal behavioral transparency beyond the obvious action.
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 one short, clear sentence. It is front-loaded and contains no unnecessary 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?
The description is sufficient for a simple reload operation, though it does not specify what the tool returns on success or failure. Given the absence of an output schema, this is acceptable but not fully 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 single parameter `ignoreCache` is described in the schema as 'Bypass the cache when reloading'. The tool description adds no additional meaning beyond that schema description, so the baseline score applies.
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 operation: reload the current page. This distinguishes it from navigation, screenshot, and other browser tools.
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 use on the current page but does not explicitly state when to prefer this over navigation or other refresh-related actions. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explaining the internal mechanism (CDP vs emulation), which informs how the resize will be applied. It does not fully describe side effects like whether the resize triggers layout changes, but the added context is valuable.
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 succinct, front-loads the main purpose, and contains no extraneous information. The two sentences are focused and clear.
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 tool with two parameters and no output schema, the description covers the essential behavior. The mention of CDP/emulation is a useful edge case, but it does not discuss minimum size constraints (already in schema) or whether the change is persistent. Overall, it is sufficiently complete for an agent to use 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 schema already provides descriptions for both parameters (width/height in pixels). The tool description adds no additional semantic detail beyond what is already present, so it meets the baseline.
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 action (resize) and the resource (browser window), and even clarifies the two modes of operation (real window bounds vs emulated viewport). This distinguishes it from other browser tools.
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. It does not mention conditions, prerequisites, or contrast with other tools, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is a single round-trip and reports whether the end was reached, adding useful behavioral detail beyond the minimal annotations. It does not contradict readOnlyHint or destructiveHint, though it could mention side effects more explicitly.
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 very concise and front-loaded with the core purpose. Every sentence adds meaningful information about behavior or output.
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 covers the main action, target scope, round-trip nature, and outcome reporting. It does not specify the exact return shape, but for a simple scroll tool the statement that it reports whether the end was hit is probably sufficient.
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 five parameters already have clear descriptions in the schema, including defaults and the override behavior of x/y over direction. The description adds little beyond the schema, so it meets the baseline but does not elevate the semantic guidance.
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 scrolls the page or an element, and the title reinforces this. It distinguishes itself from browser_mouse_wheel by noting it is a single round-trip with no synthetic wheel events.
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 does not explicitly indicate when to choose this tool over alternatives such as browser_mouse_wheel or browser_mouse_drag_xy. It mentions no synthetic wheel events, but does not explain why an agent should prefer this tool in a given situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the action is a removal, which is clear. Annotations show destructiveHint=false, which is consistent with sessionStorage being temporary, so no contradiction. It does not mention edge cases (e.g., key not found), but the simple nature of the operation makes this acceptable.
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 extraneous information. It is perfectly sized for the tool's simplicity and is front-loaded with the action verb.
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 a single parameter, no output schema, and a straightforward purpose, the description is sufficient. It could mention behavior on missing keys, but that is a minor omission and not necessary for basic usage.
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 only parameter 'key' has a description that merely restates its name ('sessionStorage key'). This provides no additional context beyond the schema, such as expected format or that it must be an existing key. Schema coverage is 100%, so baseline of 3 applies, but no extra meaning is added.
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 removes one sessionStorage key, distinguishing it from sibling tools like sessionstorage_clear (removes all) and sessionstorage_get (retrieves). The verb 'Remove' is specific and the resource is clearly identified.
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 for removing a single key but does not explicitly contrast it with alternatives like sessionstorage_clear or sessionstorage_set. For a simple operation, this is minimally acceptable but lacks explicit guidance on when to prefer this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already convey that this is a non-destructive read operation. The description adds no further behavioral details such as return format or whether cookies from all frames or only the main frame are listed.
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 fully communicates the tool's purpose and optional filtering capabilities without extraneous information.
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?
For a simple read-only listing operation, the description and schema are sufficient. The tool's behavior is clear given the annotations, and no additional context is necessary for correct 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?
The schema provides complete descriptions for both parameters: 'path' filters by path prefix and 'domain' filters by domain substring. The description restates that filtering is optional but adds no additional semantic detail 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 lists cookies for the current page with optional filtering, using the specific verb 'list' and resource 'cookies'. It is easily distinguishable from related cookie tools like browser_cookie_get or browser_cookie_set.
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 indicates optional filters by domain or path but does not explicitly explain when to choose this tool over sibling cookie or storage tools. Some usage context is implied but not fully stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint and destructiveHint, and the description does not contradict them. However, the description does not disclose that executing arbitrary JavaScript could have side effects beyond the provided hints, so it adds little transparency on top of 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 concise, using two sentences to convey the core functionality and parameter behavior without unnecessary details or repetition. It is well-structured and easy to parse.
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 the simple purpose but omits an explanation of the 'filename' parameter and does not state what the tool returns. While no output schema exists, mentioning the return behavior or the purpose of saving to a file would improve completeness.
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 all parameters with descriptions, and the tool description clarifies the 'function' and 'target' parameters but omits any explanation of 'filename'. Since schema coverage is complete, the description adds only marginal value beyond the existing parameter 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's purpose as running JavaScript in the page, which is a distinct action from navigation, clicking, or other browser operations. It provides a specific verb and resource, making it easily distinguishable from sibling tools.
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 includes a concrete example of how to pass the function as a string and explains the behavior of the optional target parameter. While it does not explicitly state when to prefer this tool over alternatives, the example and parameter explanation provide practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key internal behavior (MutationObserver) and notes that it returns instantly when the text shows up. However, it does not explain behavior when multiple parameters are combined, what happens on timeout, or what happens if no parameters are provided—leaving some behavioral uncertainties.
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 short sentences with no redundant wording. It front-loads the core purpose and adds one valuable implementation detail without unnecessary elaboration.
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 appropriate for a simple tool but lacks guidance on edge cases like empty parameters, conflicting parameters, timeout errors, and return value. This leaves some practical gaps for an agent deciding how 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 descriptions cover all four parameters clearly, so the description adds limited extra meaning. It does not clarify relationships between text, textGone, and time, or how timeout applies when both text and textGone are set, but the individual parameter explanations are adequate.
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 a specific action: wait for text to appear or disappear, or wait for a fixed time. This distinguishes it from sibling tools like browser_find or browser_snapshot by focusing on the waiting behavior rather than querying or inspecting the page.
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 implies when to use the tool—when a script needs to pause until a text appears, disappears, or for a fixed duration. However, it does not explicitly contrast it with alternatives like browser_find or browser_snapshot, so there is slight room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It states the basic mutating effect ('Set files') and the default-target behavior, but does not detail side effects like change events or form submission; annotations indicate readOnly false, so 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 concise sentences provide the essential information without unnecessary wording.
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 file-upload action with no output schema, the description covers required inputs and default behavior sufficiently, though it omits edge-case details like file existence or input visibility.
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 describes both parameters fully; the description adds little beyond restating the target parameter's optionality.
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 identifies the action as setting files on a file input, which is distinct from navigation, clicking, and other browser operations.
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?
It explains how to specify a target or rely on the first file input, but does not explicitly address when this tool should be preferred over related actions such as typing or drag-and-drop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds a behavioral note about reliability ('cheaper and more reliable than a screenshot') and explains that refs are passed to other tools, which is useful context. It does not describe the exact output structure or potential limitations, but given annotation coverage, this is adequate.
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?
Three sentences with zero fluff. The purpose is front-loaded, the primary use case is stated, and the key concept (refs) is introduced succinctly. 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 has five optional parameters, all well-documented in the schema. The description explains the core purpose, the output format (ref-tagged), and its integration with other tools. Nothing critical is missing for an agent to call it correctly. It could mention that the snapshot is a tree structure, but that is not essential.
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 descriptive text, so the description adds no additional parameter-specific meaning. The description's mention of refs refers to the output, not parameters. With high schema coverage, 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 captures a 'compact, ref-tagged snapshot' and explicitly contrasts it with screenshots ('cheaper and more reliable than a screenshot'). It distinguishes the primary use case (reading a page) and explains the role of refs, making it immediately clear what this tool does and how it differs from sibling tools like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description positions this as 'the primary way to read a page' and contrasts it with screenshots, giving a clear when-to-use signal. However, it does not mention when not to use it or alternative read tools like browser_find or browser_snapshot_diff, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the basic action and does not mention potential side effects like triggering hover events or changing cursor appearance. While readOnlyHint=false implies some state change, the description does not elaborate on observable consequences beyond moving the mouse.
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 one concise sentence that directly states the action and coordinate format. It is front-loaded and contains no extraneous information, making it easy to parse and understand.
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?
For a simple mouse-move operation, the description is complete: it defines the action, the coordinate system, and the parameters. There is no output schema, and no additional context is necessary to call the tool correctly.
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 schema covers both parameters fully, and the tool description clarifies that coordinates are in viewport CSS pixels, which adds meaningful unit context. The per-parameter descriptions are minimal but adequate given the clarity of the parameter names and the tool-level unit specification.
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 moves the mouse to viewport coordinates, which is a specific and concrete action. It is distinguishable from siblings like click, hover, or drag because it only moves the cursor without any additional action.
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 does not explicitly compare with alternative tools such as browser_hover or browser_mouse_click_xy, which could help agents choose the right one. It is clear that this is a raw coordinate-based move, but the lack of explicit guidance on when to use it over element-based alternatives leaves some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool changes the current page but the description does not explain side effects such as losing unsaved form data or the possibility of the action being disabled when no history exists. Annotations provide limited additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is well-structured and directly to the point.
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 adequate for a tool with no parameters or output schema. It covers the core action but omits edge cases like history unavailability; however, this is not critical for understanding basic functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is nothing to explain. The empty schema is sufficient.
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 action (go back) and the target (previous page in history). It is unambiguous and specific.
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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention scenarios where back navigation is inappropriate or unavailable (e.g., no history).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (not read-only) and destructiveHint=false (not destructive). The description confirms the mutation by stating it changes network state, which is consistent. It adds the specific behavior (toggling offline/online) but does not mention side effects such as whether it affects the current page or session. Annotations already carry the safety profile, so a 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?
Two short sentences with zero waste. The core purpose is front-loaded ('Go offline or back online'), and the use case follows immediately. Every word earns its place.
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?
For a simple tool with one enum parameter, no output schema, and annotations that already cover the safety profile, the description is complete. It tells the agent what it does, when to use it, and the parameter is fully documented in the schema.
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 for the single parameter 'state', with an enum of ['online', 'offline'] and a clear description. The tool description does not need to add parameter details, and the baseline of 3 applies since the schema fully documents the parameter.
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 ('Go offline or back online') and resource (network state), and adds a clear use case ('testing error paths'). It is unambiguous and easily distinguishes from all sibling browser tools, which are navigation, interaction, and storage operations.
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?
It provides a clear context for when to use it ('testing error paths'), which guides an agent on appropriate scenarios. However, it does not explicitly state when not to use it or name alternatives; given there are no network-state siblings, this is acceptable but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool attaches to an existing Chrome instance and that it can switch browsers/tabs. It does not contradict the annotations (readOnlyHint=false, destructiveHint=false) and adds useful behavioral context without overstating side effects.
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 short sentences with no redundant or filler content. It is direct, readable, and front-loads the core action before the use case.
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 (all optional parameters, no output schema), the description is sufficiently complete. It explains both the mechanism and the intent, though it relies on the schema for parameter details.
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 six parameters, so baseline is appropriate. The description itself does not add extra parameter semantics, but none are needed because the schema coverage is complete.
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 action ('Attach Blinkwire to a Chrome instance exposing the DevTools Protocol') and the practical purpose ('switch browsers or tabs without restarting the server'). It is unambiguous about what the tool does at a high level.
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 explicitly says when to use this tool: to switch browsers or tabs without restarting the server. It does not deeply contrast with sibling tools, but the stated use case is enough to guide selection in most situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate non-read-only and non-destructive behavior. The description adds context that it simulates an external drag event, which is useful. No contradictions or hidden side effects are mentioned.
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, focused sentence with no unnecessary details. It is well-structured and easy to parse.
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 covers the core functionality and parameters, but could be enhanced by noting potential constraints (e.g., that the target must be a drop zone). Still, it is sufficiently complete for an agent to understand the tool's purpose.
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?
All three parameters have clear descriptions with a concrete example for 'data'. The schema covers 100% of parameters. However, the relationship between 'data' and 'paths' (e.g., whether they can be used together) is not clarified, slightly reducing completeness.
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 action (drop), the payload (files or MIME-typed data), and the target (an element), and distinguishes it from sibling tools like browser_drag (in-page dragging) and browser_file_upload (file input).
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 for simulating external drag-and-drop but does not explicitly compare with alternatives such as browser_drag or browser_file_upload, nor does it state conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool will either accept or dismiss a dialog and indicates the supported dialog types. Annotations do not contradict this behavior. It could mention side effects (e.g., dismissing may cancel navigation) but the core behavior is transparent enough given 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 concise and well-structured, consisting of two short sentences. It front-loads the main action and then adds essential timing context without any redundant or extraneous 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?
The description provides enough context for correct invocation, including dialog types and timing. It does not describe the absence of a return value or what happens if no dialog is pending, but these details are not necessary for the basic use case and the tool is simple enough that the provided context is adequate.
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?
Both parameters are covered by the schema descriptions with clear meaning: 'accept' indicates acceptance versus dismissal, and 'promptText' is for entering text into prompt dialogs. Since schema coverage is 100%, the description adds no extra semantic detail beyond the schema, so a baseline score 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: accepting or dismissing a pending JavaScript dialog. It lists the relevant dialog types (alert, confirm, prompt, beforeunload), which distinguishes it from other browser action tools and leaves no ambiguity about its 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 practical timing guidance by instructing to call the tool immediately after the action that opened the dialog. While it doesn't explicitly mention alternatives or edge cases, the guidance is sufficient for correct usage in the typical dialog-handling flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the immediate effect (moving the mouse and revealing hover menus) and does not contradict the annotations. It does not go into edge cases or side effects, but the primary behavior is transparent.
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 concise, consisting of two clear sentences with no redundancy. It front-loads the core action and then provides the primary use case.
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 simple nature of the tool and the lack of an output schema, the description is sufficient for an agent to know when and how to invoke it. It could mention that it does not click, but this is implied by the contrast with browser_click.
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 both parameters (target and element), so the tool description adds no additional parameter semantics. The baseline of 3 is appropriate since the schema covers all parameters.
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 action ('Move the mouse over an element') and distinguishes it from clicking or dragging. It also specifies the purpose of revealing hover menus, making it easy to differentiate from sibling tools.
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 explicitly says to use it to reveal hover menus before clicking, giving a concrete use case. It does not explicitly mention alternatives like coordinate-based mouse movement, but the intended usage is clear enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention any side effects beyond the click itself, such as whether it triggers navigation or waits for page load. Since annotations only indicate it is not read-only and not destructive, the description carries the burden but provides minimal extra detail about the click's 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 concise, using only two sentences to convey the action and the key guidance. Every word serves a purpose, with no redundancy or 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?
The tool is simple and self-contained; the description gives enough context about what it does and when to prefer it. It could mention that coordinates are relative to the viewport, but that is already implied by 'viewport coordinates' in the description and the parameter names.
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 (x, y, button, doubleClick) have straightforward descriptions in the schema, covering 100% of parameters. The description adds no additional per-parameter semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks at viewport coordinates, using a specific verb and resource. It also distinguishes itself from browser_click by mentioning the alternative with a ref, making its purpose unambiguous even among many sibling mouse tools.
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 advises preferring browser_click with a ref and explains why (coordinates break when layout shifts). This gives clear guidance on when to use this tool versus the alternative, leaving no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, so the description adds value by specifying that it resolves on the load event (or SPA history event) rather than a fixed sleep. This discloses the waiting mechanism, which is beyond the 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 with no redundant information. The first sentence states the action, the second explains the wait behavior. Every word 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?
Given a single required parameter and no output schema, the description covers the essential purpose and the waiting behavior. It doesn't mention error handling or timeouts, but for a simple navigation tool, it is sufficient. The mention of 'page to settle' and load event gives enough 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?
The schema covers 100% of the parameter with a description 'The URL to navigate to'. The tool description does not add additional semantics about URL format, validation, or relative vs absolute. Since schema coverage is high, the description adds no extra value for the parameter.
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 action ('Navigate to a URL') and the resource (URL). It also specifies the wait behavior, distinguishing it from sibling navigation tools like browser_navigate_back/forward/reload.
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 does not explicitly compare with alternatives, but the name and title make the primary navigation purpose clear. It provides context about waiting for the page to settle, implying it's the main navigation tool. However, it lacks explicit guidance on when to use back/forward/reload.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says what action is performed but not what effects it may have on the page (e.g., focus changes, event propagation, potential navigation). The annotations indicate non-read-only and non-destructive, but details of runtime behavior are not disclosed.
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 perfectly structured, using only necessary words and helpful examples. It is immediately scannable and free of extraneous information.
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 key-press operation, the description provides enough context to understand what the tool does. It does not mention return values or failure modes, but given the absence of an output schema and the simple nature of the 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?
Both parameters are described: 'key' covers the target key or combined shortcut, and 'modifiers' explains extra modifier keys. Examples reinforce the expected format, though a full list of valid key names is not provided.
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 purpose: pressing a key or modifier combo. Concrete examples (Enter, ArrowLeft, Control+A, Shift+Tab) remove ambiguity and distinguish it from mouse-based actions.
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 examples effectively illustrate typical keyboard inputs, but the description does not explicitly state when to prefer this over related actions like typing or clicking. It is still clear enough for common keyboard interaction scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral note beyond the destructiveHint annotation: 'The browser itself is left running — Blinkwire does not own it.' This clarifies that the browser process persists after the tab closes, which is useful context. It does not contradict the annotations, and it provides a meaningful insight into the side effects of the operation.
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 no redundancy. The core action is front-loaded, and the second sentence adds a valuable behavioral note without excess. Every word earns its place, making it a model of conciseness.
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?
For a tool with no parameters and no output schema, the description fully covers what an agent needs to know to invoke it correctly: the action (close current tab) and the key side effect (browser stays running). There are no missing prerequisites, return values, or error conditions that would leave an agent uncertain. The destructive annotation is consistent with the description, so no additional context is necessary.
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, so the schema is trivially complete. The description correctly omits parameter details since there are none. The baseline score for no parameters is 4, and the description does not need to add anything further about parameters.
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 action 'Close the current tab' with a specific verb and resource, distinguishing it from other browser tools. It unambiguously identifies what is being closed and the scope (current tab), leaving no ambiguity about its function.
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 usage is implied by the tool's name and description, but there is no explicit guidance on when to use this versus alternatives (e.g., browser_tabs to list tabs first) or when not to use it. It provides no context about prerequisites or scenarios where closing a tab is appropriate, but the intent is clear enough for a simple action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by explicitly stating that nothing is installed and no browser download occurs, reinforcing the non-destructive, purely informational nature. It goes beyond the annotations by clarifying the actual behavior (prints steps, no side effects).
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 zero waste. The key message ('Nothing to install') is front-loaded, followed by a clarifying explanation and the concrete action. Every word earns its place.
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?
For a zero-parameter, read-only information tool with no output schema, the description is complete. It tells the agent exactly what the tool does and what it outputs (setup steps). There is nothing missing that an agent would need to call it correctly.
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, so the schema trivially covers 100% of them. The description correctly adds no parameter information because none is needed. A baseline of 4 is appropriate 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 states a specific verb ('Prints') and resource ('exact setup steps'), and immediately clarifies that no installation is needed ('Nothing to install'). This distinguishes it clearly from all browser_* siblings, which are about navigation, interaction, and state management, not setup.
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 that this tool is for obtaining setup instructions, but it does not explicitly state when to use it versus alternatives. There are no similar sibling tools, so the need for differentiation is low, but the description could have mentioned 'Use this when you need to set up CDP connection' for clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description is consistent with those annotations and adds the detail that it returns all key-value pairs. No contradictory or additional behavioral traits are disclosed beyond what annotations provide.
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, clear sentence with no redundant information. It effectively communicates the tool's purpose without any verbosity or structural complexity.
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?
Given the tool has no parameters and no output schema, the description is complete. It specifies the action, the resource, and the scope ('current origin'), providing all necessary context for an agent to understand when and how to use it.
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, so there is nothing to describe. The schema fully covers the parameter aspect, and the description does not need to compensate. Baseline of 4 applies.
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 verb 'List' and the resource 'localStorage key-value pairs for the current origin'. It unambiguously differentiates from sibling tools like 'get' which targets a single key, and the scope is explicitly tied to the current origin.
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 for retrieving all localStorage entries versus specific keys, but does not explicitly mention alternative tools or provide conditions for when to choose this over others. Guidance is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true aligns with the description's 'show' verb, and the description adds useful detail that it returns headers and body. No contradictions; the description supplements the annotations with output specifics.
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 directly conveys the tool's function without superfluous words. It is well-structured and easy to parse.
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?
For a simple tool, the description is complete: it states what the tool does, references the prerequisite source of the index, and the parameter schema handles the rest. No additional context is needed for correct usage.
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 descriptions for both parameters (index as 1-based from browser_network_requests, part as an enum to return only a specific part), covering 100% of parameters. The tool description itself does not add extra meaning beyond the schema, so it meets the baseline.
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 purpose: to show headers and body of a single request. It uses a specific verb ('show') and references the resource (network request details) and the source of the index (browser_network_requests), distinguishing it from sibling tools like browser_network_requests which list requests.
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 clear context by referencing 'the number printed by browser_network_requests,' implying that this tool is used after listing requests to get details of one. However, it does not explicitly state when not to use it or mention alternatives, so it stops short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only and non-destructive. The description adds the important caveat that the Network domain is expensive and must be explicitly enabled, which goes beyond the basic safety 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 no filler. It states the core function, the default-off behavior, and the prerequisite flag in a compact and direct way.
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?
For a simple list operation, the description is complete: it specifies the data source (requests since page load), the availability caveat, and the expensive nature of the feature. No output schema exists, but the purpose and usage are sufficiently clear.
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 three parameters have descriptions in the schema, including defaults for limit and static. The tool description itself does not add additional meaning beyond what is already in 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists network requests made since page load, with a specific verb and resource. It is easily distinguished from sibling tools like browser_network_request, which would make a request rather than list them.
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 context on when the tool can be used, noting it is off by default and requires restarting with --network-capture. It does not explicitly name an alternative for other actions, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description names destructive behavior (closing tabs) and clarifies default behavior for closing without an index. It does not contradict the annotations, and it carries the transparency burden since readOnlyHint and destructiveHint are both false.
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 compact two-sentence summary that states the core operations and a key preference rule. No filler or redundant phrasing is present.
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 covers invocation and behavior for the main actions, but it does not describe the return value or output format for actions like list or create. Since there is no output schema, this missing information leaves some ambiguity for an agent.
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 schema descriptions cover all parameters, and the tool description adds decision logic about preferring select over new. The action parameter description is somewhat generic ('Operation to perform'), but the enum values are self-explanatory and reinforced by the tool description.
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 primary actions—list, create, close, or select—and the resource is a browser tab. It is unambiguous and distinguishes itself from sibling navigation and page-interaction tools.
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 actionable guidance: 'Prefer select over new when a matching tab already exists.' This helps an agent decide between the select and new actions, though it does not explicitly enumerate all sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides behavioral details about the effect on routes: removes one if pattern is given, all if not. This goes beyond the annotations which only indicate readOnly and destructive status. It does not mention side effects, but given the annotations, it is sufficient.
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 short and effective, using two clauses to convey the core functionality and parameter behavior without unnecessary words.
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?
For a simple tool with no output schema, the description covers the essential information: what it does and how the parameter affects behavior. It is complete in 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?
The parameter 'pattern' is described in the schema with the same information as the description. The tool description does not add additional insight beyond the schema, 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 action: removing mocked routes. It specifies the behavior for both providing a pattern and omitting it, and the title 'Remove network routes' aligns. It differentiates from sibling tools like browser_route and browser_route_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 explains when to use it: to remove a specific route or all routes. However, it does not explicitly mention alternatives or when not to use it, so it is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false, which is minimal. The description adds valuable behavioral context: the structure of steps ({tool, args}), the flexibility of tool names (bare or prefixed), and the output inlining behavior (failures and last step by default, use 'include' for more). This goes beyond annotations without contradicting them.
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 three sentences, each serving a distinct purpose: stating the core function and benefit, explaining the step format and naming, and clarifying output behavior. It is front-loaded with the most important information and contains no filler.
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 batching tool without an output schema, the description covers essential aspects: what it does, how steps are structured, and what the response includes. It could explicitly mention ordering guarantees or error handling beyond stopOnError, but the schema already documents 'Steps to run in order' and the description mentions failures, so it is adequately complete.
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 coverage is 100%, so the baseline is 3. However, the description adds meaning beyond the schema by explaining the step structure in detail, how tool names can be prefixed, and the default output inlining behavior tied to the 'include' parameter. This enriches the schema's parameter definitions.
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 explicitly states the verb 'Run' and the resource 'several Blinkwire actions in ONE call', clearly distinguishing it from the individual browser_* sibling tools. It conveys a specific, actionable purpose with no ambiguity.
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 strongly implies when to use it: 'the biggest latency and context win available' suggests using it for multiple actions. It doesn't explicitly list exclusions or alternatives, but the context is clear enough for an agent to decide between batching and single calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions the underlying CDP calls and lack of polling, but does not disclose that clicking may trigger navigation, modal dialogs, or other state changes. The annotation reads readOnlyHint=false, so some behavioral detail beyond the call count would improve transparency.
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?
Extremely concise and overloaded with useful clues. The description packs purpose, target identification, and performance characteristics into two short sentences without redundancy.
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?
Given six parameters and no output schema, the description fully covers what an agent needs to invoke this tool correctly. The extra note about CDP calls and no polling adds useful execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All six parameters have meaningful descriptions, including target with format examples, button with enum and default, modifiers list, and doubleClick boolean. Schema coverage is 100%.
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?
Explicitly states it clicks an element and specifies how to identify the target (ref or CSS selector), clearly distinguishing it from coordinate-based clicks or hover actions among sibling tools.
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?
Provides clear action guidance (pass a ref from browser_snapshot or CSS selector) and mentions the number of CDP calls, implying efficiency. Does not explicitly contrast with alternative click methods, but the context of siblings makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that output is captured 'since the last navigation' and that the 'all' parameter can include earlier messages, offering useful behavioral context. Annotations confirm read-only and non-destructive nature with no contradictions.
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, using two short sentences to convey both purpose and usage hints, 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?
The description is sufficient for an agent to understand what the tool does and how to apply basic filters, though it lacks explicit mention of the return format or structure. Given the simplicity, this is adequate.
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 schema provides descriptions for all three parameters, and the tool description adds practical context about filtering. While the schema covers 100% of parameters, the description's filter guidance enhances understanding beyond the basic 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 purpose with a specific verb ('Return') and resource ('console output'), making it distinct from sibling tools like browser_network_requests or browser_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 provides usage guidance by mentioning filtering options ('Filter by level or regex') to control output, but does not explicitly name alternative tools or when to prefer this one over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is transparent about the side effects: it sets the value and fires input/change events, and the annotations confirm non-destructive, non-read-only behavior without 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?
The description is two short sentences, direct, and contains only relevant information with no filler or redundancy.
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 action tool with no output schema, the description provides sufficient context about the operation and its effects, though it does not describe the return value, which is not required here.
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?
Each parameter has a meaningful description in the schema; 'target' gets a concrete example format, 'values' explains the expected data, and 'element' is self-explanatory as a human-readable label.
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 action ('Select one or more options'), the target element type ('<select>'), and distinguishes it from other browser interaction tools by focusing specifically on option selection.
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?
It explains how the action is performed ('One CDP call') and the resulting behavior ('sets the value and fires input/change'), which gives useful context, though it could more explicitly contrast with clicking or typing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the action is to 'list' entries, consistent with the readOnlyHint annotation. It also discloses the scope ('current origin'), which is a meaningful behavioral detail. No destructive behavior is implied or contradicted.
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 redundant words. It front-loads the action and resource, making it immediately understandable without extra fluff.
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 for a simple read operation. It does not describe the output format, but given the tool's purpose (listing key-value pairs) and the absence of an output schema, the omission is acceptable. The 'current origin' qualifier adds necessary context.
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?
There are no parameters in the input schema, and the description adds no parameter-specific details. Following the baseline for zero parameters, the score is 4 as the description correctly implies no arguments are needed.
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 the specific verb 'List' and clearly identifies the resource as 'sessionStorage key-value pairs' scoped to 'the current origin'. This unambiguously distinguishes it from related tools like browser_sessionstorage_get (single key) and browser_localstorage_list (different storage).
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 implies the use case of retrieving all session storage entries for the current page, and the 'current origin' qualifier sets expectations. It does not explicitly contrast with localStorage or mention when to prefer this tool, but for a zero-parameter read operation the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety; the description adds that it returns matching lines with refs, which is helpful behavioral detail. No contradiction with annotations, and the cost note adds transparency.
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 that pack in purpose, cost advantage, and return value. No wasted words, and the structure is direct and easy to parse.
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 description is complete for the tool's purpose. It tells the agent when to use it, what it does, and why it's beneficial, without needing additional context. Missing output schema details are not required for correct usage.
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 descriptions cover each parameter fully (text, regex, context). The description does not add additional meaning beyond the schema, but no further clarification is needed, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's function: search the current snapshot for text or regex and return matching lines with refs. It also highlights the cost benefit compared to reading the whole snapshot, effectively distinguishing it from snapshot retrieval tools.
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?
Explicitly mentions the primary use case (locating one element) and contrasts with the more expensive alternative (re-reading the whole snapshot). This gives clear guidance on when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what it returns (only changed lines) and notes it is a diff operation. The readOnlyHint annotation confirms it does not alter state. However, it does not describe edge cases like what happens if no snapshot exists, or the exact return format, leaving some minor ambiguity.
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 concise, with two sentences that convey the core functionality and a key benefit. No unnecessary words or redundancy.
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 tool with one optional parameter and no output schema, the description provides sufficient context to understand its purpose and basic behavior. It lacks explicit error handling or return structure details, but these are not critical for a straightforward diff operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter contextLines is fully described: it specifies the number of unchanged lines to show around each change, with a clear default. Schema coverage is 100%, and the description adds meaningful detail 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 purpose: to show only changes since the last snapshot. It also provides context ('cheapest way to check the effect of an action'), which distinguishes it from a full snapshot and makes its intent unambiguous.
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 implies usage by mentioning 'since the last snapshot' and 'effect of an action', but it does not explicitly state prerequisites (e.g., that a prior snapshot must exist) or contrast with sibling tools beyond the implied distinction from browser_snapshot. Still, the guidance is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, and the description adds the important behavioral trait that 'Screenshots cost a lot of context,' which is not in the annotations. This is valuable additional context about resource consumption, though it doesn't detail output format or other behaviors 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 two concise sentences with zero filler. It front-loads the core purpose and then immediately provides usage guidance, making every word earn its place.
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 description is complete for a screenshot tool. It covers when to use it, and the schema fully documents all parameters including default behaviors like viewport capture and file saving. No critical information is missing for an agent to call 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?
The input schema has 100% coverage with detailed descriptions for all 7 parameters, so the description does not need to add parameter-level meaning. The description adds nothing beyond the schema, so it meets the baseline for high schema coverage.
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 the exact action 'Capture the page as an image' with a clear verb and resource, and it distinguishes itself from the sibling browser_snapshot by mentioning the alternative. This makes the tool's purpose unambiguous and sets it apart from related tools.
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?
It explicitly advises 'prefer browser_snapshot, and use this only when you need to see pixels,' which clearly states when to use this tool versus the alternative. This is direct and actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond the annotations: the default fast path uses Input.insertText without per-character key events, and it explicitly states when to use slowly:true. This is critical because many pages rely on per-key events, and the description surfaces this behavior so the agent can make an informed choice. The annotations (readOnlyHint: false, destructiveHint: false) already indicate it's a write operation, and the description adds valuable detail about how the write 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 two sentences long with no unnecessary filler. The first sentence states the core purpose, and the second immediately provides the key behavioral nuance. The information is front-loaded and each sentence earns its place. It is both concise and structured effectively for quick 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 simple typing tool with a well-documented schema and annotations, the description covers the most important behavioral nuance (fast path vs. slow). It does not mention whether typing clears existing content or appends at the cursor, which could be a minor gap, but this is not critical for most use cases. Given the tool's simplicity and the schema/annotation coverage, the description is sufficiently complete.
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 coverage is 100%, so all parameters are documented. The description adds meaning beyond the schema by explaining the default behavior of the 'slowly' parameter (fast path vs. real per-key events) and when to override it. Other parameters like 'target' and 'text' are already well-described in the schema, and the description does not need to repeat them. The added context for 'slowly' justifies a score above the baseline of 3.
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 purpose: 'Type text into an editable element.' The verb 'Type' and resource 'text into an editable element' are specific, and the description also mentions the fast path vs. slow path, which helps distinguish it from sibling tools like browser_press_key (single key presses) or browser_click (clicking). The purpose is unambiguous and directly ties to the tool's name.
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 usage condition for the 'slowly' parameter ('use slowly:true only when the page needs real per-key events'), which is a form of usage guidance. However, it does not explicitly contrast this tool with alternatives like browser_fill_form or browser_press_key, nor does it state when not to use this tool. The context is clear enough that an agent would know to use it for typing, but explicit exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 known. The description adds that it is a 'cheap diagnostic' (a performance trait) and specifies the exact information it returns (browser, target, buffer sizes), which goes beyond the annotations. It does not contradict the annotations and provides useful behavioral context, though it does not elaborate on side effects or output format beyond what is implied.
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 short sentences with zero fluff. It front-loads the core purpose ('Show the attached browser, active target and buffer sizes') and then delivers a crisp usage recommendation. Every word earns its place; it is both efficient and well-structured.
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?
For a parameterless read-only diagnostic with annotations covering safety, this description is complete. It tells the agent what the tool does, when to use it, and what information it provides. Without an output schema, the mention of 'browser, active target and buffer sizes' gives enough detail for an agent to understand the expected output. Nothing essential is missing.
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, so the schema is trivially 100% covered. The description does not need to explain parameter semantics because there are none. The baseline for 0 params is 4, and the description correctly focuses on what the tool returns rather than inputs.
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: 'Show the attached browser, active target and buffer sizes.' It names specific outputs and is clearly distinct from the many sibling navigation/action tools, which perform mutations or interactions. The verb 'Show' and the resource 'browser status' are specific, and the description avoids tautology.
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 tells the agent when to use it: 'call it first when something looks wrong.' This is a clear usage recommendation that positions it as a diagnostic first step, distinguishing it from action-oriented siblings. It also implies it is not for performing actions, which is consistent with the tool's read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says it dispatches a wheel event and mentions it is a synthetic scroll animation, which gives some insight into behavior. The readOnlyHint=false annotation indicates state mutation, though the description itself could more explicitly state that scrolling will occur.
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 concise, using only two sentences with no redundant information, and the structure directly states the action and the recommendation.
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 description includes a reference to browser_scroll, providing context for when this tool is useful versus the alternative, and is sufficiently complete for a simple scroll action without needing to specify return values or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are clearly explained: deltaX as horizontal scroll delta in pixels, and deltaY as vertical scroll delta with positive meaning downward, adding meaningful detail beyond the parameter 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 clearly states that the tool dispatches a wheel event and explicitly recommends browser_scroll as a preferred alternative, making the purpose unambiguous and differentiating it from related tools.
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 provides direct usage guidance by advising to prefer browser_scroll for a single round-trip instead of a synthetic scroll animation, giving clear situational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Blinkwire MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Blinkwire MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/81117105108108/Blinkwire/badges/card.svg)](https://glama.ai/mcp/servers/81117105108108/Blinkwire)

Score Badge

Copy to your README.md:

[![Blinkwire MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/81117105108108/Blinkwire/badges/score.svg)](https://glama.ai/mcp/servers/81117105108108/Blinkwire)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/81117105108108/Blinkwire'

If you have feedback or need assistance with the MCP directory API, please join our Discord server