Local Browser MCP
Server Quality Checklist
Latest release: v0.3.0
- Disambiguation4/5
Most tools have clearly distinct purposes (navigation, interaction, reading page state, tabs, dialogs). A few pairs like browser_snapshot vs browser_get_text and browser_type vs browser_fill could cause confusion, but descriptions clarify the differences.
Naming Consistency4/5All tools share the browser_ prefix, but the pattern mixes verbs (browser_reload), verbs with objects (browser_get_text), and nouns (browser_console, browser_tabs). This is mostly predictable but not perfectly uniform.
Tool Count2/5At 27 tools, the set is over the 25-tool threshold for appropriateness. While each tool serves a distinct function, the granularity could be consolidated (e.g., combine type/fill or console/network into single tools).
Completeness4/5The server covers navigation, interaction, page reading, tab management, dialogs, downloads, and permissions, making it quite complete. Minor gaps like cookie/localStorage handling are absent but not critical.
Average 3.8/5 across 27 of 27 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 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?
With no annotations available, the description carries the full burden of disclosure. It only restates the basic action without detailing side effects, error conditions (e.g., no forward history), or what happens after navigation. This lack of transparency is a gap for a tool that modifies 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, well-structured sentence with no redundant information. It is concise and directly states the purpose, earning every word with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is minimally adequate but lacks additional behavioral context, such as return values, state changes, or failure modes. It does not address what happens when there is no forward history, which could be useful for the agent. Overall, it is sufficient for basic use but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making schema coverage 100% vacuously. The baseline for 0 params is 4, and the description does not need to add anything about parameters. There is no ambiguity or need for further explanation.
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 'Navigate forward in history' clearly states the tool's action (navigate) and its scope (history), effectively distinguishing it from sibling tools like browser_back and browser_navigate. It is specific enough to be understood, though slightly terse.
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 mention of when to use this tool versus alternatives such as browser_back or browser_navigate. No context or exclusions are provided, leaving the agent without guidance on selecting it over other navigation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains what conditions are waited for but omits critical details such as what happens on timeout (e.g., error thrown), default timeout behavior, or whether the tool returns a value. This leaves the agent uncertain about failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and contains no unnecessary words. However, it is terse to the point of omitting important details, so it loses a point for sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should compensate by explaining behavior, parameters, and results. It only covers basic purpose, leaving the agent without enough information to predict outcomes or handle errors, making it incomplete for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must clarify parameters. It loosely maps selector to visibility, text to appearance, and timeoutMs to 'short delay', but it does not explain how these parameters interact, which are mutually exclusive, or the format of selector/text. This is insufficient for a 3-parameter tool with no 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 uses a specific verb 'Wait' with clear resources: selector visibility, text appearance, and short delay. It distinguishes itself from sibling browser actions like click, hover, and navigate, making the tool's purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for synchronizing or delaying actions, but it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions or prerequisites. The intended context is inferable but not 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?
With no annotations provided, the description carries full responsibility for disclosing behavioral aspects. It states the effect (fill) but does not mention whether this triggers events, replaces existing content, or handles missing selectors. It lacks any safety or side-effect information, which is significant for a mutation 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 sentence that is front-loaded with the verb and resource. Every word contributes to understanding, with no unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only two string parameters, and the description covers the core behavior. However, given no annotations and no output schema, it leaves out behavioral context such as return values, error handling, or event triggering, making it only moderately complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameters. The description clarifies that 'selector' is a CSS selector and 'value' is the value to fill, adding meaning beyond bare parameter names. However, it does not provide additional details like value format or selector syntax nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fill') and the target resource ('input/textarea identified by a CSS selector'), making the tool's purpose unambiguous. It does not explicitly differentiate from sibling tools like browser_type, but the verb 'fill' and target element type provide reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting form field values but does not provide explicit guidance on when to choose this tool over alternatives such as browser_type or browser_click. There are no when/when-not or alternative mentions, so it falls to the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies the behavior of resizing the viewport, but does not disclose side effects, units, or whether it affects the current page only or persists across navigations. The basic operation is transparent, but lacking richer details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words or filler. It is appropriately sized for the tool's simplicity, front-loading the core function perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the description provides the core function but leaves gaps such as units and behavioral side effects. It is reasonable for a basic resizing operation, but not fully complete for an agent that may need to know whether a reload occurs or what happens to the page state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate by explaining units (e.g., pixels), constraints, or the meaning of width/height beyond their names. The parameter names are self-evident, but critical semantic details are missing.
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 'Resize the page viewport' clearly states a specific verb and resource, distinguishing it from sibling tools like navigate, click, or screenshot. The scope is precise, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context such as emulating different screen sizes or responsive design testing. The description simply states the action without any situational or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides only the basic action. It does not state what happens when there is no history, whether the page state is preserved, or any side effects of going back.
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 four-word sentence with no filler or repetition. It is appropriately sized for such a simple operation.
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 trivial tool with no parameters, the description is minimally adequate but lacks behavioral context such as failure modes or state changes. Since there are no annotations or output schema, a few extra details would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100%, so the baseline is 4. The description adds nothing about parameters, but none 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 clearly states the tool's action: navigating back in browser history. It uses a specific verb ('navigate back') and resource ('history'), distinguishing it from siblings like browser_forward and browser_navigate.
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 offers no guidance on when to use this tool versus alternatives. It does not mention browser_forward for forward navigation or browser_navigate for direct URLs, leaving the agent without exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only says that text is typed; it does not mention whether existing text is replaced, whether it executes after a delay, or what happens with special characters. There is also no mention of return values or 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 a single, compact sentence that front-loads the action and target. It contains no redundant or vague wording, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the core behavior is covered. However, it lacks guidance on focus prerequisites, the distinction from browser_fill, and handling of special keys. This makes it minimally complete but not fully self-sufficient given the large sibling context.
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?
With schema description coverage at 0%, the description must compensate. The phrase 'Type text' clarifies that the 'text' parameter is the string to be typed, which is helpful. However, it adds no details about accepted formats (e.g., newlines, key names) beyond the schema's generic string type.
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 ('Type'), a resource ('text'), and a specific target ('currently focused element'). This differentiates it from sibling tools like browser_fill (which fills form fields) and browser_press_key (which sends key combinations). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after focusing an element, but it does not explicitly state when to use it over alternatives like browser_fill or browser_press_key. No when-not conditions or alternative tool references are provided, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose potential side effects, such as whether removal errors on missing hosts or affects the current page. It only states the core action without edge-case behavior or persistence details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One clear, single-purpose sentence. No redundant wording, front-loaded action, and fully readable at a glance.
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 single-parameter mutation tool, the description sufficiently conveys the purpose and parameter. However, it omits behavior for invalid hosts or persistence, which would be expected in a more complex tool. Given the low complexity, it is mostly 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?
With 0% schema description coverage, the description adds that 'a host' is the parameter to remove, but it lacks format details (e.g., domain vs. URL). It compensates minimally over the schema which only lists 'host' as a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a host from the navigation allowlist.' It uses a specific verb ('Remove') and a specific resource ('navigation allowlist'), distinguishing it from sibling tools like browser_allow_host.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a host should no longer be navigable, but it does not explicitly state alternatives or exclusion criteria. Sibling tools like browser_allow_host suggest the opposite operation, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the literal action and does not clarify nuances like what 'visible' means, whether it waits for page load, or if there are any side effects. Minimal behavioral context is added beyond the function itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. Every word contributes to understanding the tool's purpose, making it perfectly concise.
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 zero-parameter tool with no output schema, the description adequately conveys what is returned. It could be strengthened by explicitly stating the return type (e.g., string) or behavior regarding dynamic content, but the current description is sufficient for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is complete and the description need not elaborate on parameter syntax or meaning. Per the rubric, a baseline of 4 is appropriate for a no-parameter tool, and the description does not need to add anything further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Return') and resource ('visible text content of the page body'). It effectively distinguishes from sibling tools like browser_screenshot (visual capture) and browser_navigate (URL change), so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is a read-only operation or contrast with browser_snapshot or browser_eval, leaving the agent without explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'recent' but does not clarify the time window, ordering, limits, whether it logs all frames/types, or whether it clears the log. This vagueness leaves important behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the verb and resource, then packs the output fields into a parenthetical list. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's zero-parameter complexity and lack of an output schema, the description sufficiently communicates the return content. However, it omits expected details like whether the list is sorted, what 'recent' means, or if it covers only the current page. These gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which gives a baseline of 4. The description adds no parameter details, but none are needed since the input schema is empty and there is nothing to clarify.
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 'Return' with a clear resource ('recent network requests') and enumerates the exact fields returned (method, url, status, resourceType). This makes the tool's purpose immediately clear and distinguishes it from sibling tools like browser_screenshot or browser_console.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or what context it applies to (e.g., current page, session, or navigation). The description only states what it does, not when to call it. With no alternative network inspection tool among siblings, some usage context would help.
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?
There are no annotations, so the description carries the full burden. It only states the basic action without disclosing any side effects, prerequisites, or behavior on invalid indices. The reference to browser_tabs is helpful but does not reveal what happens after switching (e.g., return value, focus changes).
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 one concise sentence that is front-loaded with the verb and object. Every word is necessary and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description points to browser_tabs for obtaining the index, which is a key piece of context. However, it lacks any mention of error handling or what happens on invalid indices, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for 'index', and the description only says 'by index' plus '(see browser_tabs)'. This implies the index is from browser_tabs but does not explicitly state whether it is 0-based or how it maps to tab positions, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Switch' and the resource 'active tab', and specifies the method 'by index'. It also references browser_tabs, which distinguishes it from other tab-related tools like browser_new_tab or browser_close_tab.
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 by stating 'by index (see browser_tabs)', which tells the agent to first obtain the list of tabs from browser_tabs. However, it does not explicitly mention when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states what is returned. It does not disclose whether the buffer is cleared after retrieval, whether messages are scoped to the current page, or any side effects, which is a significant gap for a potentially stateful 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 sentence, front-loaded with the action and resource, and contains no unnecessary words. It is appropriately sized and instantly scannable.
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?
Since there is no output schema, the description should explain the return format. It mentions message types but not the structure (e.g., array of strings vs. objects), timing, or empty state, making it incomplete for an agent to reliably consume the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema covers everything. The description adds no parameter semantics, but per the rubric, a baseline of 4 applies when no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return'), the resource ('buffered console messages'), and the specific types ('log/warn/error') captured from the page. This distinguishes it from sibling tools like browser_network (network logs) and browser_get_text (page text).
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 does not explicitly state when to use this tool or offer alternatives/exclusions. While the name and content make it obvious for console debugging, there is no guidance on when to prefer it over browser_network or browser_snapshot, leaving usage implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 disclosing behavior. It accurately describes the capture action and the trade-off between jpeg and png formats, but it does not mention the return format (e.g., base64) or any potential side effects or limitations. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences that efficiently cover the purpose, options, and format guidance without any redundant phrases. The core action is front-loaded, making it easy to understand quickly.
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 features but leaves some gaps: it does not explicitly state whether fullPage and selector are mutually exclusive, nor does it describe what the tool returns (which is important given the absence of an output schema). For a tool with four optional parameters, this ambiguity reduces completeness.
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 low (only quality is described), but the tool description compensates by explaining the meaning of key parameters: 'optionally full page or a single element' clarifies the roles of fullPage and selector, and the format discussion explains the format parameter. This adds meaningful context beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Capture a screenshot of the current page', clearly stating the tool's primary function. It also mentions optional full-page or single-element capture, which distinguishes it from sibling browser tools that do not offer screenshot capabilities.
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 explicit guidance is provided on when to use this tool compared to alternatives like browser_snapshot or other sibling tools. The only usage advice concerns format selection (jpeg vs png), which is parameter-level advice, not tool-selection guidance. Thus, the description lacks clear context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 that the tool returns dialogs and their handling status, but does not mention potential side effects, whether it waits, or if it consumes/clears dialog state. This is adequate but minimal.
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 conveys all necessary information without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema), the description covers the core behavior adequately. However, it omits return format details and usage context, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the empty schema provides 100% coverage. Per the guidelines, baseline for 0 params is 4. The description adds no parameter information, but none is 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 uses a specific verb 'Return' and identifies the resource as 'JS dialogs' with explicit types (alert/confirm/prompt/beforeunload). This clearly distinguishes the tool from sibling browser tools and unambiguously states its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as browser_set_dialog_behavior. It is purely factual and gives no context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool targets elements via CSS selector or snapshot reference and performs a hover action, which is the core behavior. However, it does not mention any side effects, waiting behavior, or failure modes. For a simple hover tool, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the action, targeting methods, and an example. Every word earns its place, with no redundant information or structuring issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, no annotations, and absence of an output schema, the description is reasonably complete. It explains what it does and how to specify elements. It lacks details about return values or error handling, but for a hover action this is a minor 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 has zero description coverage, but the description explains that 'ref' refers to a snapshot reference and 'selector' refers to a CSS selector. This adds meaning beyond the raw parameter names. It does not detail precedence or constraints, so it is moderate but helpful.
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 ('Hover the mouse over an element') and the two targeting methods ('by CSS selector or snapshot ref'). This distinguishes it from siblings like browser_click or browser_fill. The example 'e.g. to open a dropdown menu' reinforces its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example use case ('to open a dropdown menu') which implies when to use it, but does not explicitly mention alternative tools or when not to use it. This is more than no guidance but less than explicit differentiation, so a score of 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes how to identify the element, but discloses no behavior such as waiting, error handling, side effects, or return values. For an interaction tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the verb and resource, with no filler. Efficiently communicates the core function.
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 click tool with only two optional parameters and no output schema, the description is minimally adequate. However, it leaves open questions about return values, waiting behavior, and failure handling, which are relevant in a browser automation context.
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 description explicitly explains the meaning of both parameters ('CSS selector' and 'ref from browser_snapshot'), compensating for the 0% schema description coverage. However, it does not clarify precedence or exclusivity between the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Click an element') and specifies two identification methods (CSS selector or ref from browser_snapshot), distinguishing it from sibling tools like browser_hover and browser_fill.
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 implies clear usage context for clicking an element, but does not explicitly mention when not to use it or compare with alternatives. The context is evident enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Reload the current page' describes the core behavior but does not mention side effects like discarding unsaved state or whether the tool waits for the page to load. It is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no wasted words. It says exactly what is needed and nothing more.
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?
Given the tool's extreme simplicity (no parameters, no output schema, no annotations), the one-sentence description fully covers what the tool does. There is no missing information that would affect an agent's ability 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?
The tool has zero parameters, so the description has no parameter details to add. The schema already covers the empty input, and the baseline of 4 for zero-parameter tools 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 uses a specific verb 'reload' and a clear resource 'current page', which immediately distinguishes it from sibling tools like navigate, back, and forward. It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While the usage is straightforward, there is no explicit context to help an agent decide between this and potentially similar actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that user approval is required and that a boolean return indicates grant status. This adds meaningful behavioral context beyond the schema, though it could mention side effects or error cases.
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, front-loaded with the primary purpose, and contains no filler. Every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple one-parameter permission tool: it explains the action, user interaction, and return value. Lacking explicit side-effect details or usage context, but overall complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter already well-described as a hostname. The tool description repeats the example 'github.com', adding no significant 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 clearly states the tool's function: requesting permission to add a host to the navigation allowlist. It specifies the resource (host) and distinguishes it from related tools like browser_disallow_host and browser_list_allowed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a host needs to be allowed, but does not explicitly state when to use this tool versus alternatives like disallow_host or list_allowed. No exclusions or 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 provided, so the description carries the full burden. It explains the action and gives examples, but does not disclose potential side effects like triggering navigation or page reloads, or how invalid keys are handled. This is adequate but has gaps for a keyboard action 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 two concise sentences: the first clearly states the action with examples, the second gives practical use cases. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is nearly complete. It includes examples and use cases, and sibling names provide context. It could mention that the key press applies to the current page/focused element, but this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already describes the key parameter with the same examples as the tool description. The description adds usage context but no additional parameter syntax or format details beyond what the schema provides, 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 the verb 'Press' and the resource 'a key or chord on the keyboard', with concrete examples (Enter, Tab, Control+A). This distinguishes it from sibling tools like browser_click (mouse) and browser_type (text input).
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 'Useful to submit forms or navigate without a mouse', giving clear use cases. While it doesn't name specific alternatives, the context implies when to choose this over mouse-based tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses two behavioral traits: the default action when no index is given and the fact that it returns the updated tab list. However, it omits important edge-case behaviors such as whether the index is zero-based, what happens on an invalid index, or whether closing the last tab terminates the browser. These gaps prevent a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core action and the parameter, the second sentence describes the return value. There is no redundant or filler language, and the front-loading is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter tool, the description covers the main behavior and return value, which is helpful since there is no output schema. However, it leaves out practical details such as indexing convention (zero-based vs one-based) and error handling for out-of-range indices. These are relevant in a browser automation context, making the description not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a property name 'index' with a type number and zero documentation. The description adds key meaning: the index identifies which tab to close, and omitting it means the active tab is closed. This explains the parameter's role and optionality, going well beyond the bare 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 starts with a specific verb and resource: 'Close a tab by index'. It clearly distinguishes this tool from siblings like browser_tabs, browser_switch_tab, and browser_navigate by focusing on the closing action. It also clarifies the default behavior when no index is given, which further sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to close a tab, optionally specifying an index. It also explains the behavior when no index is provided ('or the active tab'), which is practical usage guidance. It doesn't explicitly name alternatives or exclusions, but the purpose is so distinct from siblings that the context is clear without them.
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 present, so the description carries the full burden. It discloses key behaviors: creates a new tab, optionally navigates to a URL, makes it active, and returns the updated tab list. This is adequate for a simple operation, though it lacks edge-case details like error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no filler. Every word earns its place.
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?
Given the tool's low complexity (one optional param, no output schema), the description fully covers purpose, behavior, and return value. It is complete for an agent to select and invoke 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 coverage is 0% for the single 'url' parameter, so the description must compensate. It says 'optionally navigating to a URL', clarifying that URL is optional, but does not explain format requirements or what happens if omitted (implied blank tab). This is minimal but functional.
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 action: 'Open a new tab' with optional URL navigation and activation. It distinguishes from siblings like browser_navigate (likely navigates current tab) and browser_switch_tab (switches existing tab) by specifying new tab creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you want to create a new tab. However, it does not contrast with alternatives like browser_navigate or browser_switch_tab, so there is no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the confirmation prompt on non-local pages, which is useful, but it doesn't warn about potential side effects of executing arbitrary JS or what happens if the expression throws. The safety behavior is only partially addressed.
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, front-loaded with the core purpose, then a conditional caveat. No unnecessary words or repetition.
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-parameter tool with no output schema, the description covers the essential points: what it does, the result format, and a key conditional behavior. It doesn't mention error handling or side effects, but given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 0%, the description explicitly defines the single parameter 'expression' as a JavaScript expression to be evaluated in page context, and clarifies that the result must be JSON-serializable. This compensates well for the lack of schema 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 uses a specific verb ('Evaluate') and clearly identifies the target ('a JavaScript expression in the page context') and the output ('return the JSON-serializable result'). This is unambiguous and distinguishes it from sibling tools like browser_console or browser_get_text.
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 implies usage: use when you need to run JavaScript in the page and get a serializable result. It also gives context about non-local pages prompting for confirmation, but doesn't explicitly contrast with 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the allowlist validation, but doesn't explain what happens on rejection, whether it waits for page load, or any error handling. This is partial disclosure but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb, no filler. Every word contributes meaning (action, target, constraint). Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter navigation tool with no output schema, the description covers the core action and key constraint. It could mention post-navigation behavior (e.g., waiting for load) but overall is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'url' parameter (100% coverage), so baseline is 3. The description adds the key constraint that the URL must be a local dev URL and subject to the allowlist, providing valuable context 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 uses a specific verb 'Navigate' with the resource 'browser' and clearly specifies the URL type ('local dev URL') plus the allowlist validation. This clearly distinguishes it from sibling tools like browser_reload or browser_back.
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: it is for navigating to local dev URLs, with an implicit exclusion of non-allowlisted URLs. However, it doesn't explicitly name alternatives or state when not to use this tool, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It clearly states the tool returns a list of allowed hosts and a boolean indicating whether all hosts are allowed, which fully describes its observable behavior. It does not reveal potential side effects, but none are implied for a list 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 sentence that is direct and informative. Every word contributes value, and it is fully front-loaded with the action and subject.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and no output schema, the description is complete. It explains both the primary output (list of hosts) and the additional flag (whether all hosts are allowed), leaving no ambiguity about what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is no need for parameter explanations. The description focuses on the output rather than inputs, which is appropriate. The baseline of 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('hosts the browser may navigate to') plus the additional detail about whether all hosts are allowed. This clearly distinguishes it from sibling tools like browser_navigate (which performs navigation) and browser_allow_host/browser_disallow_host (which modify the allowed hosts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking the current allowed-host configuration but does not explicitly state when to use it versus alternatives. It does not mention exclusions or compare with browser_allow_host/browser_disallow_host, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the snapshot is 'flat' and includes tag, role, text, and ref, which is helpful. However, it does not mention potential side effects, timing, or whether the snapshot represents the full page or a viewport, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the resource and content, the second gives a direct usage instruction. Every word adds value, with no redundant 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 zero-parameter tool with no output schema, the description provides all essential context: what is returned, the fields included, and how to use the result. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the baseline rule, a score of 4 is appropriate. There is no parameter information to add beyond the empty schema, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a flat accessibility/DOM snapshot with specific fields (tag, role, text, ref), and ties it to element targeting. It explicitly mentions using the returned ref with browser_click, distinguishing it from sibling tools like browser_get_text.
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: use it for element targeting and pass the returned ref to browser_click. It does not explicitly list exclusions or alternatives, but the guidance is sufficient for a zero-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates a read-only 'list' operation and discloses the exact data returned (index, url, title, active status). It does not explicitly state the absence of side effects, but the verb 'list' strongly implies no mutation, which is sufficient for a simple 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, front-loaded sentence. Every element is useful: the verb, the resource, and the parenthetical list of return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description completely covers what an agent needs to know: what the tool does and what information it will receive. It is self-contained and sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by explaining the output shape, which is the most relevant information for invocation and interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('open tabs'), and adds specificity by enumerating the included fields (index, url, title, active). This unambiguously distinguishes it from sibling tools like browser_new_tab, browser_switch_tab, and browser_close_tab.
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 by the name and description: it lists tabs so an agent can see what's open and which is active. However, it does not explicitly state when to use this over alternatives, nor does it note that the returned index can be used with browser_switch_tab or browser_close_tab. This is minimal viable guidance but leaves the agent to infer the use case.
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 burden of behavioral disclosure. It clearly conveys a read-only list operation and discloses the scope ('during this session') and the exact data returned (url, filename, saved path). While it does not mention edge cases like 'no downloads' or 'list reset behavior', the simple nature of the tool makes this acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and object, then adds the return fields in parentheses. Every word earns its place; there is no redundancy or fluff.
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?
This is a low-complexity tool with no parameters and no output schema. The description fully specifies what it does, the session scope, and the composable return fields. There are no gaps in its context 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?
The tool takes zero parameters, so the description does not need to explain parameter meanings. The baseline for 0-parameter tools is 4, and the description appropriately focuses on behavior rather than arguments.
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') with a clear resource ('files downloaded during this session') and specifies the return fields (url, filename, saved path). This clearly distinguishes it from all browser siblings, none of which deal with downloads.
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 tool's purpose is self-evident: use it to see files downloaded during the current browser session. There are no alternative tools among the siblings for this function, so explicit when-not-to-use guidance is unnecessary. The context is clear, and no exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the default behavior ('accept'), the alternative ('dismiss'), and an important edge case ('beforeunload is always dismissed'), providing useful behavioral context beyond a simple statement of functionality.
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 action and includes all necessary details without redundancy.
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 one-parameter setter with no output schema and no annotations, the description is sufficiently complete. It covers the purpose, the parameter values, the default, and a critical special case, leaving no significant ambiguity for the agent.
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 only lists an enum with no defaults or explanations. The description compensates by explaining that 'accept' is the default and 'dismiss' is the alternative, and clarifies the beforeunload behavior, adding 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 uses the specific verb 'Set' and identifies the resource 'JS dialogs' and the two behaviors ('accept' or 'dismiss'). It clearly differentiates from sibling tools like browser_dialogs (which likely reads dialogs) by focusing on auto-handling configuration.
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 that this tool configures auto-handling of JS dialogs, implying usage when such behavior needs to be controlled. It does not explicitly mention alternatives or exclusions, so it lacks the explicit guidance of the highest tier.
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:
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/NolanLT/local-browser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server