usable-browser-agent-free
Server Quality Checklist
Latest release: v0.7.0
- Disambiguation4/5
Most tools target distinct actions and resources with detailed descriptions, and overlapping pairs like browser_type vs browser_paste vs browser_os_type are clearly differentiated. A few similar-sounding tools (browser_status vs browser_info, browser_snapshot vs browser_screenshot) still require careful reading, so it is not perfect.
Naming Consistency4/5All tools share the browser_ prefix and most follow a clear verb_noun pattern (browser_list_tabs, browser_close_tab, browser_upload_file). There are minor deviations like noun-only names (browser_status, browser_snapshot) and noun-verb ordering (browser_workflow_recall), but the overall pattern remains predictable.
Tool Count1/553 tools is far beyond the typical well-scoped 3-15 range and exceeds the 50+ threshold for an extreme mismatch. Even for a broad browser-automation domain, the surface is bloated with many variants (OS-level clicks, clipboard image handling, workflow memory) that could likely be consolidated.
Completeness4/5The tool set covers the full browser lifecycle: tabs, navigation, interaction, forms, secrets, clipboard, downloads/uploads, dialogs, screenshots, network inspection, and OS-level fallbacks. Minor gaps like cookie management and console-log inspection exist but can be worked around via browser_eval or browser_network_log.
Average 3.9/5 across 53 of 53 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.jsonto 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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Write text to the system clipboard', which states the obvious operation but does not mention overwrite behavior, platform differences, or any side effects. The agent gains no extra insight beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it is so brief that it lacks any structured presentation of important details; it is under-specified rather than efficiently concise. It earns a 4 for being short, but not a 5 due to missing structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimal. It provides the core action but omits any context about parameter expectations, clipboard behavior, or interaction with other tools. An agent could call it correctly, but it is incomplete for a robust understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single 'text' parameter with type string and zero description coverage. The tool description does not mention the parameter at all, so it adds no semantic value. Given the low schema coverage, the description should compensate, but it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Write') and resource ('text to the system clipboard'), and implicitly distinguishes from sibling tools like browser_clipboard_write_image by specifying 'text'. It is not a tautology because it adds the 'text' qualifier, but it is minimal and does not elaborate on any specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of conditions, prerequisites, or references to sibling clipboard tools. The agent is left without any routing cues.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'recent' but does not define the recency window, ordering, whether the list is limited to completed downloads, or what 'state' encompasses. It also doesn't disclose potential side effects (e.g., whether it refreshes the download cache). This is minimal disclosure for a listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the core action and result. However, it is arguably too terse, leaving out essential context, but for conciseness alone it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and no annotations, the description should explain the return shape, the meaning of 'state', and the effect of 'limit'. It provides none of these. An agent cannot predict what fields will be in the result or how to interpret the output, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'limit' (a number, optional), and the schema has zero description coverage (0%). The description does not mention 'limit' at all, so it provides no semantic guidance on what it controls (e.g., number of entries returned, default value, or maximum). The agent must guess the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('recent downloads') with useful specifics ('on-disk paths and state'). It is distinct from sibling tools like browser_download (which initiates downloads) and browser_save_pdf (which saves PDFs), though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or exclusions. The agent must infer that this is the listing counterpart to download actions, but nothing in the description tells it when to choose this over other browser tools.
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?
With no annotations, the description must disclose behavioral traits. It only says the pointer hovers over an element, but omits whether hover events are triggered, whether the element must be visible, whether the action is synchronous, or any side effects. This is minimal for an interactive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no fluff. It is front-loaded and conveys the core action and target efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter and no output schema, the description is incomplete. An agent needs to know how to obtain a valid ref (e.g., from browser_snapshot), whether the element must be in view, and what happens after hovering. Without this, the tool may be misused.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'ref' parameter with 0% coverage. The description says 'by ref' but does not explain what a 'ref' is, how to obtain it, or its format. This adds minimal meaning beyond the parameter name and leaves the agent guessing about the required value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (hover), the target (element), and the mechanism (by ref). While it doesn't explicitly contrast with siblings like browser_click or browser_drag, the verb 'hover' is unambiguous and distinct enough for an agent to infer 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 Guidelines2/5Does 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's no mention of prerequisites (e.g., needing a ref from a prior snapshot), when hover is preferred over click or drag, or any exclusion conditions.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without revealing side effects, error handling, or whether the operation is reversible. The description is minimal and does not clarify what happens if the tab id is invalid or if any state changes occur beyond activation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. It adds a useful nuance about the agent's interaction with the active tab. It is appropriately sized for the tool's simplicity, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a minimal description might suffice, but it lacks essential context for an agent: how to find the tab id, what happens on failure, and whether any output is returned. The sibling browser_list_tabs is not referenced, and there is no output schema to fall back on. This is incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter, tabId, with zero description coverage. The description mentions 'by id' but does not explain what the id represents, how to obtain it, or its format. Since the schema coverage is 0%, the description should compensate, but it only weakly ties the parameter to the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Make a tab active') and the resource (tab by id), and adds the context that the agent then acts on the active tab, which differentiates it from tab creation/closing tools. This is a specific and unambiguous 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/5Does 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_new_tab or browser_close_tab. It does not mention prerequisites (e.g., using browser_list_tabs to obtain an id) or exclude any scenarios, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the submit flag but does not disclose the clear default behavior (true per schema) or whether it replaces or appends text. It also omits error handling or field visibility requirements, making it 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the primary action and the submit option. No wasted words, and it reads clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is incomplete. It omits the default clear behavior, doesn't explain what happens if the field isn't found, and doesn't mention any return value. The agent lacks critical context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (clear and submit have descriptions, ref and text do not). The tool description explains that ref identifies the field and text is what to type, adding some meaning. However, it doesn't define the format or scope of ref or text, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: focus a text field by ref and type text into it. The verb 'type' distinguishes it from clicking, pasting, or filling forms, but it does not explicitly differentiate from siblings like browser_fill_form or browser_paste, so it's clear but without sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_fill_form or browser_paste. The description only explains the action, leaving the agent to infer appropriate usage from the action itself.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the default behavior (active tab) but does not disclose potential side effects such as unsaved data loss, confirmation dialogs, or error behavior when tabId is invalid. For a destructive action, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It states the action, the parameter, and the default in a compact and efficient manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tab-close operation, the description is functional but minimal. It lacks information about return values (no output schema), error handling, or side effects. Given the lack of annotations, the description should provide more context to ensure correct invocation, especially for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (tabId) with no description (coverage 0%), so the description must compensate. It explains that omitting tabId defaults to the active tab, adding meaning beyond the schema. However, it does not explain what the id represents (e.g., how to obtain it) or any constraints on its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (close) and the resource (a tab), with the parameter being the tab id and the default being the active tab. It is distinct from sibling tools like browser_list_tabs or browser_select_tab, though it doesn't explicitly name alternatives. 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 Guidelines2/5Does 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_select_tab or browser_new_tab. The description only states what it does, not the context or conditions for its use. No exclusions or preferred scenarios 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the new tab is made active, which is a useful behavioral trait, but it does not disclose side effects (e.g., what happens if the URL is invalid, whether the tab is created in the background, or what the return value is). For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It conveys the action, the optional parameter, and the resulting state (active) efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description is mostly complete. It covers the core operation and the active-state behavior. It does not describe the return value or potential error conditions, but given the tool's simplicity and lack of an output schema, these are minor omissions. An agent can correctly call it with just this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single optional url parameter with no description, so the description's phrase 'optionally at a URL' adds meaning by indicating that the url parameter sets the new tab's address. While the schema already marks it as optional, the description clarifies its role, which compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (open a new tab) and the resource (tab), and adds the behavior of making it active. It distinguishes from list/select/close but does not explicitly contrast with browser_navigate, which also manipulates tabs. Still, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like browser_navigate or browser_select_tab. The 'optionally at a URL' hints at flexibility but does not explain scenarios where a new tab is preferable to reusing an existing one. No exclusions or alternative recommendations are given.
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 word 'Get' implies a read-only action and 'current value/text' tells the agent what to expect. However, with no annotations provided, the description does not explicitly address side effects, waiting behavior, handling of invalid refs, or hidden elements. It is minimally transparent but leaves some behavioral context unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant wording. It conveys the operation and the key parameter in one line, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description conveys the core action and the required input. However, it omits the source of refs, return behavior, and how this tool relates to the close sibling browser_read_text, so an agent may still have open questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines ref as a string with no description. The description adds that ref identifies a field or element, which provides some meaning, but it does not explain where ref comes from, its expected format, or how it relates to refs from other browser tools. Partial compensation for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (get current value/text) and a resource (field/element by ref). However, it does not differentiate this tool from the similarly named sibling browser_read_text, which could plausibly serve the same 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use browser_get_value instead of alternatives such as browser_read_text or browser_snapshot. There are no exclusions or conditions that would help an agent choose 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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the waiting condition and timeout behavior, which is useful. However, it does not disclose what happens on timeout (error vs. return value), whether the text can be in hidden elements, or whether the wait re-checks continuously.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core behavior immediately. There is no filler, and the key condition ('text appears anywhere on the page') is front-loaded before the timeout note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter wait tool, the description covers the essential purpose and behavior. Still, missing timeout semantics (units, default, timeout failure behavior) and return-value information leave slight gaps that could affect an agent's ability to call it correctly in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add meaningful detail about the parameters. It references 'given text' and 'timeout', but does not specify timeout units, default values, whether timeout is in milliseconds, or whether text matching is exact/substring/case-sensitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to wait until a given text appears anywhere on the page or until a timeout occurs. It uses a specific verb ('wait') and a clear resource ('text'), which distinguishes it from generic wait tools, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of use is implied: use this tool when you need to block until specific text is visible or present on the page. However, it provides no explicit guidance about when not to use it, how it differs from browser_wait, or when browser_read_text or browser_snapshot might be more appropriate.
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?
No annotations are provided, so the description carries the behavioral burden. It discloses the core behavior of advancing through the active tab's history, but it does not mention what happens when there is no forward history, whether the tool waits for page load, or how failures are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The action and scope are front-loaded, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema action, the description conveys the essential operation and scope. However, with no annotations and no mention of edge behavior, it leaves some uncertainty about failure modes and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and there are zero parameters, so there is nothing for the description to document. The baseline for zero parameters is 4, and the description appropriately adds no redundant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Go forward') and the resource ('the active tab's history'). It is specific enough to be understood, and the direction 'forward' implicitly separates it from browser_back, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus browser_back, browser_navigate, or browser_reload. The intended condition, such as 'use after going back' or 'redo a navigation,' is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but does not explicitly state that it is non-destructive, has no side effects, or what happens if there is no active tab. It also does not mention any permission requirements or rate limits. The description adds little beyond the basic read intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the action and then lists the exact data points returned. There is no redundant language or filler. It earns its place with every word contributing to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description lists the data points returned but does not describe the output format (e.g., an object with keys) or how the 'workflow-memory hints' are presented. It also does not mention error cases or how this differs from browser_status, which might return overlapping info. With no output schema, the description should provide more structural detail to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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). Since there are no parameters to document, the description does not need to add any parameter semantics. The baseline for zero parameters is 4, and the description does not need to compensate for any missing parameter information. It is appropriately concise in this regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource: the active tab's url, title, load state, scroll position, and workflow-memory hints. This is specific and distinct from siblings like browser_list_tabs (which lists all tabs) or browser_status (which likely gives overall browser status). The tool's purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that browser_status or browser_snapshot might be more appropriate for other contexts, nor does it state any exclusions. The only implied usage is 'when you need this info,' which is not explicit enough for an agent to make a reliable selection among many similar browser inspection tools.
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?
No annotations are provided, so the description carries the full burden. It only mentions the selection mechanism ('by visible label or value') but omits side effects, prerequisites, error behavior, or what happens if the option isn't found. This is minimal for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the core action front-loaded. Every word earns its place, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core action and value semantics, but 'ref' remains undefined and return behavior (success/failure) is not mentioned. Given the tool's simplicity, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'value' parameter by clarifying it can be a visible label or a value, which is not in the schema (coverage 0%). However, 'ref' is left unexplained—likely a reference to the select element—so the description only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Choose'), a clear resource ('an option in a <select> dropdown'), and the method ('by visible label or value'). This clearly distinguishes it from sibling tools like browser_click or browser_type, which handle general clicking or typing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for dropdown selections, but it doesn't explicitly say when to prefer it over alternatives (e.g., browser_fill_form, browser_click). No exclusions or alternative routing are provided, leaving some inference required.
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?
With no annotations, the description must carry the burden. It discloses the important security behavior (secrets never accepted/returned) but omits other behavioral details such as side effects (e.g., form submission), requirements (visible element), or error conditions. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the purpose and immediately state a critical constraint. Every word earns its place, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that interacts with the browser, the description lacks context: it does not mention that 'ref' comes from browser_snapshot, nor what happens after filling (e.g., does it submit the form?). There is no output schema to compensate. The description is minimal but leaves key workflow gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions 'secret alias' which matches the schema's description, but does not elaborate on 'ref' or 'field'. It adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fill a username or password field') and the source ('server-side credential broker'). It implicitly distinguishes from sibling tools like browser_fill_form by focusing on secret fields, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one key guideline (pass only a secret alias, never actual secret values) but does not explicitly contrast with alternatives like browser_fill_form or browser_login, nor does it state when to use this tool over others. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only restates the action without revealing side effects, failure modes, or non-destructive guarantees. It does not mention whether the list is a snapshot, what happens with no tabs, or any performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. The action and key output details are front-loaded, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description is nearly complete. It specifies the output fields and the scope (all open tabs). Minor omissions like window scoping or empty-tab behavior are acceptable given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema covers everything vacuously. The description adds value by listing the returned fields (ids, urls, titles), which is helpful for an agent anticipating the output structure. Baseline 4 applies for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), the resource (open tabs), and the specific output fields (ids, urls, titles). It is unambiguous and easily distinguishes this tool from siblings like browser_select_tab or browser_new_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While the name implies its purpose, the description does not explicitly direct an agent on when listing tabs is appropriate or what to consider instead.
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?
No annotations are present, so the description carries the full burden. It only states the action without disclosing side effects such as discarding unsaved form data, re-fetching from cache vs network, or that it may interrupt ongoing page operations. This is a significant gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundancy. It is perfectly sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 is largely adequate. It clearly identifies the action and target. However, it could briefly mention that reloading discards current page state, which is important for an agent to know. The lack of that nuance prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully documents them (vacuous 100% coverage). The description correctly makes no parameter claims, and the baseline for 0 parameters is 4, as nothing is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Reload') and a clear resource ('active tab'). It is unambiguous and distinct from siblings like browser_navigate, browser_back, or browser_forward, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 vs alternatives. For example, it does not clarify when to reload versus navigate to the same URL, or when a reload might be preferred over back/forward. The description gives no context about appropriate 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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the conditional return of hints based on workflow memories, but does not describe the output format, side-effect safety, or what the bridge connection check returns. It is not misleading, but it is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the primary purpose and then add the conditional behavior. There is no wasted wording, and it is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what the agent can expect as a return value. It mentions 'short hints' but does not specify the structure or content of those hints, nor what the bridge connection status looks like. It is adequate but leaves some ambiguity for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric baseline is 4. The description adds no parameter information because none is needed; the schema already covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific purpose: checking the bridge connection and current active tab, and conditionally returning workflow memory hints. It is not a tautology and is distinct from sibling tools like browser_list_tabs or browser_native_status, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need bridge and active tab status), but it does not provide explicit guidance on when to prefer it over alternatives like browser_native_status or browser_info, nor does it state any exclusions or prerequisites.
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?
With no annotations, the description carries the burden. It discloses that ref with no direction/to just reveals the container, and that to='bottom' jumps to the end. However, it does not mention smooth vs. instant scrolling, focus changes, or the effect of combining direction and amount. Some behavioral nuance is covered, but not exhaustively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the main action, then provide practical usage details. No fluff or repetition; every sentence contributes to understanding when and how to use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description leaves out critical information about the interaction between direction, amount, and to. It doesn't explain what happens when direction is combined with to, or how amount scales the scroll. For a tool with 4 parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only to and ref have schema descriptions. The description adds meaning for ref (reveal behavior) and to (infinite-scroll trigger), but says nothing about the 'amount' and 'direction' parameters, which are entirely undocumented in both schema and description. This fails to compensate for the low coverage on half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 a scrollable container, with a specific verb and resource. It differentiates from siblings because no other sibling tool is for scrolling; it also distinguishes between window and container scrolling via ref.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to pass a ref (to scroll a container like inner panes or virtualized lists) versus omit it (scroll the window). Also explains using to='bottom' to trigger infinite-scroll loading. No exclusions are given, but no direct alternatives exist among siblings, so the context is sufficient.
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?
With no annotations, the description carries the behavioral burden. It accurately states the behavior (waiting a fixed number of milliseconds) and adds a caution, but does not explain what happens after the wait, why it should be used sparingly, or whether it blocks or only pauses automation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the action first, then the parameter unit, then the caution. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core behavior and unit. However, it lacks guidance on when to use it versus browser_wait_for_text and does not describe the return value or side effects, leaving some context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'ms' as a number with no description, so the description must clarify meaning. It does convey that the value is in milliseconds, but it does not specify constraints like allowed range, integer-only, or typical limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: waiting a fixed number of milliseconds. It distinguishes itself from sibling browser_wait_for_text by specifying a fixed duration rather than a condition-based wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'use sparingly' gives some usage caution, implying fixed delays should be avoided when possible. However, it does not explicitly say when to prefer alternatives like browser_wait_for_text or provide when/when-not selection rules.
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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the action and purpose but offers no additional details about side effects (e.g., overwriting existing clipboard contents), prerequisites (e.g., active browser session), or failure modes. It is not misleading, but it fails to convey any behavior beyond the literal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It conveys the action and purpose efficiently, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter write operation with no output schema, the description covers the essential aspects: what to provide (local image file) and the intended outcome (paste into a page). It does not mention potential edge cases like unsupported image formats or clipboard behavior, but given the tool's simplicity, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – the schema already fully describes the path parameter as an absolute path to a local image file. The description does not add any additional semantic detail or format guidance beyond what the schema provides, so it meets the baseline for fully covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (put a local image file onto the system clipboard) and the intended purpose (pasting into a page). It distinguishes itself from sibling browser_clipboard_write by specifying 'image file' and from read operations like browser_clipboard_read_image. The verb-resource pair is specific and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a local image file to place on the clipboard for pasting. However, it does not explicitly mention alternatives or exclusion criteria, such as 'use browser_clipboard_write for text'. Given the clear name and sibling context, the intended usage is inferable, but explicit when-to-use guidance is missing.
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?
With no annotations provided, the description carries the full behavioral burden. It adds useful context about batching ('in one call') and a reliability/performance comparison to browser_type, but it does not disclose whether existing field values are replaced or appended, how missing refs are handled, or what the tool returns on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences totaling roughly 30 words, with the core purpose front-loaded and no filler. The parameter convention and the comparison to browser_type each earn their place in a compact definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool the definition covers purpose, input shape, and usage context, but with no output schema and no annotations it omits the return value, error behavior, and the meaning of ref. An agent calling this tool has enough to attempt a call but not enough to handle failures or validate inputs confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but 'Pass fields as an array of {ref, text}' merely restates what the input schema already defines. It does not explain what a ref is (selector, accessibility id, snapshot reference) or how an agent should obtain valid ref values, leaving the key parameter semantically ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fill multiple fields in one call.' It clearly states the batch nature of the operation and distinguishes it from the sibling browser_type by claiming it is faster and more reliable for forms. An agent can tell what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names browser_type as the alternative and gives the selection condition ('for forms'), providing clear context for when the batch call is preferable. However, it does not state explicit when-not conditions, such as using browser_type for a single field or browser_fill_secret for sensitive values.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool navigates the active tab and waits for loading to finish, which covers the core behavior. However, it omits details about timeout handling, error behavior, or what 'finished loading' means (e.g., does it wait for all resources?). These are notable gaps for a navigation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that is front-loaded with the verb and resource. No unnecessary words or repetition. It efficiently conveys the action and the wait-for-load behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple navigation tool, the description covers the essential action and target, but lacks details on the optional timeout parameter and error conditions. Since there is no output schema or annotations, the description is the only source of behavioral context; it is adequate for basic usage but not fully complete for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: only 'url' has a description, and 'timeout' is undocumented. The description adds no extra meaning for either parameter; it simply restates the action. It does not explain timeout's purpose, units, or default behavior, which is a significant omission given the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (navigate), the target (active tab), and the destination (a URL), plus a notable behavioral detail (wait for loading). This distinguishes it from sibling tools like browser_back, browser_forward, browser_reload, and browser_new_tab, which handle different navigation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: navigating the active tab to a specific URL. It does not explicitly mention alternatives or when not to use it, but the context of sibling tools (new_tab, back, forward) makes the scope clear. A short exclusion note would strengthen it, but the intent is evident.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the action (disarm HTTP auth) and the scope (all or specific domains), but it does not mention edge cases (e.g., behavior when no auth is armed), side effects on the browser session, or any prerequisites beyond 'previously-armed'. It is transparent about the core action but lacks depth on consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. The main action is front-loaded, and the parameter scope is mentioned efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 covers the core action and parameter semantics. However, with no annotations, it lacks explicit statements about return values, side effects (e.g., whether it clears auth for future requests), or error conditions. It is adequate but not fully complete for an agent to anticipate all behavioral outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description directly explains the 'domains' parameter by stating it can clear 'all domains, or specific ones'. This adds meaning beyond the schema's bare array-of-strings definition. The explanation is sufficient for an agent to understand how to use the parameter, though it doesn't specify domain string format, which is likely self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Disarm') and a specific resource ('previously-armed HTTP basic-auth answers'), and clarifies the scope ('all domains, or specific ones'). It is clear and distinct from sibling tools like browser_http_auth, even though it doesn't explicitly name it. 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing 'previously-armed' auth, which suggests it is used after arming via browser_http_auth. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. Usage is implied rather than explicitly guided.
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?
No annotations are provided, so the description carries the full burden. It discloses the real OS-level nature and macOS-only constraint, but does not explain side effects, focus requirements, or how modifiers are applied. The description is honest but lacks depth about operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and supported with constraints. Every phrase adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key action, allowed values, platform, and use case. However, it omits details on modifier syntax and does not explicitly contrast with browser_press_key, which could lead to confusion. For a simple tool, it's adequate but has gaps in parameter specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists allowed key values and mentions 'single char', which helps, but the 'modifiers' parameter is only described as 'optionally with modifiers' without specifying valid modifier strings (e.g., 'Shift', 'Cmd') or their format. This leaves ambiguity for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool presses a REAL OS key, lists specific allowed keys (Enter, Tab, Escape, ArrowDown, F1-F8, or a single char), and notes optional modifiers. This distinguishes it from synthetic key tools like browser_press_key by emphasizing 'REAL OS key'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the intended use case: 'For native UI and isTrusted-checking pages' and notes the platform constraint 'macOS only'. While it doesn't explicitly name alternatives or say when NOT to use it, the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior: it simulates a real paste event and either pastes the provided text or the clipboard contents when text is omitted. It does not, however, mention potential limitations such as the element needing to be focused or editable, or how invalid refs are handled. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. The core purpose is front-loaded, and the optional behavior (clipboard fallback) is stated clearly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential action and the two input modes, but it omits return value information (no output schema) and does not mention prerequisites like element focus or editability. For a simple paste tool, this is acceptable but could be more thorough given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: only 'text' has a description in the schema, and 'ref' does not. The description adds meaningful semantics for 'text' by explaining the two modes (given text vs clipboard). It does not explain what 'ref' is beyond 'by ref', so the agent must infer from prior context. This partially compensates for the missing schema description but leaves 'ref' undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pastes into an element by ref using a real paste event, and explicitly distinguishes it from typing for rich editors. It names specific target platforms (Google Docs, Notion, contenteditable), making the purpose and differentiation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on when to use this tool over typing ('rich editors handle this better than typing'), implying it should be used for contenteditable scenarios. However, it does not explicitly name sibling alternatives like browser_type or browser_press_key, nor does it state when not to use it. Still, the context is clear enough for an agent to make a reasonable choice.
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?
With no annotations provided, the description carries the full burden. It discloses that dialogs are auto-answered to never block the agent, explains the meaning of accept, promptText, and suppress, and clarifies the scope (current page) and re-setting requirement. This is transparent and actionable, though it doesn't cover potential side effects like whether the policy resets automatically on reload or applies to iframes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no waste. It front-loads the core purpose, then covers each parameter and a critical usage caveat (re-set after navigation). Every sentence carries information, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with three optional parameters and no output schema, the description is fairly complete. It explains the parameters, defaults, and scope. The only minor gap is not specifying the return value (if any) or error conditions, but given the simplicity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description, but the tool description adds significant context: accept=true confirms (default), promptText sets the return value only when accepted, and suppress neutralizes beforeunload guards. This goes beyond the schema by explaining the interplay between parameters and default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets how native JS dialogs are auto-answered, with a specific verb (set) and resource (dialog policy). It explains the three parameters' effects, distinguishing it from sibling tools like browser_native_dialog which likely handle dialogs interactively, though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear scoping note ('Applies to the current page; re-set after navigation if needed'), which is useful context. However, it does not explicitly mention when to use this tool over related siblings like browser_dialogs or browser_native_dialog, so an agent must infer the distinction.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the core action, but does not disclose edge-case behavior, such as what happens when the active tab has no history, whether the action triggers navigation events, or how it interacts with the current page state. This is a real gap for an un-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tight sentence with zero wasted words. The action is front-loaded, and every word earns its place. Nothing is verbose or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is nearly complete — an agent knows exactly what happens. The only gap is edge-case behavior (empty history), which is minor given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is nothing for the description to explain about parameters, and no schema-coverage burden to compensate for. The description correctly says nothing about parameters because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go back in the active tab's history' names a specific verb and resource, and naturally distinguishes from siblings like browser_forward (go forward) and browser_navigate (direct navigation). An agent can immediately tell what this does and how it differs from its neighbors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied — an agent would call this after navigating somewhere — but there is no explicit guidance on when to choose back over navigate, forward, or reload. No exclusions or alternatives are named, though for such a simple operation the implied usage is reasonably 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?
With no annotations, the description carries the full burden. It discloses the core effect (returning a fixed position), the scope (current page only), and the reset mechanism (clear=true). However, it does not mention default behavior when latitude/longitude are omitted, nor does it describe accuracy defaults or side effects on other tabs. It is transparent about the essential behaviors but leaves a few edge cases unstated, so a 4 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the purpose and then providing the essential usage caveats. Every sentence adds value with no filler, and the structure is easy to scan. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain all relevant context. It covers the core effect, scope, and clearing, but leaves out how to actually set the coordinates (which parameters to use) and what happens if lat/lon are absent. For a tool with four optional parameters, this is an incomplete picture, though the tool is simple enough that a 3 is appropriate rather than lower.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'clear' and 'accuracy' but leaves 'latitude' and 'longitude' without any description (50% coverage). The description fails to mention these parameters at all, so an agent cannot infer that they specify the mocked position. Since the description must compensate for the schema gaps but does not, the parameter semantics are notably weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Make navigator.geolocation return a fixed position'. It clearly states what the tool does and its purpose (bypassing permission prompts for location-gated tasks). There is no sibling tool for geolocation, so no ambiguity exists; this is a strong, specific purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Pass clear=true to stop mocking' and 'Applies to the current page; re-set after navigation', giving clear when-to-use and when-not-to instructions. It does not name alternatives because none exist among siblings, but the usage conditions are concrete and actionable, earning a 4 rather than a 5.
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?
No annotations are provided, so the description carries full responsibility. It implies a read-only operation via 'Inspect' but does not explicitly state safety, side effects, or that it does not modify browser state. It does describe the data returned, which is helpful, but stops short of full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core purpose and data, the second gives practical use cases. No redundant words, and the key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only inspection tool with no output schema, the description adequately covers what it returns and common use cases. It doesn't explain how to interpret errors or pagination, but those are minor given the tool's simplicity and the schema covering parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no extra meaning beyond the schema; it only mentions the response fields, not parameter nuances. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Inspect') and resource ('recent network requests'), and lists the key fields (method, URL, status, type, errors). It distinguishes itself from sibling tools like browser_status or browser_info, which focus on browser state rather than network activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete use cases: diagnosing why a button 'did nothing', finding an API endpoint, or confirming a request succeeded. These give clear context for when to use the tool. It lacks explicit 'when not to use' or alternatives, but the context is strong enough to guide selection.
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?
No annotations are provided, so the description carries the full burden. It discloses that the key goes to the focused element unless a ref is provided, which is key behavioral context. However, it does not mention potential side effects (e.g., navigation triggered by keys), whether it waits for any condition, or how invalid keys/refs are handled. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and examples, then explains the ref behavior. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema or annotations, the description covers the essential usage: what the tool does, how to target an element, and the fallback. It doesn't cover edge cases like key validity or post-action state, but these are minor for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that 'key' is a key name (with examples) and 'ref' is an element target, adding meaning beyond the bare 'string' type. This fully clarifies both parameters, making it easy for an agent to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press a key') and the resource (browser), with concrete examples (Enter, Tab, Escape, ArrowDown). It distinguishes itself from typing or clicking by focusing on key presses, which is clear from the context of siblings like browser_type and browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the ref vs focused-element behavior, which is useful context. However, it does not explicitly state when to prefer this tool over alternatives like browser_type or browser_click, nor does it mention any scenarios where it should not be used. The guidance is implied but not explicit.
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?
No annotations are provided, so the description carries the burden. It clarifies that only visible text is returned and that the tool is scoped to content reading rather than structure, which is useful. However, it does not disclose potential truncation behavior, performance implications for large pages, or error behavior when an element ref is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action is stated first, and the alternative tool guidance is appended as a clear second sentence. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two optional parameters, the description covers the main purpose and use case. But without an output schema or annotations, it should at least mention the role of maxChars and maybe the return format. The tool is usable as-is, but an agent would have to infer or guess about maxChars.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It explains 'ref' as a way to target one element, but 'maxChars' is not mentioned at all, leaving its purpose, constraints, and default behavior undocumented. This is a meaningful gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('visible text of the page or one element by ref'), and explicitly distinguishes it from browser_snapshot. This makes the tool's purpose unambiguous and easily separable from its 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'Use for reading article/content' and names the alternative: 'use browser_snapshot for interactive structure.' This directly helps an agent choose between two similar browser inspection tools.
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?
No annotations are provided, so the description carries the full burden. 'Search' unambiguously implies a read-only operation, and 'local workflow memory' suggests no side effects. However, it doesn't state whether the search is non-mutating explicitly, but the verb strongly implies it, so a 4 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and timing, then enriched with concrete examples. Every word earns its place, and it is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the search returns (e.g., a list of saved workflows, steps, or memory IDs). It also omits how the limit parameter affects the result and what the agent should do with the matches. This is a critical gap for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents all four parameters. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'local workflow memory', and explicitly differentiates from siblings by instructing to use it BEFORE multi-step tasks. It gives concrete examples of target sites, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit 'when to use' guidance with a clear trigger condition (multi-step or repeated tasks on changing sites) and instructs to use it first. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.
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?
No annotations are provided, so the description carries the full burden. It discloses key traits: real OS event vs synthetic, macOS-only, and cliclick dependency. However, it omits operational details like macOS Accessibility permissions, focus requirements, or error behavior when cliclick is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with zero waste: core purpose front-loaded, then usage guidance and dependency. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when-to-use, platform, and dependency. However, with no output schema and no annotations, it fails to disclose the return value or failure modes (e.g., what happens if cliclick isn't installed or if the OS blocks the event).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only count has a description; x and y are bare). The description adds meaning to x/y via 'absolute screen coordinates', clarifying the coordinate system. But it doesn't specify coordinate origin, units, or range, and button is only self-documenting via its enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (click), resource (absolute screen coordinates), and method (REAL OS mouse event). Clearly differentiates from browser_click by emphasizing the 'REAL OS mouse event' and 'absolute' coordinate system, which sets it apart from its 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to prefer browser_click and use this only for trusted clicks or native chrome. Also states the platform constraint (macOS only) and the prerequisite (brew install cliclick), leaving no ambiguity about when to select this tool.
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?
No annotations exist, so the description carries the full burden. It discloses the real OS event nature, coordinate computation, window raising, exact vs approximate behavior on Firefox/Chrome, iframe limitations, macOS dependency, and the need for cliclick + Accessibility. This is thorough and goes beyond what the schema offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but dense. Each sentence adds value: purpose, method, platform specifics, prerequisites. It's front-loaded with the core use case. Slightly longer than needed but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (real OS click, platform differences, external dependencies), it covers the essential context: why use it, limitations, prerequisites. It doesn't describe return values or error conditions, but no output schema exists. Overall, it's fairly complete for a niche tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only allowApproximate has a description). The description adds context for allowApproximate (explains why approximate and when to set it) but gives no meaning for ref, count, or button. Since these parameters are undocumented in both schema and description, the description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Click), resource (page element by ref), and method (REAL, OS-trusted mouse event). Clearly distinguishes from synthetic clicks and implies why this tool exists. It also names platform-specific behavior, which sharpens 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: for elements that ignore synthetic clicks, and notes macOS-only with cliclick + Accessibility permission. It doesn't name the alternative (browser_click) but strongly implies it. It also gives a condition for Chrome (approximate coords, must set allowApproximate) and warns about iframes.
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?
With no annotations, the description carries the full burden. It clearly indicates a read-only operation with no destructive side effects, which is valuable. However, it does not disclose edge-case behavior such as what happens when the clipboard is empty, contains non-text content, or requires user permissions in the browser 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The primary action is front-loaded in the first sentence, and the second sentence provides practical usage guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is nearly complete. It states what the tool reads and when to use it. It could slightly improve by noting the return value explicitly (e.g., 'returns the clipboard text'), but 'Read text from the system clipboard' sufficiently implies the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter documentation, but none is needed; the invocation is fully determined by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Read text') and a precise resource ('the system clipboard'), and the qualifier 'text' distinguishes it from sibling tool browser_clipboard_read_image. An agent can immediately understand what this tool does and how it differs from nearby clipboard 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear, concrete usage contexts: after a page places text on the clipboard via a copy button, or when moving data between pages and apps. It lacks an explicit exclusion statement (e.g., 'use browser_clipboard_read_image for images'), but the text-focused wording and sibling naming make the intended use clear.
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?
No annotations are provided, so the description carries the full burden. It discloses the error condition (errors if no image) and the output format (PNG/JPEG), but it does not specify how the image is returned (e.g., base64 string, binary data, or file path). Since there is no output schema, this ambiguity could cause the agent to mishandle the result. A read-only tool with no side effects is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose and an example. Every word contributes value; there is no redundancy or filler. It is optimally sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers the core purpose, usage scenario, and error behavior. However, it omits the exact return representation (PNG/JPEG encoding), which is a gap for an agent needing to process the result. Given the simplicity, this is a minor but notable omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing to explain. The baseline for 0 parameters is 4, and the description does not attempt to add parameter semantics because none exist. It correctly omits any param-related text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads an image from the system clipboard and returns it as PNG/JPEG. It includes a concrete example ('Copy image') and distinguishes itself from sibling tools like browser_clipboard_read (which likely handles text) and browser_clipboard_write_image (which writes images). The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage scenario ('after a Copy image action') which helps the agent know when to invoke it. It does not explicitly list alternatives or when-not-to-use, but the example and the tool name make the intent clear. This is sufficient context without needing exclusions.
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?
With no annotations provided, the description carries the full burden. It states that the tool lists dialogs and how they were auto-answered, which implies a read-only operation, but it does not explicitly disclose that it is non-destructive or whether it consumes or resets the dialog queue. The word 'List' helps, but more explicit safety/behavioral notes would strengthen it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence stating the core function, followed by a brief use-case sentence. No wasted words; it is concise and immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description should hint at the return value. It says 'List ...' which implies an array of dialog entries with their auto-answer status, but it does not specify the exact structure. For a simple listing tool this is likely sufficient, though a bit more detail on the return shape would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the description need not explain parameter meaning. Baseline 4 applies; the description adds no parameter information, which is appropriate since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('native JS dialogs (alert/confirm/prompt)'), clearly distinguishing it from sibling tools like browser_native_dialog or browser_set_dialog_policy. It also states the purpose ('to see if the page asked something'), making the tool's 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Use this to see if the page asked something') but does not explicitly mention when not to use it or name alternative tools. It gives context for when to use, which is adequate, though not exhaustive.
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?
With no annotations, the description carries full burden. It discloses key behaviors: no OS dialog, returns local path, and saves to downloads folder. It does not cover potential failure modes (e.g., invalid URL, network issues) or behavior on timeout, but the core behavioral traits are clearly stated and do not contradict anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The most critical information (no dialog, returns path) is front-loaded, followed by use cases. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with three parameters and no output schema, the description covers the essential purpose, use cases, and expected outcome. It does not address error handling or edge cases, but those are not critical for an agent to invoke the tool correctly in typical scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema; it does not clarify parameter usage further (e.g., how filename interacts with the downloads folder). The use-case mention is helpful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: downloading a file to disk without the OS save dialog and returning its local path. It distinguishes itself from sibling tools like browser_save_pdf by focusing on URL-based downloads and explicitly mentioning the dialog bypass, which is unique. The use cases (PDFs, exports, attachments) further clarify intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on when to use the tool ('Use for PDFs, exports, attachments') and explains the outcome (file lands in downloads folder). However, it does not explicitly contrast with alternatives like browser_downloads_list (for listing downloads) or browser_save_pdf (for saving the current page), leaving some inference to 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?
With no annotations provided, the description carries the behavioral transparency burden. It does well by stating that it 'Fires both HTML5 drag-and-drop and a pointer-drag sequence,' explaining how it handles both native and JS-library targets. It could add more about side effects or timing, but the core behavior is well 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences, front-loaded with the core action and examples, followed by the mechanism detail. Every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter action with no output schema, the description is largely complete: it names the source and target, gives use cases, and explains the dual-input strategy. It does not explain how refs are obtained, but the schema names them and the tool fits into a broader browser toolset where refs are a standard concept.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both fromRef and toRef clearly described as 'Ref of the element to drag' and 'Ref of the drop target.' The description adds no extra semantic detail 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Drag one element onto another,' and lists concrete real-world scenarios (kanban cards, sortable lists, file tiles, sliders). This clearly distinguishes the tool from sibling actions like browser_click, browser_hover, and browser_scroll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool through example use cases. It does not explicitly name alternatives or exclusion conditions, but the drag-specific purpose is unambiguous, and no sibling tool is dedicated to dragging.
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?
With no annotations, the description carries the full burden. It discloses important behavioral traits: atomicity, the security policy of not accepting/returning secret values, and conditional filling of username. It does not mention error behavior, side effects like navigation, or what happens on failure, which leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the main action and includes a critical security constraint. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the key aspects: what it does, security constraints, and parameter behavior. It omits failure handling and return value expectations, but for a login automation tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context: explains that secret is a vault alias (not the value), that refs come from browser_snapshot, and that username_ref is only used when the secret contains a username. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: atomically fill username/password fields and submit the login form. It clearly distinguishes from siblings like browser_fill_secret and browser_fill_form by focusing on the login flow with a server-side secret alias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: pass only refs and the secret alias, and notes that secret values are never accepted as input. However, it does not explicitly exclude alternatives or state when not to use this tool, so it lacks explicit when-not 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?
With no annotations provided, the description must carry the full behavioral burden. It discloses the platform restriction, permission requirement, and the nature of actions (list, click, type). However, it doesn't disclose potential side effects, failure modes, or whether operations are reversible. For a tool that can click and type in system dialogs, this is a notable gap, though the description does add some useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed paragraph that front-loads the core purpose and then details actions, platform, and permission. Every sentence earns its place, with no fluff or repetition. The structure is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description covers the essential aspects: what it does, when to use it, what actions are available, and environmental constraints. It doesn't explain return values or error handling, but for a tool that primarily performs side effects, this may be acceptable. The lack of output schema means the agent can't know what to expect, but the description gives enough to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%), so baseline is 3. The description adds value by explaining the meaning of each action and providing concrete button label examples ('Open', 'Save', 'Don't Save'). It also clarifies the 'text' parameter is for set_text. This goes beyond the schema's sparse field descriptions, enriching the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: it inspects or operates native browser dialogs (file picker, print, auth popup, leave page). It explicitly lists the actions ('list', 'click_button', 'set_text') and gives examples. It also distinguishes itself from siblings by noting these are dialogs 'no extension can touch', implying other tools (like browser_dialogs) are for page-level dialogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool: for native dialogs that extensions can't touch. It also specifies platform (macOS only) and permission requirement (Accessibility). It doesn't explicitly name alternative tools for exclusion, but the 'no extension can touch' phrase implies a distinct usage scenario. This is adequate guidance without naming siblings.
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?
With no annotations provided, the description must carry the burden of behavioral disclosure. It does so by stating it uses 'REAL OS keystrokes' (bypasses DOM events), targets the currently focused element (not a selector), requires macOS and Accessibility permission, and only works when in-page typing fails. This is substantial transparency. It doesn't mention error handling or blocking behavior, but the critical constraints are 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The first sentence states the core function and its distinguishing feature (REAL OS keystrokes). The second sentence gives the when-to-use, prerequisite, and platform requirement. All essential information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, usage condition, prerequisite, and platform constraint. However, it omits any explanation of the 'modifiers' parameter, which is a required part of the input schema (though not required, it's optional). For a tool that types OS-level keystrokes, modifiers are a common need (e.g., typing Ctrl+A). The lack of this information means an agent might call the tool with incorrect or missing modifier syntax. Additionally, it doesn't specify what happens on failure (e.g., if permission is denied), but that's minor compared to the parameter gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. While 'text' is implicitly described as the content to type, the 'modifiers' parameter is completely ignored. An agent has no idea what values to pass (e.g., 'ctrl', 'shift') or how they affect the keystrokes. This is a significant gap for a tool whose schema provides no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Type text using REAL OS keystrokes into whatever currently has focus.' It clearly distinguishes itself from in-page typing (likely browser_type) by emphasizing OS-level keystrokes and the isTrusted condition. This leaves 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use only when in-page typing fails because the element checks event.isTrusted.' It also gives a prerequisite ('Focus the field first') and a platform constraint ('macOS only'). This is clear guidance that prevents misuse and routes the agent away from normal typing tools.
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?
With no annotations provided, the description carries the full burden. It discloses the dialog-free behavior and the caveat about Firefox builds, and specifies the output destination. However, it does not mention failure modes, return values, or whether the file is overwritten, leaving some behavioral ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and destination, then a concise fallback instruction. No fluff or redundancy; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core behavior, output location, and a relevant alternative. It omits return value and error handling, but these are arguably implicit for a save operation. Given no output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter ('Optional output filename.') at 100% coverage, and the description adds no additional meaning or constraints. The baseline of 3 applies since the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Save'), resource ('current tab as PDF'), destination ('downloads folder'), and behavior ('dialog-free'), clearly distinguishing it from browser_screenshot (image) and browser_download (generic). It is immediately obvious 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit use case ('capture a rendered page') and names a concrete alternative (browser_native_dialog) for a specific condition (if a save dialog appears), giving clear guidance on when to use this tool vs. another.
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?
With no annotations, the description carries the full burden. It discloses that the action 'appends a local tombstone' and that 'normal recall will stop returning that memory', which is valuable behavioral context beyond a simple 'remove'. It does not mention reversibility or permissions, but the tombstone detail is a strong transparency addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The core purpose is front-loaded, and the behavioral disclosure is appended concisely. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the purpose and the tombstone effect. It does not describe the return value, but that is minor for a deletion action. The lack of an explicit alternative routing is a small gap, but overall it is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (id and reason) are already documented in the schema. The description does not add meaning beyond what the schema provides; the id example in the schema is actually more specific. Baseline 3 is appropriate when the schema covers parameters thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('workflow memory by id'), and specifies the id-based targeting. It is easily distinguished from sibling tools like browser_workflow_recall and browser_workflow_remember by the verb 'forget', so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool (stale, sensitive, or incorrect memory) but does not explicitly mention alternatives or state when not to use it. The 'stale, sensitive, or incorrect' phrasing implies a conditional use case, but no exclusionary guidance is given.
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?
With no annotations, the description must carry the burden. It discloses content restrictions and the act of saving, but does not mention side effects (e.g., whether it overwrites, returns an ID, or requires prior verification). It is adequate but not fully transparent about what happens on save.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The primary purpose is front-loaded, followed by concise content rules. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and high schema coverage, the description covers the core purpose and content constraints well. It doesn't explain return values or error behavior, but for a save tool with no output schema, that is minor. The guidance about what not to store is valuable and the overall definition is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds semantic guidance (e.g., store durable UI labels, avoid transient refs) that aligns with parameter descriptions like 'selectors' and 'steps'. This enriches meaning beyond the schema, justifying a score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Save' and the resource 'verified reusable workflow', with context of 'after discovering or completing a browser task'. It is immediately distinct from sibling tools like browser_workflow_recall (retrieve) and browser_workflow_forget (delete), and 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use (after discovering or completing a task) and provides explicit negative guidance (do not store passwords, one-time codes, or transient refs). It does not name alternative tools or explicitly say when not to use, but the context is clear enough for a save operation.
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?
With no annotations, the description carries the full burden. It discloses that right-click opens context menus, modifiers enable multi-select and open-in-new-tab, and double-click is supported. It does not describe error handling or return values, but it goes beyond the schema by explaining the effects of parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then capabilities. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should mention what it returns, but it does not. It also omits error conditions or prerequisites beyond referencing the latest snapshot. For a simple click operation, it covers the main usage but misses return value and edge cases, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all four parameters, so the baseline is 3. The description adds value by explaining the effect of modifiers (multi-select, open-in-new-tab) and the right button (context menus), which is not in the schema. This elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (click), the resource (an element identified by its ref from the latest snapshot), and distinguishes itself from siblings like browser_hover and browser_drag by focusing on clicks. It also mentions supported button types and modifiers, clarifying its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates it is for clicking elements by ref from a snapshot, which is the primary click mechanism for DOM elements. It does not explicitly state when not to use it or name alternatives like browser_os_click, but the context implies it for ref-based clicks.
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?
With no annotations, the description carries the full burden. It discloses key behaviors: the tool arms answers, scopes to the secret's domains, never accepts or returns the credential value, and must be called pre-navigation. It does not mention failure modes (e.g., missing alias) or the exact behavior when 'once' is not set, but the essential security properties and invocation timing are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. The core purpose is front-loaded, followed by a security constraint and a direct usage instruction. It is optimally concise while conveying all necessary operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and no annotations, the description covers purpose, security, scoping, and timing. It does not describe return values (likely none) or error handling, but these are not critical for an agent to invoke it correctly. The absence of a return description is acceptable given the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'secret' and 'once'. The description adds value by reinforcing that 'secret' is an alias, not a value, and that the credential value is never accepted or returned. This goes beyond the schema's 'Secret alias from the server-side secrets vault.' The 'once' parameter is already well-described in the schema, so the description does not need to expand on it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Arm answers for HTTP basic-auth prompts' using a server-side secret alias. It clearly distinguishes the tool from siblings like browser_fill_secret (which would input credentials directly) and browser_clear_http_auth by emphasizing the alias-only approach. The scope ('scoped to that secret's domains') adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear when-to-use instruction: 'Call before navigating to the protected URL.' It implies the alternative (not calling leads to a native dialog) but does not explicitly name sibling alternatives or conditions for when not to use. The security-focused phrasing ('never accepted as input or returned') implicitly contrasts with tools that accept credential values, but a direct comparison is 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?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait—refs become stale after navigation/DOM updates—and implies the tool is a read-only snapshot. It could mention more about output format or side effects, but it covers the critical behavior for correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a conditional are tightly packed with useful information. The core purpose is front-loaded, followed by usage guidance and a cross-tool hint, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter, no output schema, and no annotations. The description explains what the tool returns (structured tree with refs) and when to use it, which is sufficient for an agent to call it correctly. It doesn't detail the tree structure or maxNodes default, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter (maxNodes) is already described in the schema. The description adds no extra meaning or context about how maxNodes affects the snapshot, so it stays at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures an accessibility/DOM snapshot as a structured tree and introduces stable [ref=eN] handles. It distinguishes itself from siblings like browser_screenshot (visual capture) and browser_read_text (text extraction) by focusing on the interactive element tree with handles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'USE THIS to understand the page before acting' and instructs to re-run after page changes because refs become stale. It also gives a conditional to call browser_workflow_recall when workflow-memory hints appear, providing clear when-to-use and alternative routing.
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?
With no annotations, the description carries full weight. It discloses the OS-level side effect (foregrounding), the platform limitation (macOS), and the dependency on the bridge connection. For a zero-parameter tool, this is sufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the action and includes all necessary context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple action, the description is complete. It states what it does, when to use it, and the platform constraint. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and schema coverage is 100% (empty schema). The description adds no parameter details, but none are needed. The baseline for zero-parameter tools is 4, and the description does not introduce any ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (bring to foreground), the resource (the connected browser), and the specific browsers supported. It is unambiguous and distinct from all sibling tools, which handle tabs, navigation, or OS input differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the purpose ('so OS-level input lands in it') and imposes a platform constraint (macOS only). While it doesn't explicitly name alternatives, the unique function makes usage context obvious. No exclusions are needed beyond the platform note.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool sends a desktop notification, returns a message to relay, and instructs the agent to stop and wait. It also warns against bypassing CAPTCHAs. This is transparent about the blocking nature and expected workflow, though it doesn't detail failure modes or user-inactivity handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the core purpose, then details the behavior, and ends with a critical safety directive. Every sentence adds value, and the most important guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is complete. It covers when to use it, what the tool does, what the agent should do afterward, and a prohibition on bypassing CAPTCHAs. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both 'reason' and 'message' with clear descriptions and examples. The tool description adds no additional parameter-specific meaning beyond what the schema provides, so it meets the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to hand control to a human for actions automation cannot or should not perform, listing specific examples (CAPTCHAs, anti-bot walls, 2FA, judgment calls). It distinguishes itself from sibling browser tools by focusing on human intervention rather than direct automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it (CAPTCHAs, anti-bot walls, 2FA, judgment calls) and includes a strong directive to not attempt bypassing CAPTCHAs, implying alternatives are not appropriate. It also tells the agent to STOP and wait, providing clear operational 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?
With no annotations provided, the description carries the full burden. It discloses that the tool sets the input's files directly or simulates drag-and-drop when no file input is found, and explains the hidden input detection in snapshots. It doesn't mention potential side effects like change events or failure modes, but for a browser automation tool it covers the key behaviors well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but every sentence adds value: the warning is front-loaded, then the ref explanation, then the modes. It is well-structured and not redundant. Could be tightened slightly, but the density of useful information justifies its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a specialized browser automation tool, the description covers the essentials: how to locate the input, what to pass, and the two modes. It even includes a warning about the picker. No output schema exists, so return values are not expected. It is fairly complete 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented in the schema. The description adds value beyond that: it explains that 'ref' can be a file input, upload button, or dropzone, and that hidden inputs appear in snapshots. It also clarifies the 'drop' mode for dropzones. This goes beyond the schema's simple descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: attaching local files to a page without using the OS picker. It uses a specific verb 'Attach', identifies the resource 'local file(s) to the page', and includes a critical warning about not clicking elements that open the picker. This clearly distinguishes it from sibling tools like browser_click or browser_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: when to use it (to upload files), how to find the ref (including hidden inputs appearing in snapshots), and the two modes (auto vs drop). It also warns against clicking elements that open the picker, which is essential for correct usage. No alternatives are named, but the tool's specialization is clear from the context.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool reports available capabilities and setup needs, which implies a read-only status operation. However, it does not explicitly state it has no side effects or is non-destructive, though 'Report' strongly suggests a safe inspection. This is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the tool's function and the second gives usage guidance. Information is front-loaded with the capability list, and every word adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool reports and when to use it, but does not describe the output format or provide details on how the report is returned (e.g., a list, a boolean per capability). For a status tool, the core use case is covered, but a bit more on the expected response would improve completeness. However, given the tool's simplicity and the lack of an output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 properties). The description adds no parameter-specific details, but none are needed. With no parameters, a baseline of 4 is appropriate, as the description correctly focuses on behavior and usage rather than parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Report') and resource ('OS-level input capabilities'), listing the exact capabilities (trusted keystrokes, native-dialog control, raw clicks). It also explicitly differentiates itself from the browser_os_* and browser_native_dialog tools by positioning itself as a prerequisite check, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs the agent to 'Check this before relying on the browser_os_* / browser_native_dialog tools,' providing a clear when-to-use condition. This also implies when not to use it (when not relying on those tools), giving the agent direct guidance on selecting this tool versus its siblings.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool is disabled by default and how to enable it, and details environment-specific execution differences (Firefox sandbox vs Chrome page realm with CSP and observability). This goes well beyond a simple 'run JS' and prepares the agent for 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence carries essential information: purpose, operational constraints, environment differences, and usage guidance. It is well-structured and front-loaded with the core action, though it could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic eval tool with no output schema, the description covers the key operational and environmental aspects. It explains how to return data and notes platform differences. Minor omissions like error handling or return format are acceptable given the tool's flexibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'code' parameter with 100% coverage. The description adds a valuable usage hint: 'use `return value;` to return data,' which clarifies how to extract results. This supplements the schema without redundancy, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Run JavaScript in the page and return the result.' It also distinguishes itself from the many sibling tools by explicitly saying 'Use only when no dedicated tool fits,' making it clear this is a fallback for custom scripting not covered by other 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use only when no dedicated tool fits.' It also explains the operational prerequisite (disabled under hardened mode, enabled via UBA_STRICT_SECRETS=0), which is critical for an agent to know before attempting invocation. This is clear and actionable.
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?
With no annotations provided, the description carries the full burden. It discloses the capture scope (visible part of the active tab) and output format (PNG). For a read-only operation this is sufficient, though it could mention potential failure cases (e.g., inactive tab) or that it does not capture off-screen content. Still, it adds value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both purposeful. The first states the action, the second gives the usage condition. Front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is complete: it defines what it captures, the format, and when to use it. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. Baseline for 0 params is 4, and the description correctly omits parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: captures a PNG screenshot of the visible part of the active tab. It also distinguishes itself from browser_snapshot by explicitly noting when the snapshot is insufficient, making its purpose clear relative to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use only when the snapshot is insufficient' with concrete examples (canvas, charts, visual layout). This implies when not to use it (when snapshot suffices) and effectively routes the agent away from the default snapshot tool.
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
Copy to your README.md:
Score Badge
Copy to your README.md: