bwb-browser
Server Quality Checklist
Latest release: v3.2.0
- Disambiguation4/5
Most tools target distinct operations (navigation, content extraction, interaction, tabs, cookies). Minor overlap exists between browser_status and browser_listTabs, and browser_act can serve as an alternative to click/fill/goto, but descriptions clarify boundaries.
Naming Consistency3/5All tools share a browser_ prefix, but the suffix style varies: verb-noun compounds (newTab, setViewport, waitForSelector), bare verbs (goto, click, eval), and bare nouns (html, title, url, status). This mix is readable but lacks a consistent verb_noun pattern.
Tool Count2/5At 26 tools, the server exceeds the 25+ threshold and feels bloated. The high-level browser_act duplicates many core interactions, and niche additions like fingerprint, diagnose, and watch expand the surface beyond essential browser control.
Completeness5/5The toolset covers the full browser lifecycle: navigation, tab management, content extraction, input, waiting, cookies/sessions, diagnostics, and restart. There are no obvious dead ends, and browser_eval provides an escape hatch for any missing operations.
Average 3.8/5 across 26 of 26 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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, the description must disclose behavioral traits, but it only states 'execute JavaScript'. It fails to mention whether the execution is synchronous, what happens to return values, security implications, or potential side effects (e.g., DOM modifications). This is insufficient for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but conciseness comes at the cost of informativeness. It is front-loaded and efficient, yet it sacrifices necessary detail, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's potential for arbitrary execution (no output schema, no annotations), the description is incomplete. It omits return behavior, error handling, and scope of execution. The single parameter is documented only minimally, leaving critical gaps for an AI 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 coverage is 100%, and the description adds no extra meaning beyond the schema's 'JavaScript expression' description. The value conveyed is identical, so it meets the baseline of 3 for high coverage without adding new insight.
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 action (execute JavaScript) and the context (page context), distinguishing it from sibling tools like browser_click or browser_goto which perform specific UI actions. However, it lacks specificity about the execution environment or return value, making it slightly less than exemplary.
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 (e.g., browser_watch or other interaction tools). There are no prerequisites, exclusions, or context hints, leaving the agent to infer appropriate usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'list' but does not clarify if elements must be visible, what happens if none match, or any side effects. Minimal 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly conveys the purpose. However, it could be more structured (e.g., listing return type) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that returns a list of elements, the description lacks details about the output format, attributes returned, or any filtering behavior. Given no output schema, more information is needed for full completeness.
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 parameter has an enum with descriptions. The description echoes the enum values, adding no new meaning beyond what the schema already 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 states exactly what the tool does: list interactive elements by kind, specifying the four kinds (links, buttons, inputs, headings). It uses a specific verb 'list' and distinct resource 'interactive elements', clearly differentiating from sibling tools like browser_click or browser_goto.
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 usage guidelines are provided. The description does not inform the agent when to use this tool (e.g., before interacting with page) or when not to (e.g., if only text needed). No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions 'visible text content' but does not clarify what 'visible' entails (e.g., hidden elements, scripts), nor does it specify if the tool waits for page load or returns whitespace-trimmed text.
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 efficiently communicates the tool's function with no unnecessary words. It is front-loaded and concise.
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 an output schema and the presence of many sibling tools (e.g., browser_eval), the description is too brief. It does not specify the format of the returned text (e.g., plain string, lines), what happens when no selector is provided, or any side effects.
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% for the only parameter 'selector', which is described as 'Optional CSS selector'. The tool description adds that it retrieves text content from that selector, providing minimal additional 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 clearly states the tool retrieves visible text content from a page or a specific CSS selector. It distinguishes from sibling tools like browser_html (HTML content) and browser_title (page title).
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives like browser_elements or browser_eval, nor does it mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions using CDP Input.dispatchMouseEvent for native events, but does not disclose other important behaviors such as scrolling into view, waiting for element, or error handling. Since annotations are absent, more transparency is needed.
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 with two sentences, no redundant information, and front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a click action and no output schema, the description is somewhat complete but lacks details on return value, error scenarios, and coordinate behavior.
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 sole parameter 'selector' is fully described in the schema with 'CSS selector'. The tool description adds no extra meaning beyond that, so baseline score 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 clicks an element by CSS selector, using a specific verb and resource. It distinguishes from sibling tools like browser_goto, browser_fill, and browser_elements.
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. The description does not mention prerequisites, scenarios, or exclusions.
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 present, so description must carry behavioral burden. It fails to disclose critical details like page load wait behavior, timeout handling, error scenarios, or whether navigation is synchronous. Only states the action and return values.
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 with zero wasted words. Front-loaded with the action and result. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is minimally adequate. However, it omits important contextual details like error handling, prerequisites (e.g., browser must be initialized), and interaction with other tools. Given sibling complexity, more context would be beneficial.
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% (one parameter with description). The tool description does not add additional meaning beyond what the schema already provides (e.g., URL format requirements are implied but not specified). Baseline at 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?
Description clearly states the verb 'Navigate' and the resource 'URL', and mentions the return values (page title and URL). It distinguishes this tool from siblings like browser_back or browser_eval as the primary navigation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., browser_back for backwards navigation). The description does not provide any use cases or exclusions.
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 only restates the selector behavior already present in the schema, and omits critical details such as the output format (e.g., base64 vs. file path) or whether the operation is non-mutating, leaving the agent uncertain about return values and 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, efficient sentence that front-loads the core action. It is compact and every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the screenshot returns, but it does not. However, the tool is simple with all optional parameters, and the purpose is clear. The missing return format and lack of explicit confirmation that it is a read-only operation create a moderate 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?
Schema description coverage is 100%, so all three parameters already have descriptive text. The description adds no new semantic information, merely echoing the selector parameter's purpose. The baseline of 3 is appropriate because the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Take a screenshot') and identifies the resource ('current page'), with an optional CSS selector for element capture. This clearly distinguishes the tool from sibling browser tools like browser_html or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention situations where a screenshot is preferred over textual tools, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the method ('CDP Input.insertText') and mentions clearing the field, but does not elaborate on side effects (e.g., event triggering, hidden inputs). Annotations are absent, so the description carries full burden 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 14 words, front-loaded with key action. Efficient but could benefit from a brief usage note without becoming verbose.
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?
No output schema, so description should hint at return value or success/failure. Lacks details on error handling, focus requirements, or what happens after fill. Adequate for a simple tool but not 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 covers both parameters with descriptions. Description adds no extra meaning beyond schema – it reiterates the action but does not clarify formatting, escape rules, or behavior for special characters.
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 the action: 'Clear and fill an input field with text'. It specifies the resource ('input field') and the verb ('fill'), and distinguishes from sibling tools like browser_click or browser_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like browser_eval or browser_click for filling forms. No mention of prerequisites (e.g., page must be loaded, input must be visible) or when not to use.
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 provided, so the description carries full responsibility. It fails to disclose behavioral traits such as whether it modifies state, requires permissions, or handles errors. It simply states the function without additional context.
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 without fluff. It is front-loaded with the action. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but incomplete. It doesn't clarify behavior when selector is omitted (full page) or when selector matches multiple elements.
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% (single parameter 'selector' described as 'Optional CSS selector'). The description adds no new meaning beyond the schema, so 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 verb 'Get' and the resource 'HTML source', with an optional CSS selector. It distinguishes from sibling tools like browser_text (which gets text) and browser_screenshot (which gets images).
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?
No explicit guidance on when to use this tool vs alternatives. While the description implies it's for HTML, it doesn't mention scenarios or exclusions (e.g., use browser_text for visible text). The sibling list provides context but no direct direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden. 'Get' implies a read-only operation, but it does not explicitly state that it does not modify the browser state, nor describe potential error conditions (e.g., if no browser session exists) or what 'connection info' specifically includes. It adds some context about contents but leaves behavioral details vague.
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 efficiently communicates the tool's purpose and scope without redundancy. Every word contributes meaning.
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, zero-output-schema tool, the description provides a reasonable indication of what the tool returns ('opened tabs and connection info'). However, it omits details about the return format or whether it reports on the current page only or all pages, which could be relevant given the sibling toolset. Still, it is adequate for a simple status snapshot.
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 accepts zero parameters, so per the rubric the baseline is 4. The description does not need to explain parameter semantics since there are none, and the schema is fully covered by having no properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('browser and page status'), and it enumerates key contents (opened tabs, connection info). It distinguishes itself from sibling tools like browser_listTabs by focusing on overall status rather than just tabs, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 the many sibling tools. It does not mention alternative tools like browser_listTabs or browser_title, nor any prerequisites or contexts where this status snapshot is preferable. The description simply states what it does.
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 full burden. It discloses polling interval (200ms) and timeout behavior, but does not mention what happens on timeout (error? return null?) or whether the tool returns the element. The return value is unspecified.
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 clear sentence that immediately conveys the purpose. It is efficient and front-loaded, though it could include additional details without becoming verbose.
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 core waiting behavior and polling, but lacks details on return value, error handling, or performance implications. For a tool with no output schema, more context on outputs would be beneficial.
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. The description does not add extra meaning beyond confirming the overall behavior. 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 clearly states the tool waits for a CSS selector to appear or disappear, with polling details. It distinguishes from sibling tools like browser_click or browser_fill by focusing on waiting rather than action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for waiting on DOM conditions but does not explicitly state when to use this tool over alternatives or provide usage boundaries. It lacks guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action and a use case, but does not explain whether the change applies to the current tab, whether it causes a reload, or how it affects subsequent operations. This is minimal information.
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, no filler. The first sentence states the action, the second gives the use case. Very 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?
For a simple setter with two parameters and no output schema, the description is adequate but could mention the scope (current tab) and that the change applies to subsequent browser interactions. Given the minimal complexity, a score of 3 is appropriate.
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 provides complete descriptions for both parameters (width and height with units and defaults). The description 'width × height' adds no new meaning, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Change' and identifies the resource 'viewport size' with dimensions. It clearly distinguishes from sibling tools like browser_goto or browser_screenshot by focusing on viewport 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 phrase 'Useful for responsive testing' provides a clear context for when to use the tool, though it does not explicitly exclude alternatives. There is no competing viewport tool among siblings, so this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action and parameter, with no mention of side effects, error handling, or return value, leaving the agent without insight into what happens after switching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is concise and to the point, earning its place without unnecessary elaboration.
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 description and schema provide a basic understanding. However, it lacks guidance on how to obtain targetId (e.g., via browser_listTabs) and what happens after switching, making it minimally sufficient but not 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 input schema fully describes targetId as 'Target tab ID to switch to' (100% coverage). The description adds no new semantic detail beyond restating that switching is done 'by targetId', so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Switch' and the resource 'browser tab' with the mechanism 'by targetId'. It is distinct from sibling tools like browser_newTab, browser_closeTab, and browser_goto.
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 usage context is clear: you need a targetId (likely from browser_listTabs) to switch to an existing tab. It does not explicitly mention alternatives or prerequisites, but the purpose is unambiguous and distinct from other tab-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions what the tool returns but not whether it is read-only, whether it executes scripts, or any potential side effects like modifying page state or requiring network requests. The absence of safety and side-effect disclosure is a significant gap for a diagnostic tool that could be heavy.
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 core purpose and immediately informative. The first sentence gives a crisp summary, the second adds a helpful analogy. No waste or redundancy, making it exceptionally 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?
The tool is complex with multiple return types and no output schema. The description enumerates key return categories (performance metrics, console errors, broken images, meta tags, health score), which is a solid summary. However, it lacks details on how the health score is defined or any prerequisites (e.g., requiring a loaded page), leaving some gaps given the richness of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage (empty). With no parameters to explain, the description adds no parameter-specific value, but the baseline 4 applies because there is nothing missing in that regard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does a 'Full page health diagnostic' and lists specific outputs (performance metrics, console errors, broken images, meta tags, health score). This distinguishes it from sibling tools like browser_text or browser_html, which are focused on content retrieval rather than health assessment.
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 the analogy 'Like Lighthouse for your agent' which suggests a comprehensive audit use case, but it does not explicitly state when to use this tool versus alternatives (e.g., using browser_title for a quick check). There are no exclusions or direct comparisons to siblings, leaving usage guidance 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, the description carries the behavioral disclosure burden. It reveals the implementation approach ('rule-based DOM heuristics — no LLM dependency'), which is useful, but omits caveats about failure modes, side effects of actions, or whether actions are irreversible. This leaves the agent with incomplete safety awareness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably sized but contains promotional fluff ('GROUNDBREAKING', 'One tool call does what normally takes 5-10') that does not add operational value. The examples are useful but could be trimmed. Front-loaded enough, but not 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?
The tool has a single parameter, no output schema, and no annotations. The description explains the interaction model and lists varied examples, giving a general sense of capability. However, it does not mention return values, error handling, or limitations (e.g., unsupported page states), which is needed for reliable use in complex browser automation contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one instruction parameter, so baseline is 3. The description adds value through concrete examples of acceptable instructions, clarifying the natural language format and range of intents beyond the schema's minimal 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?
Clearly states it performs natural language page interaction, a distinct capability from sibling tools like browser_click, browser_fill, and browser_goto. The examples ('search for laptops under $1000', 'click the login button', 'fill email') concretely illustrate the 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?
Implies use as a higher-level alternative to multiple discrete tool calls ('One tool call does what normally takes 5-10'). Provides examples across navigation, clicking, filling, extraction, and scrolling, which signal when it applies, but does not explicitly say when to prefer sibling tools like browser_eval or browser_waitForSelector.
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 bears the burden. It analogizes to a browser back button, which conveys typical behavior but does not specify effects if there is no history, or whether it waits for page load. It is adequate but not detailed.
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 directly conveys the purpose with no extraneous words. 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 tool has no parameters, no output schema, and no annotations, the description is largely complete for the action. It could mention additional behavioral details (e.g., no history leads to no action), but the current description is sufficient for a simple navigation 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 has no parameters, so the description does not need to supplement parameter information. The analogy adds context beyond the empty schema, making the action clear. With 0 parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Go back in browser history (like clicking the browser back button).' It uses a specific verb and resource, and the analogy distinguishes it from sibling tools like browser_goto or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (navigating back in history) but does not explicitly state when to use it or when not to, nor does it mention alternatives or conditions like requiring a history entry. It is minimal but adequate for a simple action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 accurately describes the read-only listing behavior and output fields, but does not disclose additional traits such as return format or potential side effects, though none are expected 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, well-structured sentence that conveys all essential information without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description adequately explains what the tool does and partially describes the return values. It does not specify the structure or format of the returned list, but given the simplicity, it is nearly 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, so the baseline is 4. The description adds value by indicating the output content (cookie counts and save dates), which provides meaning beyond the empty 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 lists all saved browser sessions and specifies the included data (cookie counts, save dates). It uses a specific verb and resource, distinguishing it from sibling tools like browser_listTabs.
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?
Usage is implied by the listing nature of the tool, but the description does not explicitly state when to use it or contrast it with alternatives. No exclusions are mentioned, so it is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey safety and behavior. The verb 'List' strongly implies a read-only operation, and the description discloses the exact output fields, providing reasonable transparency for a simple query tool. It lacks explicit statements about side effects or browser requirements, but none are strongly expected 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?
A single sentence with no filler; the tool's action and output contents are specified immediately. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema, the description adequately covers return content (IDs, titles, URLs, active status). Minor omissions like empty-tab-list behavior or error conditions 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, so the input schema carries no burden. The description correctly implies that no arguments are needed, meeting the baseline 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') with a clear resource ('all open browser tabs') and enumerates the returned fields (IDs, titles, URLs, active status). This clearly distinguishes it from sibling tools like browser_newTab or browser_closeTab, which modify tabs, and from browser_status, which likely reports a single tab or browser state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over alternatives such as browser_status or browser_listSessions. The description only states what it does, leaving the agent to infer the appropriate context from the tool name and 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that navigation is required for cookies to take effect, which is valuable, but it does not explain whether loading overwrites or merges existing cookies or what happens if the session name doesn't exist. This is some but not rich 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 two sentences with no redundant wording. The first sentence states the purpose, and the second adds a critical usage note, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the essential information for correct invocation: what it does and the required post-step. It lacks explicit error behavior or cookie-overwrite semantics, but these are not critical for a single-parameter load tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'name' parameter, so the baseline is 3. The tool description adds no additional semantic detail about the parameter beyond what the schema already 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 clearly states the action ('Load') and the resource ('saved browser session (cookies) from disk'), making it distinct from sibling tools like browser_saveCookies and browser_listSessions. It also includes the important follow-up requirement to navigate to the target domain, which fully clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool by instructing the user to navigate after loading, but it does not explicitly mention when not to use it or name alternatives. This is a minor gap, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only, non-destructive operation. With no annotations, this suffices for a simple getter. However, it does not disclose edge cases (e.g., behavior on empty pages or errors), so it is adequate but not thorough.
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 with zero unnecessary words. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a simple read operation, the description provides sufficient context for the agent to understand the tool's purpose. It could mention return format (e.g., string) but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the description adds no parameter information. Baseline 4 is appropriate since there is nothing to describe.
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: 'Get current page URL.' It uses a specific verb (Get) and resource (current page URL), which is unambiguous. No need for sibling differentiation due to its simplicity.
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?
No explicit guidance on when to use this tool versus alternatives like browser_title or browser_status. However, the purpose is singular and straightforward, so the usage context is implicitly clear. Slightly below a 4 due to lack of explicit 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 provided, the description carries the full burden of behavioral disclosure. It states the restart is 'clean' and useful for 'clearing state', which hints at side effects like losing session data. However, it does not explicitly warn that all tabs and sessions will be closed or that cookies/saved state may be lost, which are important for a restart operation. It is not misleading but is not fully transparent about the full extent of state reset.
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, with two sentences that lead with the action and immediately follow with concrete use cases. Every word adds value — there is no fluff or repetition. It is well-structured and front-loaded.
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 parameterless tool, the description covers the core purpose and usage scenarios. However, given the surrounding context (browser session management, cookies, multiple tabs), it omits important caveats like the loss of open tabs and saved sessions. This is a gap that could lead an agent to invoke it without understanding how disruptive a restart is. The description is adequate but 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 tool has zero parameters, so per the rubric the baseline is 4. The description does not need to add parameter semantics, and it does not attempt to. This score reflects the simplicity of the parameterless input 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 purpose: to cleanly restart the browser process. It specifies the resource (browser process) and the action (restart), and distinguishes from siblings like browser_closeTab or browser_newTab by targeting the entire process rather than individual tabs. The additional context about freeing memory and recovering from issues reinforces the specific use case.
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: freeing memory, clearing state, or recovering from issues during long-running sessions. It does not explicitly mention when not to use it or alternative tools, but the provided scenarios are specific and actionable, placing it just below the highest bar.
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 must carry the full burden of behavioral transparency. It correctly indicates a read operation but lacks details on potential failure modes (e.g., no page loaded, non-browser context). Could be more transparent but adequate for a 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?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the tool's purpose without waste.
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, clear function), the description is complete. It fully informs the agent of what the tool does without needing additional 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 tool has zero parameters, and schema coverage is 100%. The description need not add parameter info, achieving the baseline of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current page title.' uses a specific verb ('Get') and resource ('current page title'), clearly distinguishing it from sibling tools like browser_url (gets URL) and browser_screenshot (captures image).
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 retrieving the page title but provides no explicit guidance on when to use it versus alternatives or any prerequisites. For such a simple tool, implied usage is sufficient but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently explains the recording-polling model, indicating that events are captured asynchronously and retrieved via polling. It also lists the event types. It does not mention resource limits or automatic cleanup, but the schema's 'stop' action covers cleanup, and the overall behavior is well conveyed.
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 concise, using two sentences to convey the core behavior and workflow. The 'GROUNDBREAKING:' prefix is unnecessary hype and slightly detracts, but overall the description is well-structured and appropriately sized.
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 moderate complexity (two parameters, no nested objects) and no output schema, the description provides sufficient context: what events are captured, the start-poll-stop workflow, and the fact that events are collected over time. It could be more specific about the return format, but this is not critical for basic usage.
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 fully documents the 'action' and 'events' parameters. The description enumerates event types but adds no additional semantic value beyond what the schema provides. 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's purpose: 'Live capture of page events (console, network, navigation, exceptions).' It uses a specific verb 'capture' with a resource, and the focus on page events distinguishes it from sibling navigation and interaction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage pattern: 'Start recording, browse around, then poll to see everything that happened.' This implies when to use the tool, though it does not explicitly discuss alternatives or when not to use it. The workflow guidance is strong 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that sessions persist across agent and server restarts, a key non-obvious behavioral trait. It also implies persistence via the phrase 'works for days,' but it doesn't address overwrite behavior or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loads the purpose. The quoted tagline and persistence statement are meaningful and concise, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core action and persistence, which is sufficient. It could mention behavior for duplicate names, but that's 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 input schema already fully describes the 'name' parameter with examples, so the description adds no extra parameter semantics. Per the baseline rule for high schema coverage, this scores 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') and resource ('current browser session (cookies)'), clearly distinguishing it from sibling tools like browser_loadCookies or browser_listSessions.
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 tagline 'Login once, agent works for days' implies the primary use case is saving an authenticated session after login, giving clear contextual guidance. It does not explicitly mention alternatives or when not to use, but the context is strong enough.
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 disclosure. It reveals the important behavioral detail that the new tab is automatically switched to, which is not inferable from the schema. It does not, however, mention any potential side effects (e.g., if the URL is invalid or if a blank tab is opened). For a low-complexity tool, this is good but not exhaustive, hence a 4.
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-loaded with the core action, and every word adds value. It states the primary function, the optional behavior, and the automatic switching without any 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 its simplicity (1 optional parameter, no output schema, no annotations), the description provides complete information: what the tool does, the optional navigation, and the automatic switching. There are no hidden complexities requiring further explanation, making this a fully complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'url' parameter described as 'URL to navigate to in the new tab (optional)'. The tool description adds no further meaning beyond restating this in prose ('optionally navigate to a URL'). Since the schema already fully documents the parameter, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action: 'Create a new browser tab' with an optional navigation step, and distinguishes itself from siblings like browser_goto (which navigates the current tab) and browser_switchTab (which switches to an existing tab) by explicitly mentioning the automatic switch. This is a specific verb+resource+scope statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a new tab is needed, optionally with a URL, and notes that it automatically becomes the active tab. It does not explicitly name alternatives or state exclusions, but the context is clear for a simple browser operation. A score of 4 is appropriate for clear context without explicit exclusions.
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?
Since no annotations are provided, the description carries the full burden. It discloses the specific properties modified (navigator.webdriver, plugins, languages, chrome.runtime, user-agent), which is solid behavioral insight. It does not mention persistence or reversibility, so it isn't fully 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 concise sentences with no redundancy; the first gives the purpose and the second elaborates on the mechanism. Highly front-loaded and efficient.
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 tool with no output schema, the description covers the action, rationale, and specific behaviors. Minor gaps include not noting session persistence or interaction with other tools, but for the simplicity, it's nearly 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 is empty (0 parameters), so there's nothing to explain. The description appropriately focuses on behavior. With no parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Apply' and names the resource 'browser fingerprint,' clearly distinguishing it from navigation and DOM manipulation tools like browser_goto and browser_click. It also enumerates the exact properties normalized, leaving no ambiguity about 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?
It explicitly states the intended context: 'in CI/testing' and the goal 'to reduce false-positive automation detection.' While it doesn't list alternatives or exclusions, the stated use case is enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses the default behavior, the limitation on closing the last tab, and the suggested alternative. Could be slightly richer (e.g., what happens to page state), but it is largely transparent for a simple close 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 short sentences deliver the core action, default, and a key exception. Every word earns its place; 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?
The tool is simple with one optional parameter and no output schema. The description covers the action, default, and edge case, and provides an alternative for the one forbidden scenario. It is fully self-contained for the given complexity.
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 provides 100% coverage for the single parameter, including the optional default behavior. The description adds no new parameter-specific meaning beyond what the schema states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close a browser tab'), the target ('by targetId'), and the default behavior when no ID is given. It distinguishes itself from sibling tools like browser_restart and browser_newTab by specifying exactly what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains the default behavior (closes active tab if no targetId) and provides an exclusion: cannot close the last tab, directing the user to 'browser_restart' as an alternative. This is precise when-to-use guidance.
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/krshforever/bwb-browser'
If you have feedback or need assistance with the MCP directory API, please join our Discord server