Playwright MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes focused on specific browser interactions (e.g., click, type, navigate, screenshot), though some potential overlap exists between browser_snapshot and browser_take_screenshot where descriptions help clarify their different use cases. The tool set avoids major ambiguity with well-defined scopes for each action.
Naming Consistency5/5
All tools follow a consistent 'browser_verb_noun' or 'browser_noun_verb' pattern with snake_case throughout, making them predictable and easy to parse. This uniformity enhances usability and reduces cognitive load when selecting tools.
Tool Count3/5
With 24 tools, the count is borderline high for a browser automation server, potentially overwhelming but still manageable given the comprehensive coverage of web interactions. It feels slightly heavy compared to typical well-scoped servers (3-15 tools), but not extreme.
Completeness5/5
The tool set provides complete coverage for browser automation, including navigation, interaction (click, type, hover), file handling, dialog management, tab control, and debugging (console, network, screenshots). No obvious gaps exist for core web testing or scraping workflows.
Average 3.4/5 across 24 of 24 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, openWorldHint=true, and destructiveHint=true, indicating this is a mutable, open-ended, and potentially destructive operation. The description doesn't contradict these annotations, but it adds minimal context beyond them—it vaguely implies interaction with dialogs without detailing what 'handle' entails (e.g., accepting/dismissing, providing input). For a tool with annotations covering safety and scope, the description adds some value but lacks rich behavioral details like side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loaded and free of unnecessary information. Every word ('Handle a dialog') directly relates to the tool's function, though it's under-specified. There's no wasted text, making it efficient in structure despite its content gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (handling dialogs with potential destruction), lack of output schema, and rich annotations, the description is incomplete. It doesn't explain what a 'dialog' is in this context, what happens when accepted or dismissed, or the return behavior. The annotations provide safety hints, but the description fails to add necessary context for effective use, leaving significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters: 'accept' (boolean for accepting the dialog) and 'promptText' (string for prompt dialog text). The description adds no meaning beyond the schema—it doesn't explain how these parameters interact or provide examples of usage. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' is a tautology that restates the tool name without specifying what 'handle' means or what type of dialog is involved. It doesn't distinguish this tool from sibling browser tools like browser_click or browser_press_key, which also handle interactions. The description lacks a specific verb-resource combination that clarifies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention what triggers a dialog (e.g., alerts, prompts, confirmations) or when other tools like browser_click might be more appropriate. There's no context about prerequisites or exclusions, leaving the agent with no usage 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?
Annotations provide key behavioral hints: destructiveHint=true (indicating data loss) and openWorldHint=true (suggesting external effects). The description adds no behavioral context beyond 'Close a tab', such as what happens to unsaved data or if confirmation is needed. It doesn't contradict annotations, but adds minimal value given the annotations cover safety and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Close a tab') with zero wasted words, making it front-loaded and easy to parse. It efficiently conveys the core action without unnecessary detail, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (per annotations) and lack of output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances like what happens after closing (e.g., focus shift). For a destructive tool with no output schema, more context is needed to guide safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'index' fully documented in the schema (closes current tab if not provided). The description adds no parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close a tab' states the action (close) and resource (tab), but it's vague about scope and doesn't differentiate from sibling tools like 'browser_close' (which likely closes the entire browser). It doesn't specify whether this closes tabs in a browser context or another environment, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention siblings like 'browser_tab_list' (to list tabs before closing) or 'browser_tab_select' (to select a tab first), nor does it specify prerequisites such as needing an open browser or tab. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a click performs an action. However, the description adds minimal behavioral context beyond annotations—it doesn't specify that clicks can trigger navigation, form submissions, or JavaScript events, nor does it mention rate limits or authentication needs, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words—'Perform click on a web page' is front-loaded and efficiently conveys the core action. It earns its place by stating the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is incomplete. It lacks details on return values (e.g., success/failure indicators), error handling, or dependencies like needing a prior browser_snapshot. Given the complexity of web interactions and sparse annotations, more context is needed for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all 4 parameters. The description adds no additional meaning about parameters, such as explaining how 'element' and 'ref' work together or typical use cases for button types. This meets the baseline of 3 since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform click on a web page' clearly states the action (click) and target (web page), distinguishing it from siblings like browser_hover or browser_type. However, it doesn't explicitly differentiate from browser_drag or browser_select_option, which also involve clicking interactions, so it lacks full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_drag (which might involve clicking) or browser_select_option (for dropdowns). It mentions no prerequisites, such as requiring a page snapshot from browser_snapshot first, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds minimal behavioral context by specifying what triggers the wait (text appearance/disappearance or time), but doesn't elaborate on timeout behavior, error handling, or interaction with other browser tools. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. It avoids redundancy and waste, though it could be slightly more structured by separating the text and time conditions for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (waiting with multiple triggers), annotations cover safety and scope, and schema fully documents parameters. However, without an output schema, the description doesn't explain return values (e.g., success/failure, timeout errors), leaving gaps in understanding the tool's full behavior in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, fully documenting all three parameters (text, textGone, time). The description mentions these parameters generically ('text to appear or disappear' and 'specified time') but adds no extra semantic details like format examples, mutual exclusivity, or default behaviors, so it meets the baseline without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as waiting for text to appear/disappear or for time to pass, which is a specific verb+action combination. However, it doesn't explicitly distinguish this from sibling tools like browser_handle_dialog or browser_console_messages that might also involve waiting for specific conditions, though the core functionality is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where waiting is preferred over other actions (e.g., using browser_handle_dialog for pop-ups) or prerequisites like needing an active browser session, leaving usage context entirely 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?
Annotations provide key behavioral hints: destructiveHint=true (indicating potential changes), readOnlyHint=false (confirms it's a mutation), and openWorldHint=true (suggests dynamic environment). The description adds minimal context beyond this, stating the action but not elaborating on effects like UI state changes or error conditions. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a drag-and-drop operation in a browser context, the description is minimal. Annotations cover safety and environment aspects, but no output schema exists, and the description doesn't address return values, error handling, or interaction nuances. It's adequate but leaves gaps for a tool with destructive potential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for all four parameters (startElement, startRef, endElement, endRef). The description adds no additional parameter semantics, such as explaining the relationship between 'element' and 'ref' parameters or usage examples. Baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('perform drag and drop') and specifies the relationship ('between two elements'), which is more specific than just the tool name. However, it doesn't explicitly differentiate from sibling tools like browser_click or browser_hover that also involve element interaction, though the drag-and-drop action is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_click or browser_hover for similar element interactions. It lacks context about prerequisites (e.g., needing element references from a snapshot) or scenarios where drag-and-drop is appropriate over other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, non-read-only operation with open-world behavior. The description adds no behavioral context beyond what annotations provide (e.g., no details on upload destinations, error handling, or file size limits), but it doesn't contradict annotations either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the core action and resource with zero wasted language. Every word earns its place by clearly communicating the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is minimally complete but lacks important context. It doesn't explain what happens after upload, potential side effects, or error conditions, leaving gaps despite good annotations covering basic safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents the 'paths' parameter. The description mentions 'one or multiple files' which aligns with the schema but adds no additional semantic context beyond what's already in the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('upload') and resource ('one or multiple files'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling upload tools (though none exist in the provided sibling list), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or prerequisites. It doesn't mention context like browser state requirements or when other browser tools might be more appropriate, leaving the agent with minimal usage 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation with potential for dynamic content. The description adds minimal behavioral context beyond this, as 'hover' implies a UI interaction but doesn't detail effects like triggering events or visual feedback. It doesn't contradict annotations, so it earns a baseline score for adding some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Hover over element on page' is extremely concise and front-loaded, consisting of a single, direct sentence that efficiently communicates the core action. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (interactive UI action), rich annotations (readOnlyHint, openWorldHint), and no output schema, the description is minimally complete. It states what the tool does but lacks details on outcomes (e.g., what hovering achieves), error conditions, or integration with sibling tools. This leaves gaps for an agent to fully leverage the tool in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters: 'element' as a human-readable description for permissions and 'ref' as an exact target reference. The description adds no additional parameter semantics beyond what the schema provides, such as examples or interaction details, so it meets the baseline for high schema coverage without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over element on page' clearly states the action (hover) and target (element on page), making the purpose immediately understandable. It uses a specific verb+resource pattern, though it doesn't explicitly differentiate from sibling tools like browser_click or browser_press_key, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where hovering is appropriate (e.g., triggering dropdowns, tooltips) or when to avoid it, nor does it reference sibling tools like browser_click for different interactions. This lack of contextual usage information is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description does not contradict. However, the description adds minimal behavioral context beyond annotations—it implies navigation but does not specify effects like page loading, error handling, or browser state changes. With annotations covering safety, a baseline 3 is appropriate as the description adds little extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately sized for a simple tool and front-loaded with the core action, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and rich annotations (destructiveHint, openWorldHint), the description is minimally adequate. However, with no output schema and the description lacking details on return values or navigation outcomes, it leaves gaps in understanding the full tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'url' parameter fully documented. The description does not add any meaning beyond the schema, such as URL format requirements or navigation behavior details. Baseline 3 is correct when the schema handles all parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate to a URL' clearly states the action (navigate) and target (URL), making the purpose understandable. However, it does not differentiate from sibling tools like 'browser_navigate_back' or 'browser_navigate_forward', which are related navigation actions, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to choose this over other navigation tools like 'browser_navigate_back' or 'browser_navigate_forward', nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide key behavioral hints (destructiveHint: true, readOnlyHint: false, openWorldHint: true), but the description adds minimal context beyond stating the action. It doesn't elaborate on what 'destructive' means in this context (e.g., potential side effects like triggering events) or mention rate limits, though annotations cover the safety profile adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action, making it highly efficient and easy to parse, which is ideal for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema) and rich annotations, the description is minimally adequate. However, it lacks details on return values or error conditions, which could be helpful despite the annotations covering basic behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents the single 'key' parameter, including examples like 'ArrowLeft' or 'a'. The description adds no additional parameter information, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a key on the keyboard' clearly states the action (press) and resource (key on keyboard), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'browser_type' which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'browser_type' or 'browser_click'. It lacks context about specific scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide key behavioral hints: readOnlyHint=true and destructiveHint=false indicate it's a safe, non-destructive operation, and openWorldHint=true suggests it can be used in various contexts. The description adds minimal context beyond this—it doesn't specify if resizing affects page rendering, requires specific permissions, or has side effects. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action, making it highly efficient. Every part of the sentence ('Resize the browser window') contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 simple parameters) and rich annotations (covering safety and scope), the description is minimally adequate. However, with no output schema, it doesn't explain what happens after resizing (e.g., success confirmation or error handling). For a browser interaction tool, more context on effects would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter definitions for 'width' and 'height'. The description adds no additional semantic context beyond implying these parameters are required for resizing. It doesn't explain units (e.g., pixels), valid ranges, or default behaviors, so it relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Resize') and resource ('the browser window'), making the purpose immediately understandable. It distinguishes itself from siblings like browser_close or browser_take_screenshot by focusing on window dimensions. However, it doesn't explicitly differentiate from all siblings (e.g., browser_snapshot might also involve window manipulation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser session), exclusions, or related tools. For example, it doesn't clarify if this should be used instead of browser_tab_new for window management or how it interacts with browser_navigate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. However, the description adds no behavioral context beyond the annotations—it doesn't explain what 'destructive' means here (e.g., changes UI state), rate limits, or error handling. With annotations covering safety, a 3 reflects minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without redundancy. It's appropriately sized for a simple action tool and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (moderate, with destructive behavior), rich annotations, and no output schema, the description is minimally adequate. It covers the basic action but lacks details on outcomes, error cases, or integration with siblings like browser_snapshot for obtaining 'ref'. With annotations, it meets a baseline but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying dropdown interaction, which is already clear from the tool name. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select an option in a dropdown' clearly states the action (select) and target (dropdown), distinguishing it from siblings like browser_click or browser_type. However, it doesn't explicitly differentiate from browser_handle_dialog which might also involve dropdowns, making it slightly less specific than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring a page snapshot), exclusions, or comparisons to siblings like browser_click for non-dropdown interactions, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, which already convey that this is a safe, non-destructive operation with potential for open-ended outcomes. The description adds minimal context by specifying 'by index', but doesn't elaborate on behavioral aspects like what happens if the index is invalid, whether it changes browser focus, or any side effects. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Select a tab by index'—front-loading the core action. It's appropriately sized for a simple tool, with every word contributing directly to understanding the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, simple operation), annotations covering safety (readOnly, non-destructive), and no output schema, the description is minimally adequate. However, it lacks context on prerequisites (e.g., needing browser_tab_list first) or error handling, leaving gaps for an agent to infer usage correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'index' parameter fully documented as 'The index of the tab to select'. The description 'Select a tab by index' adds no additional meaning beyond this schema, such as index format (e.g., zero-based) or constraints. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select a tab by index' clearly states the verb 'select' and resource 'tab', with the specific mechanism 'by index' distinguishing it from other tab-related tools like browser_tab_list or browser_tab_close. However, it doesn't explicitly differentiate from all sibling tools, as browser_tab_new also involves tabs but for creation rather than selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open browser or existing tabs), when not to use it (e.g., if no tabs exist), or refer to sibling tools like browser_tab_list for listing tabs first. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds minimal behavioral context beyond this, not explaining what 'close' entails (e.g., whether it terminates a session or just a tab) or any side effects, but doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Close the page'—a single, front-loaded sentence that directly conveys the action without any wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and annotations covering key behavioral traits, the description is minimally adequate. However, it lacks details on what 'close' means operationally (e.g., closes current tab vs. entire browser) and how it interacts with siblings, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4 as no parameter documentation is needed. The description doesn't add parameter details, which is appropriate given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the page' clearly states the action (close) and target (the page), which is specific and unambiguous. However, it doesn't differentiate from sibling 'browser_tab_close' which might have similar functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'browser_tab_close' or when not to use it (e.g., if no page is open). It lacks context about prerequisites or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, read-only operation with potential side effects. The description adds minimal behavioral context beyond this, as 'Go forward' implies navigation but doesn't detail effects like page loading or history changes. It doesn't contradict annotations, so it earns a baseline score for adding some value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action, making it highly efficient and easy to parse. Every word earns its place by directly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema) and rich annotations covering safety and behavior, the description is adequate but minimal. It states what the tool does but lacks details on usage context or expected outcomes, which could be helpful for an agent. It meets minimum viability without being comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. It earns a high score because it doesn't need to compensate for any schema gaps, and the lack of parameter discussion is efficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Go forward') and target ('to the next page'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish itself from sibling tools like 'browser_navigate_back' or 'browser_navigate', though the action is inherently different. The purpose is unambiguous but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'browser_navigate_back' or 'browser_navigate'. It doesn't mention prerequisites (e.g., requiring a browser session or forward history), exclusions, or contextual cues. Usage is implied by the action but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds value by specifying it captures an 'accessibility snapshot' (implying structured data like ARIA attributes) rather than a visual image, which is useful context beyond annotations. However, it doesn't detail output format or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Capture accessibility snapshot of the current page') and adds a brief comparative note. Every word serves a purpose, with no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, rich annotations (readOnlyHint, destructiveHint, openWorldHint), and no output schema, the description is adequate but could be more complete. It explains what the tool does but doesn't clarify the output (e.g., what an 'accessibility snapshot' contains) or tie into the sibling tools effectively, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('capture') and resource ('accessibility snapshot of the current page'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this from the sibling 'browser_take_screenshot' tool beyond saying 'this is better than screenshot,' which is somewhat vague rather than a clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by implying this tool is preferable to 'browser_take_screenshot' for accessibility purposes, but it doesn't specify when to use it (e.g., for accessibility testing vs. visual capture) or when not to use it. No explicit alternatives or prerequisites are mentioned, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating this is a safe, read-only operation. The description adds minimal behavioral context beyond this, as it doesn't specify what information is listed (e.g., tab titles, URLs) or any constraints like performance implications. It doesn't contradict annotations, but adds little value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'List browser tabs' is extremely concise and front-loaded, consisting of just three words that directly convey the core action. There's no wasted language or unnecessary elaboration, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is minimally adequate. However, it lacks details on what the output includes (e.g., tab IDs, titles) or usage context, which could be helpful for an agent. The annotations cover safety, but the description doesn't fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List browser tabs' clearly states the verb ('List') and resource ('browser tabs'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'browser_tab_select' or 'browser_tab_close', which also involve tabs but perform different actions, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention if this is for getting current tab information or all tabs, or how it relates to siblings like 'browser_tab_select'. There's no explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description doesn't contradict annotations. Annotations indicate this is a destructive, non-read-only operation with open-world characteristics. The description adds context by specifying it evaluates JavaScript on 'page or element,' which helps clarify the scope beyond what annotations provide. However, it doesn't detail potential side effects like page modifications or security implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear phrase with no wasted words. It's front-loaded with the core functionality, making it easy to understand at a glance without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (JavaScript evaluation in a browser with destructive potential) and lack of output schema, the description is minimal. It covers the basic purpose but doesn't address return values, error handling, or security considerations, leaving gaps for an AI agent to infer behavior in a potentially risky operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by implying the 'element' parameter is optional (evaluating on 'page or element'), but doesn't provide additional syntax or usage details. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('evaluate') and target ('JavaScript expression on page or element'), distinguishing it from sibling tools that perform physical interactions like click, type, or navigate. However, it doesn't specify that this is for browser automation contexts, which is implied but could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is for executing custom JavaScript code in a browser context, nor does it differentiate from other browser tools like browser_console_messages (for reading console output) or browser_snapshot (for capturing page state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating this is a safe, non-destructive operation that can open any URL. The description adds context by specifying it opens 'a new tab' (not just any browser action), which complements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's front-loaded with the essential action and resource, making it immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, good annotations, and no output schema, the description is minimally adequate. However, it lacks context about browser state requirements, what happens if no URL is provided (though the schema covers this), and how it relates to sibling tab management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'url' parameter fully documented in the schema itself. The description doesn't add any parameter information beyond what's in the schema, so it meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and resource ('a new tab'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'browser_tab_list' or 'browser_tab_select', but the verb 'Open' distinguishes it from those listing/selection operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'browser_navigate' (which might navigate in current tab) or 'browser_tab_list' (which lists tabs), nor does it specify prerequisites like needing an active browser session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=true, covering safety and scope. The description adds context by specifying it types into 'editable element,' which clarifies the target beyond annotations. It doesn't contradict annotations, but lacks details on side effects (e.g., triggering events) or error handling, though annotations provide a good baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence ('Type text into editable element') with zero waste. It efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interactive browser action with 5 parameters), annotations provide good behavioral context (destructive, open-world), and schema coverage is 100%. However, no output schema exists, and the description lacks details on return values or error cases. It's adequate but has gaps in completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'element' for permission, 'ref' for target, 'slowly' for character-by-character typing). The description doesn't add meaning beyond the schema, but the schema is comprehensive, so a baseline score of 3 is appropriate as it doesn't compensate or detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Type text into editable element' clearly states the action (type) and target (editable element), distinguishing it from siblings like browser_click or browser_press_key. However, it doesn't explicitly differentiate from browser_select_option or browser_file_upload, which also involve input actions, making it clear but not fully sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a page snapshot from browser_snapshot), exclusions (e.g., non-editable elements), or comparisons to siblings like browser_press_key for key presses or browser_select_option for dropdowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe read operation with potentially unbounded results. The description adds value by specifying 'all console messages' (implying comprehensive retrieval), which complements the openWorldHint about unbounded data. No contradiction with annotations, and it provides useful context about scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single sentence that directly states the tool's function. No unnecessary words or structural fluff. Every word earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only operation with annotations), the description is minimally adequate. However, it lacks details about what 'console messages' includes (e.g., logs, errors, warnings), whether it's real-time or historical, and there's no output schema to clarify return values. For a tool that retrieves data, more context about the data format would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, and it appropriately doesn't mention any. A baseline of 4 is appropriate for a zero-parameter tool where the schema fully covers the input structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns all console messages' clearly states the action (returns) and resource (console messages). It distinguishes from most siblings that perform browser interactions (click, navigate, type) but doesn't explicitly differentiate from browser_network_requests which also returns data. The purpose is specific but could be more precise about what 'console messages' refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an active browser session), appropriate contexts, or when other tools might be more suitable. It's a standalone statement with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds useful context by specifying 'since loading the page,' which clarifies the temporal scope of data returned, enhancing behavioral understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without any wasted words. It's front-loaded with the main action and resource, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema) and rich annotations, the description is adequate but has gaps. It lacks details on output format (e.g., structure of returned requests) and doesn't address potential limitations like data volume or browser state requirements, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, there's no need for parameter details in the description. The baseline for zero parameters is 4, as the description appropriately focuses on the tool's function without redundant parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns') and resource ('all network requests since loading the page'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like browser_console_messages or browser_tab_list, which also retrieve browser data but for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser page), exclusions, or how it relates to siblings like browser_console_messages for different data types, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying installation (a write operation). The description adds valuable context beyond annotations by specifying it's for resolving installation errors, which helps the agent understand when this destructive action is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that directly address the tool's purpose and usage scenario. Every word serves a clear function, with no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no output schema, and annotations cover key behavioral aspects (destructive, not read-only), the description provides sufficient context by explaining what it does and when to use it. It could slightly improve by mentioning what 'config' refers to, but it's adequate for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install') and target ('browser specified in the config'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like browser_click or browser_navigate, which perform different browser operations rather than installation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Call this if you get an error about the browser not being installed.' This clearly defines the trigger condition and context for usage, with no misleading information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds behavioral context about what 'previous page' means (navigation history) that isn't captured in annotations. It doesn't mention potential failures (e.g., no history) or side effects, but with good annotation coverage, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and appropriately sized for a simple navigation tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and comprehensive annotations, the description is mostly complete. It could benefit from mentioning potential edge cases (e.g., what happens with no history), but for a basic navigation operation with good structured data, it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters, and the baseline for 0 parameters is 4. The description appropriately focuses on the action rather than parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go back to the previous page' clearly states the specific action (go back) and resource (previous page) with a precise verb. It distinguishes from sibling tools like 'browser_navigate_forward' by specifying directionality, and from 'browser_navigate' by focusing on navigation history rather than new URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when there is a previous page in browser history) but doesn't explicitly state when not to use it or name alternatives. It doesn't provide prerequisites like requiring an open browser session, though this might be inferred from the tool family context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds valuable context about the tool's limitations (no action capability) and clarifies its purpose relative to browser_snapshot, enhancing behavioral understanding without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the core purpose, followed by critical usage guidance. Every sentence earns its place by providing essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and full schema coverage, the description is largely complete. It effectively clarifies the tool's role and limitations, though it could slightly enhance completeness by mentioning output behavior (e.g., file saving) since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description does not add any parameter-specific information beyond what the schema provides, meeting the baseline expectation for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Take a screenshot') and resource ('current page'), distinguishing it from sibling tools like browser_snapshot. It explicitly mentions what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use this tool ('You can't perform actions based on the screenshot') and names a specific alternative ('use browser_snapshot for actions'). This clearly differentiates it from sibling tools and helps the agent choose appropriately.
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:

[![playwright-mcp MCP server](https://glama.ai/mcp/servers/furugen/playwright-mcp/badges/card.svg)](https://glama.ai/mcp/servers/furugen/playwright-mcp)

Score Badge

Copy to your README.md:

[![playwright-mcp MCP server](https://glama.ai/mcp/servers/furugen/playwright-mcp/badges/score.svg)](https://glama.ai/mcp/servers/furugen/playwright-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/furugen/playwright-mcp'

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