pony-browser-mcp
Server Quality Checklist
Latest release: v1.0.1
- Disambiguation4/5
Most tools target clearly distinct actions or resource types, and the descriptions heavily cross-reference when to prefer one alternative over another (e.g., browser_set_date vs browser_fill, browser_drop_file vs browser_upload_file). The main ambiguity risk comes from the cluster of click variants and form-input tools, but the descriptions do enough to disambiguate them.
Naming Consistency4/5The browser_ prefix and snake_case style are consistent, and most names follow a verb_noun pattern. A few exceptions like browser_screenshot, browser_console_logs, browser_clipboard_stats, and browser_about deviate from the verb-first convention, creating minor inconsistency.
Tool Count2/545 tools is well above the 25+ threshold for 'too many' and will create real selection overhead for agents. While browser automation is a broad domain, the surface could likely be consolidated or split into focused servers.
Completeness4/5The toolset is remarkably comprehensive, covering navigation, interaction, forms, files, dialogs, tabs/windows, frames, network, storage, clipboard, and user-in-the-loop flows. Minor gaps exist—such as explicit back/forward/reload navigation and delete-cookie/clear-storage operations—but most workflows can still be completed through workarounds.
Average 4/5 across 45 of 45 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool navigates to a settings page and reads a token, but it does not mention side effects like leaving the current page, authentication requirements, or behavior when the provider is not supported or not logged in.
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 action and purpose are front-loaded, and it earns its place by stating both what happens and why.
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?
With no output schema, the description should clarify what the tool returns or whether it only navigates and leaves reading to the agent. It also omits prerequisites like authentication. For a tool that extracts a token, this is a meaningful gap.
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 fully describes the single 'provider' parameter with 100% coverage. The description adds minor context by tying the provider to its API settings page, but it does not significantly extend the schema's meaning. Baseline 3 is appropriate.
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 action ('navigate to a provider's API settings page') and the intended outcome ('read its API token from the page'). This clearly distinguishes it from generic sibling tools like browser_navigate, though it could be more explicit about whether the token is returned directly or just made available on the page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as browser_navigate, browser_get_page_content, or browser_fetch. The intended use is inferable from the name and description, but no conditions, prerequisites, or exclusions are provided.
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 only says 'Get cookies' and does not reveal the return format, whether cookies include httpOnly or session cookies, how domain matching works, or whether this operation has any side effects on browser state.
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 that states the operation and its scope without any filler. It is appropriately sized for a tool with only one parameter.
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 is simple, but with no annotations and no output schema, the description should at least indicate what the returned cookies look like or that the operation returns a list. As written, it leaves the agent to infer the result format and any domain-matching behavior, which is a meaningful gap.
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 input schema fully documents the single 'domain' parameter with an example, and schema description coverage is 100%. The description adds no meaningful semantic detail beyond saying the domain is specific, so it remains at the baseline for a fully documented parameter.
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', the resource 'cookies', and the scope 'for a specific domain'. It distinguishes this tool from browser_set_cookies and all other browser tools by its read-only retrieval 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?
The description gives no explicit guidance on when to use this tool versus alternatives, such as browser_set_cookies or other browser utilities. The intended use is implied by the tool name and simple verb, but no conditions, exclusions, or prerequisite steps are stated.
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 only states the action and does not mention whether existing cookies are overwritten, how defaults like secure or sameSite behave, or whether the cookie persists beyond the current session.
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, direct sentence with no filler, front-loading the key action and scope. It is appropriately concise for the primary purpose statement.
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 9 parameters, no annotations, and no output schema, the description is under-specified. It omits how to use the bulk 'cookies' parameter, the relationship between url and domain, default flag behavior, and any side effects or prerequisites.
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 9 parameters. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline of 3 for full schema 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?
The description clearly states the verb 'set', the resource 'cookies', and the scope 'for a domain'. It also explicitly covers both single and bulk operations ('one or more cookies'), which distinguishes it from the sibling browser_get_cookies without needing inference.
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, such as browser_set_local_storage or browser_get_cookies. No prerequisites, timing, or exclusion conditions are mentioned, so the agent must infer the appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 explaining behavioral traits. It only states that content is returned as text or HTML, but does not disclose whether the page may execute scripts, how it handles dynamic content, or any side effects. It lacks detail beyond the basic 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, clear sentence with no wasted words. The verb and object are front-loaded, and the format options are stated efficiently. It is appropriately sized for the tool's simplicity.
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-only-like tool with full schema coverage, the description adequately states the output, but it lacks usage context and behavioral nuances such as when to use the debugger fallback or how 'current page' is resolved in multi-tab scenarios. No output schema exists, so the description should carry more detail about return values and edge cases.
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 documents all three parameters. The description adds no new meaning beyond what the schema already provides, matching the baseline 3. The mention of text/HTML repeats the format enum without additional semantic 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 states a specific action ('Get'), a clear resource ('content of the current page'), and output options ('text or HTML'). It is unambiguous and distinguishes itself from sibling tools like browser_screenshot, browser_get_cookies, or browser_fetch, which serve 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?
The description provides no guidance on when to use this tool over alternatives, nor does it mention any conditions or exclusions. It simply describes what the tool does. No sibling comparison or contextual trigger is given, leaving the agent to infer when this tool is 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that the tool shows an overlay and returns user responses, but it does not mention that the tool likely blocks execution until the user responds or times out, nor what happens if the user dismisses the dialog. This is useful but incomplete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. Three sentences cover the core purpose, typical use cases, input-field capability, and return behavior without redundant wording or unnecessary detail.
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 is adequate for a straightforward interactive tool, but it lacks explicit detail about blocking behavior, timeout semantics, and the exact structure of returned responses. Since there is no output schema, a bit more clarity about the response shape and cancellation behavior would make the tool fully self-contained.
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 description coverage is 100%, so the parameters are already well documented. The description adds general context about input fields and responses but does not add meaningful detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as showing an overlay dialog to request user action or information, with a specific list of use cases like credentials and 2FA. It is clear enough to distinguish from sibling tools such as browser_handle_dialog, though it does not explicitly contrast itself with related tools like browser_solve_captcha.
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 the tool: whenever the browser automation needs input from the human user. However, it provides no explicit guidance about when not to use it or which sibling tools might be better alternatives, such as using browser_solve_captcha for automated CAPTCHA handling instead of asking the user.
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 does disclose the primary behavior: waiting for an element to appear and supporting CSS/text selectors. However, it does not mention what happens on timeout, whether it waits for visibility vs existence, or what the return value/error behavior is.
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, focused sentence that front-loads the primary purpose and adds selector-type support without unnecessary detail. 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 two-parameter tool with a fully described schema, the description is largely adequate. Gaps remain around timeout behavior and return/error semantics, which an agent would need to know for robust invocation, but the core usage is clear.
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 input schema fully documents both selector and timeout. The description only restates selector types already present in the schema and adds no additional meaning beyond the structured definitions.
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 ('wait') and resource ('element to appear on the page'), clearly stating the tool's core action. It also distinguishes itself from the sibling browser_wait_for_network by focusing on DOM elements 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like browser_wait_for_network. The description implies usage ('when you need to wait for an element') but gives no exclusions or decision criteria.
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 carry the behavioral disclosure burden. It says what the tool does but not what side effects executing JavaScript may have, whether the frame context persists for later commands, or what the return value is. The name 'select_frame' also creates ambiguity about whether this is a temporary execution context or a persistent selection.
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, focused sentences with the primary action front-loaded and the prerequisite in the second sentence. No wasted words or redundancy.
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, the description plus schema covers the essentials. However, there is no output schema and no annotation safety profile, so the lack of any mention of return behavior or post-conditions leaves a minor but real gap.
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 input schema already fully documents both parameters, including the meaning of frame_index and the default behavior of code. The description adds a useful link to browser_list_frames but does not substantially expand parameter semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (execute JavaScript), a specific target (a specific iframe), and the selection mechanism (frame index). It distinguishes itself from the generic browser_execute_script sibling by scoping execution to a frame.
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 explicitly instructs the agent to call browser_list_frames first to find the right index, which is a concrete usage prerequisite. It does not enumerate alternatives or when not to use the tool, but the guidance is clear enough for correct invocation.
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 disclosure burden. It usefully discloses that the request runs from the extension background and is exempt from CORS/CSP restrictions. However, it does not mention response format, error behavior, authentication needs, or potential side effects of methods like POST/PUT, which would add meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The first sentence states the core behavior and the CORS exemption, the second gives the usage condition, and the third provides practical examples. Every sentence 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?
The schema fully documents the four parameters, and the description supplies the essential selection context. The main gap is the lack of return-value or error-handling details, especially since there is no output schema, but for a straightforward HTTP fetch tool the expected response is largely implied.
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 structured schema already documents url, body, method, and headers. The description adds no additional parameter-level meaning, but the fields are self-explanatory and the baseline of 3 applies because the schema handles parameter documentation.
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 verb and resource: 'Make an HTTP request from the extension background'. It also highlights the key differentiator, 'NOT subject to CORS', which distinguishes it from page-context fetch and other browser tools. It does not explicitly name a sibling alternative, but the purpose is clear and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: use this when page-context fetch would be blocked by CORS or CSP, and provides concrete examples like Google, Stripe, and Slack APIs. It clearly identifies the condition that selects this tool, even though it does not list alternative tools or exclusion cases explicitly.
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. 'Get' reasonably signals a non-destructive read, and the use-case context adds some value. However, it does not disclose the crucial behavioral detail of whether 'get' returns a tab reference for subsequent use or also activates/switches to the tab — a meaningful ambiguity given browser_switch_tab exists as a sibling.
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 the core action front-loaded ('Get the most recently opened tab') and the use case appended as a tight parenthetical. Every word earns its place; there is no filler, repetition, or schema echo.
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 tool this is mostly adequate — it covers what the tool does and when to use it. But with no output schema and no annotations, the description is the sole source of the return contract, and it leaves unspecified whether the result is a tab ID, a tab handle, and whether the active tab changes. Some guidance relating it to browser_switch_tab or browser_list_tabs would close the gap.
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 the description needs to explain about inputs. The description adds useful context about what the returned entity represents (the most recently opened tab) and when the call is relevant, which is more than the empty input schema alone could convey.
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 verb and resource — 'Get the most recently opened tab' — and adds a concrete use case (links opening new tabs, OAuth popups). It is unambiguous about what is retrieved. However, it does not explicitly differentiate from closely related siblings like browser_switch_tab or browser_list_tabs, leaving the agent to infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical gives explicit usage context: 'useful after clicking links that open new tabs, OAuth popups, etc.' This tells the agent the trigger condition for choosing this tool. It stops short of naming alternatives or exclusions, such as pointing to browser_switch_tab for already-known tabs or browser_list_tabs for enumerating tabs, so it lacks the when-not guidance of 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?
With no annotations provided, the description carries the behavioral disclosure burden. It explains that the tool waits for the dialog and then accepts or dismisses it, which is the core behavior. However, it does not mention what happens on timeout, whether it returns any value, or how it interacts with the subsequent 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?
Two sentences with no redundancy. The first sentence states the resource and action; the second gives critical timing guidance and the wait behavior. Every sentence 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 low-complexity tool with three optional, fully documented parameters, the description covers the essential call pattern and behavior. It could be more complete about failure modes, but the current guidance is sufficient for correct invocation in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 all three parameters. The description adds little beyond naming prompt() dialogs, which aligns with the 'text' parameter, but it does not meaningfully enrich parameter understanding.
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 identifies the target resource as JavaScript alert(), confirm(), or prompt() dialogs and states the tool's behavior of accepting or dismissing them. It is distinct in the sibling list, though it does not explicitly name an alternative tool for contrast.
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 explicit timing guidance: call this BEFORE triggering the action that causes the dialog. It does not list exclusions or alternative tools, but the intended usage context is clear from the sibling set.
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?
Without annotations, the description carries the behavioral burden. It does disclose a key side effect, 'Creates the group if missing,' but it does not explain what happens to existing tabs, whether the operation is reversible, or what the result or failure behavior looks like.
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 short sentences, front-loaded with the primary action and immediately followed by the important create-if-missing behavior. There is no filler or redundant phrasing.
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 low-complexity tool with no output schema and aliased parameters, the description is largely complete: it explains the main action, the condition for creation, and the core input concept. The main gap is the lack of explicit when-to-use or alternative guidance, which is already reflected in the usage_guidelines score.
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 all parameters and their alias relationships. The description reinforces that a 'task name' is the input, but it does not add meaningful detail beyond 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 action and resource: 'Switch the active Chrome tab group to a task name.' It also clarifies the create-if-missing behavior, which distinguishes it from sibling tools like browser_switch_tab or browser_cleanup_workspace.
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 is implied: call this tool when you want the active Chrome tab group to correspond to a task name. However, it does not explicitly state when not to use it or mention alternatives such as browser_list_tabs or browser_switch_tab.
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 usefully explains that the handler wraps code in parentheses, that only expressions are allowed, and that top-level return is a syntax error. However, it does not mention that executing arbitrary JS can mutate the page, trigger navigation, initiate network requests, or that promise results and thrown errors need handling. These are material behavioral gaps for an unannotated execution 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?
Three sentences with high information density. The core function comes first, followed immediately by the two most critical pitfalls: parameter name and expression-vs-statement syntax. Every sentence earns its place, and the structure front-loads the most actionable guidance.
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 gives the essential invocation pattern but omits return-value semantics, error handling, async/promise behavior, and side-effect warnings. Since there is no output schema, an agent is left guessing whether the expression's result is returned directly, serialized, or wrapped. This is adequate for simple cases but not fully complete for a powerful, unrestricted script-execution 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 input schema already documents that `code` must be a JavaScript expression and recommends an IIFE. The description adds valuable semantics beyond the schema: the alias `script` is accepted, and the handler wraps code in parentheses, explaining why top-level return fails. This meaningfully helps an agent produce valid inputs.
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: 'Execute JavaScript in the current page.' This clearly distinguishes it from sibling browser automation tools, none of which execute arbitrary JavaScript. It is immediately obvious what the tool does even without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need to run JavaScript in the current page. However, it does not explicitly mention alternatives or when not to use it, such as preferring browser_fetch for network requests or browser_get_page_content for reading page state. The usage context is clear but not fully articulated.
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 of explaining behavior. It states that it presses a key and supports modifier keys, which is useful, but it does not disclose that the press targets the currently focused element, whether full keyboard events are dispatched, or what happens with invalid keys.
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 action and examples are front-loaded, followed by use cases and modifier support, so 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?
For a simple keyboard tool with full schema coverage, the description is mostly adequate, covering key examples and modifier keys. However, with no annotations and no output schema, it omits important invocation context such as the need to have the right element focused and what the tool returns or does on failure.
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 all parameters clearly. The description only repeats modifier support already visible in the schema and adds no deeper parameter 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 opens with a specific verb and object: 'Press a keyboard key', then lists concrete examples and use cases. This clearly distinguishes it from the many mouse-based sibling tools like browser_click, browser_hover, and browser_double_click.
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 it: submitting forms, navigating dropdowns, and closing dialogs. It does not explicitly state when not to use it or name alternative tools, but the use cases are enough to guide an agent.
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 of disclosing side effects. It does disclose the banner behavior and the CSP-related rationale, but it does not explain whether changing the option affects the current session, requires reconnection, or has other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main purpose is front-loaded, followed immediately by the decision-relevant guidance. 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 single-boolean session option with no output schema, the description is nearly complete: it explains the default, the banner effect, and when to diverge. It could mention whether this should be called before or after browser initialization, but that gap is minor for such a simple 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 schema already documents the parameter's basic meaning, and the description adds important semantics: the default value and the specific condition for enabling it. This goes beyond a restatement of the parameter description.
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 it sets session options and identifies the specific option (use_debugger). It is distinct enough from sibling browser actions because it addresses session-level configuration rather than navigation or interaction, though it could more strongly name itself as the only session-config tool.
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 explicit guidance on when to set use_debugger=true: only when scripting fails on CSP-strict sites, with false as the default to avoid the yellow banner. It does not explicitly discuss alternatives, but none are relevant given the unique purpose.
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 burden of exposing side effects. It openly states that tabs are closed, the Chrome tab group is removed, and a window can optionally be kept for reuse. It does not discuss irreversibility or no-match behavior, but the destructive nature is clearly disclosed.
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 and well-ordered: primary operation first, optional behavior second, extra cleanup capability third. It contains no filler, though the parenthetical 'removes the Chrome tab group' is slightly redundant with 'Close tabs'.
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 main operation, optional window behavior, and prefix-based junk cleanup, and the schema documents all parameters. However, all parameters are optional in the schema and the description never clarifies what happens if task is omitted or if no matching group exists; without an output schema or annotations, this is a small but real gap.
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?
All four parameters already have detailed descriptions in the schema (100% coverage), so the baseline is 3. The description adds a little context, such as 'about:blank for reuse' and 'junk cleanup', but mostly reinforces what the schema already states.
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 first sentence names the exact action (close tabs) and resource (task group / Chrome tab group), and the description clearly separates this from generic tab-closing tools. The optional window-keeping and junk-cleanup clauses further define the tool's 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 conveys when to use the tool: for cleaning up a task group's tabs, optionally preserving a reusable blank window, and removing leftover groups by exact title or prefix. It does not explicitly name alternatives or exclusions, such as using browser_close_tab for individual tabs, so it falls short of 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 the burden of behavioral disclosure. It adds one important behavior: session ownership limits which tabs can be closed. However, it does not mention what happens on success or failure, whether closing is irreversible, or whether the tab's resources are also released. For a destructive action, some additional context would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action is front-loaded, and the session ownership limitation is stated as a separate, important constraint. 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?
This is a simple single-parameter tool with no output schema. The description covers what the tool does and the key limitation an agent must respect. It is mostly complete for a focused close operation, though it could briefly note what happens when the tab ID is invalid or stale.
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%, and the tab_id parameter is already described clearly as 'Tab ID to close (get from browser_list_tabs)'. The description reinforces the parameter's role but does not add significant meaning beyond the schema. 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 states a specific action ('Close'), a specific resource ('a browser tab'), and the method ('by ID'). It clearly distinguishes this tool from siblings like browser_switch_tab and browser_list_tabs, so an agent can immediately understand its role.
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 makes the tool's purpose obvious: call it when a specific tab should be closed. It also provides a meaningful constraint: only tabs owned by the current session can be closed. It does not explicitly name alternatives or describe when not to use it, but the narrow scope makes the usage context 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 to lean on, the description does extra work by disclosing a side effect ('Installs a lightweight interceptor on first call') and the bounded nature of the result ('last N console messages'). This goes beyond a bare read-operation description, though it could clarify interceptor persistence or message format.
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 tight sentences with no filler. The primary action and resource appear first, followed by a critical behavioral caveat and a clear output summary.
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 one-optional-parameter, no-output-schema tool, the description covers the essential behaviors: what is returned, how many messages, and the install-on-first-call side effect. Minor gaps like exact message object shape or lifecycle of the interceptor are not blocking for correct 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?
The schema already documents the single 'count' parameter with default and meaning. The description adds no new parameter-level details, but that is acceptable because schema coverage is 100%, so it does not need to compensate for missing 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 uses the specific verb 'Get' with a clear resource: console.log/warn/error messages from the page. It is instantly distinguishable from all sibling browser tools, none of which target console messages.
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 the tool: whenever recent page console messages are needed. However, it gives no explicit when-not-to-use conditions or alternatives, relying on the agent to infer the use case from the tool's purpose.
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 key stateful behavior: create or reuse a dedicated window and persist/pass back window_id on later calls. However, it does not mention side effects on existing windows, what happens when the window is gone, or any permission/return details 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 compact sentence that front-loads the core purpose and then states the persistence behavior. Every clause earns its place with no 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?
The description plus schema covers the essential invocation details: URL, task binding, dimensions, focus, and window_id reuse. It could be more explicit about the return value/format, but 'pass back window_id on later calls' strongly implies the tool returns or exposes the window_id. Missing minor specifics about edge cases like a stale window_id, yet those are partially addressed in the 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 description coverage is 67%, and the description adds some meaning for window_id via 'Persist and pass back window_id on later calls.' It does not add semantics for width, height, or task beyond what the schema already provides, so it only partially enriches parameter understanding.
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 clearly states 'Create or reuse a dedicated Chrome window for agent work' and specifically calls out keeping tabs/groups off the user browsing window. This is a specific verb + resource purpose and effectively distinguishes this tool from the many browser interaction siblings.
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 for when to use the tool: when the agent needs its own dedicated Chrome window and wants to avoid polluting the user's browsing session. It does not explicitly name alternatives or state when-not-to-use, so it stops short of 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?
With no annotations, the description carries the behavioral burden. 'Read' communicates a non-mutating operation and 'from the current page' gives scope, but the description does not disclose return format, behavior for missing keys, or origin/security constraints. For a simple getter this is acceptable 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 two short sentences with no filler. The primary action is front-loaded, and the optional parameter behavior is explained immediately and clearly.
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 one optional parameter, no output schema, and no annotations, the description covers selection and invocation adequately. The only notable gap is the lack of explicit mention of return shape or missing-key behavior, but overall it is sufficiently complete for a simple localStorage reader.
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%, and the schema already documents the key parameter exactly as the description does. The description adds no new meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Read localStorage from the current page.' It is immediately distinguishable from sibling browser_set_local_storage because the verb 'Read' directly contrasts with 'set.' The optional-key behavior is also stated precisely.
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 clear context: reading from the current page, with 'Pass key for a specific value, or omit for all.' It does not explicitly name alternatives or exclusion criteria, but the read-vs-set distinction is obvious from the sibling set_local_storage 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?
No annotations are provided, so the description carries the behavioral disclosure burden. It does explain the visible effect of hovering and mentions selector support, but it does not disclose what happens if the selector matches nothing, whether the element is scrolled into view, or what the tool returns. These are notable gaps, though the core behavior is clear.
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 deliver the action, purpose, and selector support without unnecessary detail. The primary verb and intended use are front-loaded, making it easy for an agent to scan and understand.
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 combined with the schema is largely sufficient. It explains what the tool does and what the elements are, though a bit more detail about error behavior or post-hover state would make it fully 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 both parameters with 100% coverage: `selector` as 'CSS or text selector' and `duration` as 'How long to hold hover in ms'. The description mostly restates the selector information already present, and it adds no additional nuance about the duration parameter or how selectors are resolved beyond what the schema provides.
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 ('Hover') with a clear resource ('an element') and states the intended outcomes (`trigger tooltips, dropdown menus, or hover states`). This clearly differentiates it from sibling tools like browser_click, browser_double_click, and browser_right_click, which involve active input rather than hovering.
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 phrase 'to trigger tooltips, dropdown menus, or hover states' gives clear contextual guidance for when this tool should be used. It does not explicitly mention when not to use it or name alternative tools, but the hover-specific purpose is sufficient to guide selection among the browser interaction siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the output content (URLs and indices) and scope (current page), but it does not mention whether nested frames are included, ordering behavior, or that the indices are meant for later frame selection.
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?
One concise sentence with no filler. The core action, resource, and output fields are immediately available.
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 listing tool, this is mostly complete: it says what is listed and what is returned. Minor gaps remain around nested frame handling and the relationship to browser_select_frame, but they do not seriously impair usability.
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 of 4 applies since no parameter semantics are needed.
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 ('List'), a specific resource ('frames (iframes) in the current page'), and the returned data ('URLs and indices'). This clearly distinguishes it from sibling tools like browser_select_frame and browser_list_tabs.
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 this is a discovery step on the current page, but it does not explicitly say when to use it versus alternatives such as browser_select_frame. No exclusions or direct usage conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of disclosing behavior. It accurately describes the basic scrolling action but does not explain what happens if both selector and pixel coordinates are provided, or how scrolling interacts with the current scroll position. This leaves some behavioral ambiguity, though the core behavior is clear.
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 compact, front-loaded with the primary action, and includes only useful additional context. Both sentences earn their place, with no redundant wording or unnecessary detail.
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 low-complexity tool with optional parameters and no output schema, the description covers the essential invocation scenarios well. It explains both modes and gives a practical use case. The only minor gap is the lack of explicit guidance on parameter precedence, but this is unlikely to be critical for a scrolling action.
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 input schema already documents each parameter's meaning. The description adds a high-level mapping between 'element' and selector, and 'pixel amount' and x/y, but does not provide additional detail beyond what the schema already contains. A 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 states a specific verb ('scroll') and resource ('the page'), and clearly distinguishes two modes: by element or by pixel amount. It also adds a concrete use case ('reaching elements below the fold'), which makes the tool's purpose immediately identifiable among the sibling browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by explaining that scrolling is useful for reaching elements below the fold, which tells an agent when this tool is appropriate. It does not explicitly mention alternatives or when not to use it, but the tool's function is distinct enough among the siblings that this is not a major gap.
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 mutation and scope, but does not mention that existing values are overwritten, that localStorage persists, or that this depends on a valid same-origin page 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?
The description is a single active-voice sentence with no filler. The core information—action, resource, and scope—is front-loaded and 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 and schema cover the essentials. It could mention return behavior or error cases, but the operation is simple enough that the omission is a minor gap rather than a blocker.
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 input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds no extra meaning about key format, value serialization, or length constraints beyond what the schema provides.
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 concrete verb ('Set') with a specific resource ('localStorage key-value pair') and clearly scopes the action to the current page. It is immediately distinguishable from browser_get_local_storage and other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool should be used: writing a localStorage value on the current page. It stops short of explicitly naming the reading counterpart or stating when not to use it, so it lacks full routing guidance but is still unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It states the intended action but does not disclose what happens with an invalid tab_id, whether the browser window is brought to focus, whether the switch triggers navigation or reloads, or what the return behavior is. An agent has limited ability to predict side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the necessary source for the required parameter follows immediately.
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 tool with a fully described input schema, the description provides enough to make the call: what to do and where to get the ID. It could be improved by noting error behavior or return value, but the essential contextual requirements are covered.
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 documents tab_id as 'Tab ID to activate', and the description adds valuable provenance by telling the agent exactly where to get valid IDs. This extra context makes the parameter more actionable than the schema alone.
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 ('Switch') and the resource ('a specific browser tab'), along with the key requirement ('by ID'). This is distinct from sibling tools like browser_close_tab or browser_navigate, so 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent where to obtain valid tab IDs: browser_list_tabs or browser_get_new_tab. This establishes a clear precondition for use. It does not explicitly call out when not to use the tool or compare it against alternatives, but the usage context is clear enough.
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 mechanism (monitors real network traffic via Chrome DevTools Protocol) but leaves important behavior unclear: whether it waits for a single matching request or network idle, whether already in-flight requests count, and what happens on timeout or no match.
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 tight sentences: the core behavior, the typical use case, and the underlying mechanism. It is front-loaded, free of filler, and every sentence contributes useful 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?
For a two-parameter wait tool, the description is reasonably complete: it states the use case, the mechanism, and the matching concept implied by url_pattern. The remaining gaps around timeout/return behavior are real but minor, especially since the schema already defines a timeout.
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 timeout and url_pattern already documented. The description adds contextual motivation but no parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation — waiting for a network request to complete — and places it in a concrete scenario: after clicking buttons that trigger API calls, so data is loaded before reading the page. The 'network request' qualifier and CDP monitoring distinguish it from the generic sibling browser_wait even without naming it.
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 explicitly says when to use the tool: after click actions that trigger API calls, before reading page content. It does not mention when not to use it or name alternative tools, so it falls just short of full routing 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, the description carries the full burden and does well by disclosing the key behavioral guarantee: only the character count is returned, not the content, and it copies to the system clipboard. It also flags 'CSS selectors only' as a constraint. It does not mention clipboard overwriting or element-not-found behavior, but the most critical security-relevant behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the 'SECRET-SAFE' flag and the core behavior, followed by a concrete use case and constraint. The Azure example adds context and earns its place. It is slightly verbose in the second sentence, but every part contributes 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?
For a simple 2-param tool with no output schema and no annotations, the description is largely complete: it explains purpose, secret-safe behavior, return value (only character count), and parameter constraints. It does not describe error behavior or clipboard side effects beyond 'copy', but the described use case and output behavior are sufficient for correct 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 100%, so the baseline is 3. The description's main param-related addition, 'CSS selectors only', repeats the schema's own 'CSS selector' phrasing. It does not meaningfully extend beyond what the input schema already provides for either selector or attribute.
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 ('Copy') on a specific resource (an element's value/text or attribute) with a clear destination (system clipboard). It distinguishes itself from siblings like browser_get_page_content or browser_extract_token by explicitly stating content is NOT returned. The 'SECRET-SAFE' tag reinforces the unique 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?
The description gives a concrete use case ('credentials/tokens... Azure new client secret') and specifies when to choose this tool (when the value must move to a field or CLI without entering the conversation). It implies the alternative would be returning content to the conversation, but does not explicitly name alternatives or exclusion conditions.
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 safety burden. 'List' and 'Shows' imply a read-only operation, and the group names/colors detail signals the kind of output, but the description never explicitly states that it has no side effects or what it returns beyond groups/colors.
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 filler, front-loaded action and scope. Every clause adds useful information.
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 read-only listing tool with no annotations and no output schema, the description is slightly incomplete: it tells callers they will see tab group names/colors but not the full return shape (e.g., tab IDs, titles, URLs) that would let them chain into browser_switch_tab or browser_close_tab. Still, the operation is simple and the core behavior is clear.
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 documents workspace and all_workspaces at 100% coverage, so the baseline is 3. The description adds the 'active workspace' default, clarifying how the optional workspace parameter behaves relative to all_workspaces.
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 resource ('tabs'), specifies workspace scoping ('active workspace (or all workspaces)'), and adds a concrete output detail (Chrome tab group names/colors). No sibling tool claims the same listing function, so an agent can distinguish it readily.
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: by default it targets the active workspace, and callers can opt into all_workspaces. It does not explicitly exclude alternatives, but there is no sibling tab-listing tool to confuse it with; switching and closing tabs are clearly different operations.
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 behavioral burden and it does well by disclosing auto-scroll behavior, real mouse events, and compatibility with Angular/React SPAs and CSP-strict sites. It does omit details like handling of multiple selector matches or post-click waiting, but the disclosed behavior is meaningful.
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 dense sentences front-load the purpose and then convey selector syntax, behavioral traits, and compatibility examples with no filler. Every clause contributes to correct usage.
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 click tool with no output schema, the description is nearly complete: it tells the agent what selector syntax to use, that scrolling is automatic, and how the event is dispatched. It could be slightly more complete by noting what happens after the click (e.g., waiting or return value), but this is a minor gap.
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 covers the selector parameter at 100%, so the baseline is 3. The description adds value by giving concrete selector examples (#my-button, a.btn-primary, button:text(Get started)) and clarifying that CSS and text-based formats are supported, which aids correct parameter construction beyond the schema's description.
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 begins with a specific verb and resource — 'Click an element on the page' — and further specifies CSS/text selector support and worded examples. This clearly distinguishes it from sibling tools like browser_double_click and browser_click_xy, which involve different actions or coordinate-based clicks.
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 gives useful context such as auto-scrolling and real mouse events for SPAs/CSP sites, which implies when the tool is valuable, but it does not explicitly state when to use this tool instead of browser_double_click, browser_hover, or browser_click_xy. No exclusions or when-not-to-use guidance is provided.
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 that the tool is heuristic-based, how it locates close affordances, the effect of scope values (non_critical preserves form inputs, aggressive dismisses everything), and that it returns a list of what was dismissed. This is strong transparency, though it could have noted potential edge cases like shadow DOM or unclosable overlays.
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 compact and front-loaded: purpose, heuristic mechanism, usage examples, and return value are each covered in a few tight sentences. There is no filler or redundant restatement.
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 decision factors: what the tool does, when to use it, how it behaves heuristically, and what it returns. The main gap is not explicitly excluding native JavaScript dialogs, which could cause confusion with the sibling browser_handle_dialog, but overall an agent can 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 baseline is 3 and the schema already explains both scope and max_passes. The description adds useful context for max_passes ('some overlays reveal others when closed') and reinforces the scope trade-off, but it does not carry the parameter-documentation burden.
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 and resource: dismiss visible popups, modals, tooltips, banners, and 'Are you sure?'-style overlays in one call. The heuristic details (finding close affordances via aria-label, text, or ×) distinguish it from related siblings like browser_handle_dialog, which handles native 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?
Provides clear usage context: 'Use when a flow is interrupted by unexpected dialogs' with concrete examples such as cookie banners, onboarding tooltips, and Meta Ads draft-confirm prompts. It does not explicitly state when not to use it or mention alternatives for native dialogs, but the described conditions are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses the tab-group creation/use side effect, alias behavior, and dedicated-window separation. It does not mention whether navigation waits for page load or returns status, but those are conventional and less critical for a navigate 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?
Three sentences with no filler: the core action is first, then the non-obvious task-group behavior, then aliases and window handling. Every clause 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 7-parameter tool with no annotations and no output schema, the description covers the non-obvious interaction behaviors (tab groups, parallel task naming, dedicated windows). It does not explicitly discuss new_tab/new_window or how to obtain window_id via browser_ensure_window, though the schema covers those details.
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 the baseline is 3, but the description adds real value beyond the schema by explaining the task parameter's tab-group effect, the MUST-use-different-names constraint for parallel tasks, and the alias relationships. This materially helps an agent set parameters 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?
Opens with 'Navigate to a URL', a specific verb and resource, and the tab-group/window details make the tool's role unmistakable. It is easily distinguished from siblings like browser_fetch or browser_switch_tab because the core action is explicit.
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 clear guidance on task names for parallel tasks and window isolation, but it never names alternatives or states when not to use this tool. Selection guidance is implied by the tool name and 'Navigate to a URL' rather than explicitly contrasted with sibling tools like browser_fetch.
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 and does disclose the critical behavior: content never returns, only character count, and whitespace trimming default. It could add failure behavior but covers the privacy-relevant trait well.
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 short sentences, front-loaded with the most important safety trait and purpose, no 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?
Low-complexity 2-param tool with no output schema; description explains what comes back (only character count) and the default trim behavior, which is sufficient for correct invocation. Minor gap: no mention of failure cases, but not essential.
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 already documents selector and trim with 100% coverage; description reinforces the trim default and how to disable it but adds no meaning beyond schema. Selector semantics are self-explanatory in 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?
States a specific action ('paste system clipboard into a form field') plus its key privacy property and pairing with browser_copy_to_clipboard, so it is clearly distinguishable from fill/click siblings.
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 frames the use case: moving credentials between pages/apps alongside browser_copy_to_clipboard. It does not spell out when to prefer fill or other input methods, but the context is clear enough for tool selection.
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 behavioral burden. It discloses the multi-step approach: auto-click first, screenshot for AI vision, then ask the user. It also names supported CAPTCHA types and notes that it returns detection info and solving status. There is slight ambiguity around how the screenshot and user fallback flow between calls, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: it names the operation, lists supported CAPTCHA types, outlines the solving flow with a practical detail about Google sign-in, and states the return value. It is front-loaded and free of 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?
The description covers supported CAPTCHA types, the solving strategy, fallback behavior, and return value, which is strong given there is no output schema. It does not specify the exact shape of detection info or solving status, but the high-level description combined with the well-documented optional parameters is sufficient for an agent 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 explains both parameters and the action enum clearly. The tool description provides useful narrative context about solving strategy but adds no additional parameter-level meaning beyond what the schema already states.
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 'Detect and solve CAPTCHAs on the current page', clearly specifying the verb, resource, and scope. It names the specific CAPTCHA types handled, which differentiates it from every generic browser interaction sibling such as browser_click or browser_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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: whenever a CAPTCHA appears, and it explains the solving order from auto-click to AI vision to human fallback. It does not explicitly name alternatives or state when not to use it, but the specialized purpose makes the intended use obvious.
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 present, so the description carries the behavioral burden. It usefully discloses the main mechanism (Chrome Debugger API, no file dialog), but it does not mention side effects, whether the current input selection is replaced, event firing, or return behavior. Valuable 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?
Two tight sentences: the first states purpose and mechanism, the second routes to the sibling for the alternative case. Every sentence earns its place with no 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 straightforward file-upload primitive with full schema coverage and no output schema, the description gives the essential invocation context and the relevant alternative. It could mention return values or selection-replacement behavior, but nothing required to call and distinguish the tool is missing.
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 explains file, files, and selector. The tool description adds no parameter-level meaning, which is acceptable under the baseline for full schema 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?
Opens with a specific verb+resource: uploads a file to an input[type=file] element, and immediately differentiates from the drag-drop sibling. An agent can tell this from browser_drop_file without inspecting sibling schemas.
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 names browser_drop_file as the alternative and gives the condition that selects it (drag-drop zones without a visible file input). It also clarifies programmatic CDP upload, so the agent knows when this tool is intended.
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 reveals that the tool uses trusted CDP mouse events and that only in-page menus will work, while the native browser menu cannot be triggered via CDP. This is important, non-obvious context 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The core behavior is front-loaded, and the critical limitation is stated in the second sentence. Every word contributes useful information.
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 one-parameter action tool with no output schema and no annotations, the description is sufficiently complete. It explains the mechanism, the intended use case, and the key limitation. An agent has what it needs to decide whether to invoke this tool and what to expect.
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 single selector parameter is already described as 'CSS or text selector.' The description adds 'an element' but no additional syntax or selection guidance, so it does not significantly enhance the schema's 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?
Description clearly states a specific verb (right-click) and resource (element), and explains the intended outcome (opening page-level context menus). It distinguishes this action from plain click/double-click tools and clarifies the web-app vs. native-context-menu distinction.
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 conveys when the tool is useful: for in-page context menus rendered by web apps like OWA or Google Docs. It also explicitly warns that Chrome's native context menu will not open, which is a clear when-not-to-use signal. It does not name a specific alternative tool, but the limitation provides practical routing 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, the description carries the full behavioral burden. It discloses the search scope (subtree or parent up to 2 levels), what happens when no input is found (clear error), and the limitation for pure drop-zones. It could further clarify whether file and files are mutually exclusive or what happens on success, but the core behavior is well covered.
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 with no fluff: the action is front-loaded, the usage condition follows, and the failure/limitation is stated last. Every sentence 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?
The description covers the trigger scenario, search behavior, error case, and manual-handling limitation, which is sufficient for an agent to decide and invoke it. The only minor gap is the absence of success-return details, but there is no output schema to satisfy and the practical usage is clear.
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 baseline is 3. The description connects the selector to the drop-zone target and explains how the hidden input is located, which adds some context, but it does not substantially refine the meaning of file or files beyond their 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 mechanism — uploading via a hidden file input within a drag-drop zone — and names the exact condition that distinguishes it from browser_upload_file. This makes the tool's purpose immediately recognizable and differentiated from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: when browser_upload_file fails because the dropzone has no visible file input. It also gives a clear when-not-to-use hint by noting pure drop-zones without backing inputs require manual handling.
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 and it delivers meaningful behavior: auto-scrolling, focusing the element, and working on CSP-strict sites via the Chrome Debugger API. It doesn't mention potential side effects like overwriting existing values or triggering events, but the disclosed traits go well beyond a minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a one-line purpose, two capability notes, and a two-item routing sentence. Every sentence earns its place, and the core action is front-loaded before alternatives.
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 essential use context: why it exists, what behaviors it performs, technical limitations it handles (CSP), and alternatives for edge cases. Minor gaps like error behavior or event triggering are not critical for a fill operation, so this is almost fully 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?
Schema coverage is 100%, with both 'selector' and 'value' already documented. The description repeats the selectors info but adds little beyond what the schema states. Baseline 3 applies because the schema does the heavy lifting and the description does not materially enhance parameter understanding.
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 clear verb and resource: 'Fill a form input field with a value.' It explicitly differentiates from nearby siblings by naming browser_set_date for date inputs and browser_set_combobox for autocomplete/combobox controls, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit routing: 'For date inputs use browser_set_date, for autocomplete/combobox use browser_set_combobox.' It also clarifies the accepted selector types (CSS and text-based), helping the agent decide when this tool is appropriate. This is direct when-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses the default return value (base64 PNG), the conditional side effect (saves to disk if path is provided), and the viewport limitation. It does not mention edge cases like file overwriting or page-load timing, but these are minor for a low-complexity 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?
The description is a single sentence that front-loads the primary action, then packs the return format and optional side effect. No filler or redundant detail. 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 tool with one optional parameter and no output schema, the description is near-complete: it gives the action, result format, and the effect of the only parameter. It omits trivial details like exact PNG encoding or whether the path can be relative, but nothing essential is missing for an agent to invoke 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% and the schema already explains the 'path' parameter clearly. The tool description adds meaningful behavior beyond the schema: if path is provided it saves to disk; otherwise it returns base64. This conditional semantics is essential for correct invocation and is not stated in 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 action ('Take a screenshot'), a clear resource ('the visible area of the current tab'), and distinguishes itself from all siblings by being the only screenshot-related tool. It is unambiguous and immediately understandable.
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 clear usage context: use when you need a visual capture of the current viewport. It explicitly limits scope to 'visible area', which tells the agent this is not a full-page capture. However, it does not name alternative tools or state when not to use it, but no direct alternative exists among 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, the description carries the full transparency burden. It clearly discloses the internal interaction sequence: click, type query, wait for listbox, click option. It also notes configurable waiting behavior and multi-select. Minor omissions like whether existing selections are cleared before setting values keep it from a 5.
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 tightly worded sentences front-load the core action, then explain the internal flow, multi-select support, and when to use the tool. There is 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?
The description covers the operation's workflow, multi-select behavior, and the key alternative comparison. All six parameters are fully documented in the schema. The main gap is the absence of return-value or post-condition information, but that is minor for a UI interaction tool with no 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 description coverage is 100%, so the schema already documents every parameter fully. The description adds context about multi-select and the lazy-rendering use case, but does not add meaningful parameter semantics beyond what the structured schema provides. Baseline 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 names a specific verb+resource ('Set value(s) on an autocomplete/combobox input') and explains the exact multi-step flow it automates. It explicitly distinguishes this from browser_select_option, making its purpose and scope immediately clear.
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?
Usage guidance is explicit: 'Use when browser_select_option fails because options render lazily after typing.' This tells the agent exactly when to choose this tool over the closest sibling, and the multi-select example adds real 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, the description carries the behavioral disclosure burden. It clearly states that the tool returns info and pre-filled URLs, and it instructs the agent to 'offer' the submit_url rather than auto-submitting, implying a non-destructive informational operation. It could explicitly mention no side effects, but the behavior is transparent enough for this simple read-only 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?
Four sentences, each earning its place: purpose, proactive triggers, invocation guidance, and community context. The most important action-oriented content is front-loaded, and the trigger list is detailed without being bloated.
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 tool with zero required parameters, no output schema, and no annotations, the description is complete. It explains what the tool returns, when to use it, how to map user intent to parameters, and what to do with the result. 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.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already fully explains all three parameters, including intent enum values and URL-encoding behavior. The description restates the intent values and briefly contextualizes title/body as pre-filled content, but adds no substantive new meaning beyond 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 verb and resource: 'Returns Browser MCP info and pre-filled URLs'. It also clearly enumerates the distinct intents (wish, use_case, bug, info), which distinguishes this tool from all browser-interaction siblings in the list.
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 gives explicit, concrete conditions (a–d) for when to call this tool proactively, including example user phrases. It also tells the agent exactly what to do with the output: pass an intent plus optional title/body and offer the returned submit_url to the user.
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 disclosure burden. It reveals two important behavioral traits: 'raw viewport coordinates' (meaning no scrolling or element lookup) and 'fully trusted mouse events' (which bypass some event trust restrictions). It also warns about unusual cases like Azure portal dialogs, Knockout-bound divs, and canvas UIs. However, it does not mention edge cases such as coordinates outside the viewport or page movement after a screenshot.
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 zero filler. It front-loads the 'ESCAPE HATCH' label, then gives a crisp when-to-use and how-to workflow. Every sentence contributes purpose, usage context, or procedural guidance.
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 two-parameter tool with no output schema, this description is complete. It covers what the tool does, when to use it, how to get coordinates, and how to combine it with browser_screenshot. The omission of rare edge cases is acceptable because the tool is intentionally simple and the use case is clearly scoped.
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 has 100% coverage for both x and y, so the baseline is 3. The description adds value beyond the schema by explaining how to derive coordinates—'take a screenshot, read the button's position, click its center'—and explicitly emphasizing CSS pixel units and the viewport origin. This practical guidance helps the agent invoke the tool with meaningful inputs.
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 identifies the tool as an escape hatch that clicks at raw viewport coordinates in CSS pixels with fully trusted mouse events. It explicitly contrasts this with selector-based strategies, naming the exact resource and action, so an agent can distinguish it from browser_click and other sibling click 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 explicitly states when to use it: 'when a visible button resists every selector strategy' and provides a concrete workflow with browser_screenshot. It doesn't name the preferred alternative (browser_click) explicitly, but the 'escape hatch' framing and 'resists every selector strategy' strongly imply the fallback nature, which is enough guidance without being fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states that the tool is 'SECRET-SAFE' and inspects only the shape 'without exposing content,' which is critical behavioral context for a clipboard tool. It does not explicitly state that it does not modify the clipboard, but 'inspect' strongly implies a read-only 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 compact and front-loaded with the most important guarantee ('SECRET-SAFE'), followed by the precise list of returned metrics and a concrete usage example. Every part earns its place without unnecessary detail.
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 zero-parameter, no-output-schema tool, the description is complete: it names all returned fields, explains the safety behavior, and provides a realistic scenario for when to invoke it. An agent knows what it will receive and why this tool exists.
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 has zero parameters and schema description coverage is 100%, so there is nothing for the description to clarify about parameters. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the output shape instead.
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 identifies the tool's purpose: inspecting the clipboard's shape rather than its content, and lists the exact metrics returned (length, trimmed length, has_whitespace, looks_like_uuid, looks_like_url). It distinguishes itself from clipboard-related siblings like browser_copy_to_clipboard and browser_paste_from_clipboard by emphasizing that content is never exposed and only shape is inspected.
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 a concrete use case: verify a copy landed before pasting, with a helpful example distinguishing a ~40-char secret from a UUID. It implies this is the safe pre-paste check, though it does not explicitly name alternatives or state when not to use it.
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 behavioral burden and does well by explaining that this is a 'true' double-click involving two trusted press/release pairs and escalating clickCount. This adds meaningful detail beyond the tool name, though it does not mention potential side effects or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary action and behavioral detail, then immediately gives a concrete usage scenario. Every sentence 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one well-documented parameter and no output schema, the description provides everything an agent needs to decide when to use it and what it will do. The example and contrast with single-click behavior make the context 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 input schema already covers the only parameter, selector, with 'CSS or text selector', so schema coverage is 100%. The description adds no additional semantic detail about the selector format, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a genuine double-click on an element, using specific verbs and resource ('double-click on an element'). It distinguishes itself from sibling tools like browser_click and browser_right_click by describing the internal behavior of two trusted press/release pairs with escalating clickCount.
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 this tool: for open-item actions where two single clicks would trigger inline-rename instead, with the concrete OWA month view example. This effectively routes the agent to this tool rather than using browser_click twice or another click variant.
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 behavioral burden. It discloses the interaction sequence for custom dropdowns: clicks trigger, waits for options, then clicks matching option by text. This gives the agent a real sense of what the tool does beyond the schema. However, it does not describe the native <select> behavior or any side effects, leaving a small transparency 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 two sentences and every word earns its place. The core purpose is front-loaded, followed by the custom dropdown mechanics and the sibling tool alternative. There is no fluff, repetition, or unnecessary detail.
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 is well-rounded for a UI interaction tool: it explains the two supported modes, gives the interaction flow, and routes to the correct sibling for autocomplete. With a fully described schema and no output schema expected, the only missing piece is explicit detail on how native <select> elements are handled, which 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 the baseline is 3. The description adds value by explaining that the wait parameter is used after clicking the trigger for options to appear, and it reinforces that option is a partial-match text. This contextualizes parameters beyond the schema's individual descriptions, so a 4 is warranted.
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 'Select an option from a dropdown menu,' a specific verb and resource that immediately defines the tool's function. It also distinguishes this tool from browser_set_combobox by explicitly stating the autocomplete use case falls to that sibling. The scope is clear and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance by covering native and custom dropdowns, and states 'For autocomplete (typing filters options) use browser_set_combobox instead.' This provides a clear when-to-use and when-not-to-use with a named alternative. It leaves no ambiguity about the intended scenario.
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 disclosure burden. It clearly discloses the force-detach/re-attach behavior and the symptom it addresses. It could go slightly further by stating side effects on the current page or debugger state, but the core behavior is unambiguous.
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?
One dense sentence front-loads the action with a 'RECOVERY' label, then gives the exact failure mode and the alternative. Every clause earns its place with no repetition of the tool name or schema.
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 zero-parameter recovery tool with no output schema, the description supplies enough to call it correctly: what it does, when to use it, and why it beats the fallback. Nothing critical is missing at this complexity level.
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 schema coverage is complete and the baseline is 4. The description correctly focuses on the 'current tab' as the implicit target rather than inventing 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?
States a specific recovery action ('Force-detach and re-attach the Chrome debugger on the current tab') with a clear verb and resource. It also distinguishes itself from interactive browser tools by positioning itself as the recovery path when click/fill/press_key fail with ghost-attach.
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?
Gives an explicit trigger condition: interactive tools timing out or reporting 'Debugger attach failed ... ghost' while list_tabs still works. It names the practical alternative (reloading the extension) and explains why this tool is preferred ('faster'), so an agent knows when to pick it over alternatives.
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, the description carries the full behavioral burden. It discloses the fallback strategy in detail, including native value setting, format-aware typing via Input.insertText, ARIA-based picker navigation, and read-back verification. This is exceptional transparency for an unannotated 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 core purpose and followed directly by usage guidance. No filler, no repetition of schema content, and every phrase adds 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?
The description covers what the tool does, when to use it, and the internal fallback/verification behavior, which is enough for an agent to invoke it correctly. However, with no output schema, it does not explicitly describe return values or failure behavior, so a small gap remains.
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 provides 100% description coverage for all parameters, so the baseline is 3. The description adds value by explaining the strategy sequence, which clarifies what skip_picker=true actually avoids and how the date parameter is applied across different input types.
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: robustly set a date input, covering native, masked, and calendar-picker variants. It explicitly names browser_fill as an alternative, which distinguishes it from sibling tools without needing to inspect schemas.
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 on when to use this tool: 'Use instead of browser_fill when fill fails or for any input that opens a calendar widget.' This gives the agent a clear decision rule and names the alternative 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:
shields.io Endpoint
For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pssrh/pony-browser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server