Playwright MCP

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 distinct purposes, but there is some overlap between browser_snapshot and browser_take_screenshot, as both involve capturing page states, though their descriptions clarify different use cases. The tools generally target specific actions like navigation, interaction, or monitoring, reducing confusion.
Naming Consistency5/5
All tool names follow a consistent 'browser_' prefix with snake_case, using clear verbs like click, close, navigate, or wait_for. This predictable pattern makes it easy for agents to understand and predict tool functions without ambiguity.
Tool Count3/5
With 22 tools, the count is borderline high for a web automation server, potentially overwhelming but still manageable given the comprehensive scope. It covers many aspects of browser interaction, though some tools might be consolidated for better focus.
Completeness5/5
The tool set provides complete coverage for web automation tasks, including navigation, interaction (click, type, drag), form handling, monitoring (console, network), and utilities (screenshot, wait). No obvious gaps exist for typical Playwright workflows, ensuring agents can handle end-to-end scenarios.
Average 3.4/5 across 22 of 22 tools scored. Lowest: 2.4/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 indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=true, which already inform the agent that this is a mutable, potentially destructive operation with open-ended outcomes. The description adds minimal value by implying interaction with dialogs but doesn't elaborate on behavioral traits like side effects, error conditions, or specific dialog types. No contradiction with annotations exists, but the description fails to compensate for the lack of output schema or detailed 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, which is efficient and front-loaded. However, it's overly terse to the point of under-specification, missing critical details that would help an agent. While not verbose, it fails to earn a perfect score due to lacking necessary explanatory content.
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 browser dialogs with destructive potential), lack of output schema, and minimal annotations beyond basic hints, the description is incomplete. It doesn't cover return values, error handling, or the scope of 'dialogs' (e.g., alerts, confirms, prompts), leaving significant gaps for agent understanding in a context-rich browser automation environment.
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 'accept' (boolean for accepting the dialog) and 'promptText' (string for prompt dialog text). The description adds no parameter semantics beyond what the schema provides, such as explaining when 'promptText' is required or how 'accept' interacts with different dialog types. Baseline 3 is appropriate given the schema's comprehensive coverage.
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 adding specificity. It doesn't clarify what type of dialog (e.g., JavaScript alert, confirmation, prompt) or what 'handling' entails beyond the basic verb. While it distinguishes from siblings like 'browser_click' or 'browser_navigate' by focusing on dialogs, it lacks the detailed verb+resource+scope needed for higher scoring.
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 prerequisites (e.g., that a dialog must be present), exclusions, or related tools for different dialog types. Given the sibling tools include various browser interactions, this lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and openWorldHint=true, which the description doesn't contradict. However, it adds minimal behavioral context beyond annotations—it doesn't explain what 'navigate' destroys, potential side effects, or navigation specifics. With annotations covering safety, it earns a baseline score for not adding much 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 extremely concise with no wasted words—'Navigate to a URL' is a single, clear sentence. It's front-loaded and appropriately sized for a simple tool, earning full marks for efficiency.
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 (navigation with destructive potential) and lack of output schema, the description is incomplete. It doesn't explain return values, error conditions, or navigation outcomes. With annotations providing some context but no output details, it falls short of being fully 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% for the single parameter 'url', so the schema fully documents it. The description doesn't add any meaning beyond the schema, such as URL format constraints or navigation behavior details. Baseline 3 is appropriate as the schema handles parameter documentation.
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 'Navigate to a URL' clearly states the action (navigate) and target (URL), but it's vague about scope and doesn't distinguish from siblings like browser_navigate_back. It specifies the resource but lacks detail on what 'navigate' entails beyond the basic verb.
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, context for navigation, or compare to siblings like browser_navigate_back or browser_tabs. The description offers no usage context beyond the basic action.
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 mutation ('fill'). The description adds value by hinting at bulk operation ('multiple form fields'), but lacks details on side effects, error handling, or dependencies. 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 phrase with no wasted words. It is front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
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 insufficient. It lacks details on return values, error conditions, or interaction with the browser context. Given the annotations cover safety but not operational context, more completeness is needed.
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 'fields' parameter fully documented in the schema. The description adds no additional meaning beyond implying multiple fields, which is already clear from the schema's array type. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' states the action (fill) and target (form fields), but is vague about scope and lacks differentiation from siblings like browser_type or browser_select_option. It doesn't specify whether this is for web forms or other contexts, making it minimally adequate but unclear.
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 such as browser_type for text input or browser_select_option for dropdowns. The description implies bulk form filling but offers no context on prerequisites, timing, or exclusions, leaving usage ambiguous.
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 a mutating action ('Perform click'). The description adds minimal behavioral context beyond annotations, but doesn't contradict them. It lacks details on error handling or side effects, but annotations cover key safety aspects.
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 appropriately sized for a simple action and front-loads the core functionality 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?
For a destructive tool with no output schema, the description is minimally adequate but lacks context about outcomes or errors. Annotations provide safety hints, but the description doesn't address what happens post-click (e.g., page changes, navigation) or integration with other browser tools, leaving gaps in completeness.
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%, providing full parameter documentation. The description adds no parameter-specific information beyond what's in the schema, such as explaining the relationship between 'element' and 'ref' or typical use cases for modifiers. 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.
Purpose3/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' states the action (click) and target (web page), but is vague about scope and lacks sibling differentiation. It doesn't specify whether this clicks on specific elements or general coordinates, nor how it differs from similar tools like browser_press_key or browser_select_option.
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. The description doesn't mention prerequisites (e.g., needing a browser session or page snapshot), nor does it clarify use cases relative to siblings like browser_hover or browser_press_key for interaction scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a destructive (destructiveHint: true), non-read-only (readOnlyHint: false) operation with open-world characteristics (openWorldHint: true). The description 'Hover over element on page' aligns with these annotations by implying an interactive action that could trigger page changes, but it doesn't add significant behavioral context beyond what annotations provide, such as specific side effects or rate limits.
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 ('Hover over element on page'), with zero wasted language. It's front-loaded and directly communicates the core action, making it highly efficient despite potential 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 complexity (interactive browser action with destructive hints), lack of output schema, and rich annotations, the description is insufficient. It doesn't explain what happens after hovering (e.g., triggering UI changes), potential errors, or integration with other browser tools, leaving significant gaps for agent 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?
With 100% schema description coverage, the input schema fully documents both parameters (element and ref). The description adds no additional parameter semantics, such as explaining the relationship between 'element' and 'ref' or providing usage examples. 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 'Hover over element on page' clearly states the action (hover) and target (element on page), making the purpose immediately understandable. However, it doesn't differentiate this tool from its many sibling browser interaction tools (like browser_click or browser_press_key) beyond the specific hover action, which is why it doesn't reach 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_click or browser_press_key. It doesn't mention any prerequisites, context requirements, or scenarios where hovering is specifically needed over other interactions, leaving the agent without 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, covering safety and scope. The description adds minimal behavioral context by implying it retrieves messages (consistent with annotations) but doesn't disclose details like whether it clears messages after retrieval, requires specific browser state, or has rate limits. 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 wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool, 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 low complexity (1 optional parameter), rich annotations (covering safety and scope), and no output schema, the description is minimally adequate. However, it lacks context about what 'console messages' entail (e.g., browser console logs, timestamps, sources) and doesn't address potential limitations or prerequisites, leaving gaps for an agent to infer 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 'level' parameter fully documented in the schema (enum values, default, description). The description adds no parameter-specific information beyond what the schema provides, 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 'Returns all console messages' clearly states the verb ('returns') and resource ('console messages'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'browser_network_requests' or 'browser_tabs' which also return browser-related data, nor does it specify that these are browser console messages specifically.
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 when it's appropriate (e.g., for debugging browser interactions) or when not to use it (e.g., for network monitoring where 'browser_network_requests' would be better). There's no reference to sibling tools or contextual usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds value by specifying the action involves two elements, but it doesn't elaborate on behavioral traits like potential side effects, error conditions, or interaction constraints beyond what annotations provide.
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 action without unnecessary words. It is front-loaded and appropriately sized for the tool's complexity.
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, destructive) and lack of output schema, the description is minimal but adequate. It covers the basic action but doesn't address return values, error handling, or detailed usage context, leaving gaps that annotations partially fill.
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 four parameters. The description implies parameters for start and end elements but adds no additional meaning beyond the schema's detailed descriptions of human-readable descriptions and exact references from page snapshots.
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 the target ('between two elements'), which is specific and actionable. However, it doesn't differentiate itself from sibling tools like browser_click or browser_hover, which are also interaction tools but for different actions.
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, nor does it mention prerequisites such as needing a page snapshot or specific element references. It lacks context about appropriate scenarios 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?
Annotations already indicate this is a destructive, non-read-only operation with open-world implications. The description adds some context by specifying it evaluates JavaScript on 'page or element', but doesn't elaborate on what 'destructive' means in practice (e.g., could modify page state, trigger side effects) or address rate limits, authentication needs, or specific behavioral traits beyond what annotations provide.
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 sentence that communicates the core functionality without any wasted words. It's front-loaded with the essential information and earns its place 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?
For a complex, destructive JavaScript evaluation tool with no output schema, the description is minimal. While annotations cover safety aspects, the description doesn't explain what kind of results to expect, error handling, or the relationship between parameters. Given the tool's potential complexity and destructive nature, more context would be helpful despite the good annotations.
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 - it mentions 'page or element' which relates to the element/ref parameters, but doesn't provide additional syntax examples, constraints, or usage patterns that aren't already in the parameter descriptions.
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 resource ('JavaScript expression on page or element'), making the purpose immediately understandable. It distinguishes this tool from siblings like browser_click or browser_type by focusing on JavaScript execution rather than direct interaction. However, it doesn't explicitly differentiate from browser_run_code, which might be a similar sibling.
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. With siblings like browser_run_code that might serve similar purposes, there's no indication of when this evaluation approach is preferred, nor any mention of prerequisites or constraints 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 indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict (uploading implies mutation). The description adds that it can handle single or multiple files, which is useful context beyond annotations. However, it lacks details on permissions, rate limits, or what happens if upload fails, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 resource, making it easy to parse quickly. Every word earns its place by conveying 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 (destructive operation with no output schema), the description is adequate but incomplete. It covers the basic action but lacks details on error handling, success criteria, or integration with sibling tools. With annotations providing safety hints, it meets minimum viability but could be more comprehensive.
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 'paths' well-documented in the schema. The description adds minimal value by implying the parameter can accept multiple files, but this is already clear from the schema's array type. Baseline 3 is appropriate as the schema carries most of the burden.
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 from sibling tools like browser_drag or browser_fill_form, which might also involve file operations in some contexts, so it doesn't reach the highest 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 prerequisites (e.g., needing an open browser), exclusions, or comparisons to sibling tools like browser_drag for file handling. This leaves the agent with minimal context for decision-making.
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, covering safety and scope. The description adds value by specifying 'since loading the page', indicating temporal scope, but doesn't disclose behavioral traits like rate limits, pagination, or response format. With annotations providing core safety, a 3 is appropriate for minimal added 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/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's front-loaded and appropriately sized, with every part contributing essential information, 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 (1 parameter, 100% schema coverage, no output schema) and rich annotations, the description is minimally adequate. It covers the basic action but lacks details on output format, error handling, or integration with siblings, leaving gaps despite structured data support.
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 'includeStatic' fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides, such as examples or edge cases. Baseline 3 is correct 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and resource 'all network requests since loading the page', providing specific functionality. However, it doesn't explicitly differentiate from sibling tools like browser_console_messages or browser_snapshot that might also capture network-related data, missing 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, such as browser_console_messages for console logs or browser_snapshot for visual captures. It lacks explicit context, prerequisites, or exclusions, offering only a basic functional statement without 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 indicate destructiveHint=true (mutation) and readOnlyHint=false, so the agent knows this modifies state. The description adds no behavioral context beyond this, such as whether resizing affects page layout, requires specific permissions, or has side effects. With annotations covering the safety profile, a baseline 3 is appropriate as the description doesn't contradict 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 is a single, efficient sentence with zero waste. It's front-loaded and directly conveys the core function without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (destructive operation with two parameters), annotations provide safety context, but there's no output schema. The description lacks details on return values (e.g., success confirmation) or error conditions, leaving gaps. It's minimally adequate but not fully complete for informed 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?
Schema description coverage is 100%, with clear parameter descriptions for width and height. The description adds no meaning beyond what the schema provides, such as unit explanations (pixels), valid ranges, or default behaviors. Since the schema does the heavy lifting, the baseline score of 3 is warranted.
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 'Resize the browser window' clearly states the action (resize) and resource (browser window), making the purpose immediately understandable. It distinguishes from siblings like browser_close or browser_navigate by specifying the resize operation. However, it lacks explicit differentiation from tools like browser_snapshot that might also involve window dimensions, 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. It doesn't mention prerequisites (e.g., an active browser session), exclusions (e.g., not for mobile browsers), or comparisons to siblings like browser_take_screenshot for visual changes. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, openWorldHint=true, and destructiveHint=true, indicating this is a mutable, open-ended, and potentially destructive action. The description adds minimal behavioral context beyond this, as 'Select an option' implies mutation but doesn't detail effects like page changes or side effects. It doesn't contradict annotations, so a baseline 3 is appropriate given the annotations cover key traits.
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 with zero waste: 'Select an option in a dropdown' directly conveys the core purpose without fluff. Every word earns its place, making it highly 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 complexity (interactive UI action with 3 required parameters), annotations cover safety and openness, but there's no output schema. The description is minimal and doesn't address return values or error conditions, leaving gaps. It's adequate for basic understanding but incomplete for robust agent use, scoring a minimum viable 3.
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 descriptions for all three parameters (element, ref, values). The description adds no additional parameter semantics beyond what the schema provides, such as examples or edge cases for values. Since the schema does the heavy lifting, the baseline score of 3 is justified.
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 ('Select an option') and target ('in a dropdown'), which is specific and distinguishes it from siblings like browser_click or browser_fill_form. However, it doesn't explicitly differentiate from browser_handle_dialog or browser_type, which could also involve selection interactions, making it slightly less precise 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., needing a snapshot first), exclusions (e.g., not for non-dropdown elements), or comparisons to siblings like browser_click for general 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?
The description adds minimal behavioral context beyond annotations. Annotations already declare destructiveHint=true and readOnlyHint=false, indicating mutation capability. The description confirms this with 'close' action but doesn't add meaningful context about what gets destroyed (tab state, unsaved data), authentication needs, or rate limits. 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 perfectly concise with a single, front-loaded sentence that lists all four actions. Every word earns its place with zero redundancy or unnecessary elaboration. The structure immediately communicates the tool's scope without preamble.
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 (four distinct actions, destructive operations) and rich annotations but no output schema, the description is minimally adequate. It covers the basic purpose but lacks guidance on usage context, behavioral details, or return values. The annotations help but don't fully compensate for the description's gaps in a multi-action 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?
With 100% schema description coverage, the schema fully documents both parameters. The description adds no parameter-specific semantics beyond implying the four action values. It doesn't explain index usage nuances or default behaviors beyond what's in the schema. Baseline 3 is appropriate when schema carries the full parameter documentation burden.
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 with specific verbs (list, create, close, select) and resource (browser tab). It distinguishes from siblings by focusing on tab management rather than navigation, interaction, or monitoring. However, it doesn't explicitly differentiate from close-related siblings like browser_close.
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 when to prefer browser_close for closing browsers versus this tool for closing tabs, or when to use browser_navigate versus creating a new tab. No explicit when/when-not statements or alternative tool references are included.
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 semantics. The description adds minimal behavioral context beyond this, mentioning typing into an element but not detailing side effects like potential page changes or error conditions. It doesn't contradict annotations, but adds little value over them.
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 and target, making it highly efficient and easy to parse for an AI agent.
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 5 parameters and no output schema, the description is minimal. It covers the basic purpose but lacks context on error handling, performance implications, or typical use cases. Given the rich schema and annotations, it's adequate but leaves gaps in practical guidance.
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 parameters. The description adds no additional meaning about parameters like 'element', 'ref', or 'text' beyond what's in the schema. Baseline 3 is appropriate when the schema does all 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 'Type text into editable element' clearly states the action (type) and target (editable element), distinguishing it from siblings like browser_click or browser_fill_form. However, it doesn't explicitly differentiate from browser_press_key which could also input text, so it's not 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 like browser_fill_form or browser_press_key. It doesn't mention prerequisites (e.g., needing a page snapshot) or exclusions, 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 already declare readOnlyHint=true and destructiveHint=false, indicating a safe, non-mutating operation. The description adds context by specifying what the tool waits for (text appearance/disappearance or time), which is useful beyond annotations. However, it lacks details on timeout behavior, error handling, or interaction with other browser tools, leaving some behavioral aspects unclear.
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 functionality without unnecessary words. Every part earns its place by covering the key actions (wait for text appear/disappear or time pass), 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 moderate complexity (3 parameters, no output schema) and rich annotations (readOnlyHint, openWorldHint), the description is adequate but incomplete. It covers what the tool does but lacks details on return values (e.g., success/failure indicators), error cases, or integration with sibling tools. With no output schema, more return information 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?
Schema description coverage is 100%, with clear descriptions for each parameter (time, text, textGone). The description adds minimal value by mentioning these parameters generally but doesn't provide additional semantics like usage examples, constraints (e.g., time must be positive), or how parameters interact (e.g., if both text and textGone are provided). 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 clearly states the tool's purpose as waiting for text to appear/disappear or for time to pass, which is a specific action. It distinguishes itself from siblings like browser_click or browser_navigate by focusing on waiting rather than direct interaction. However, it doesn't explicitly differentiate from all siblings (e.g., browser_handle_dialog might also involve waiting).
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 (e.g., not for waiting on network requests), or comparisons to similar tools like browser_handle_dialog for waiting on dialogs. Usage is implied but not explicitly defined.
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, confirming this is a destructive write operation. The description adds context by specifying 'the page' as the target, which clarifies scope beyond annotations. It doesn't contradict annotations, and while it doesn't detail side effects (e.g., data loss, confirmation dialogs), it provides useful behavioral context that annotations alone don't cover.
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—just three words—and front-loaded with the core action. Every word earns its place by directly conveying the tool's function without any fluff or redundancy, making it highly 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 complexity (simple destructive action), annotations cover safety (destructive) and mutability (not read-only), and there are 0 parameters, the description is minimally adequate. However, it lacks details on output (no schema provided) and could benefit from more context on what 'page' refers to (e.g., current tab vs. browser window). It meets basic needs but has gaps in completeness.
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 details, but this is appropriate given the lack of parameters. Baseline is 4 for 0 parameters, as the description doesn't need to compensate for any gaps.
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 the page' clearly states the action (close) and target (page), but it's somewhat vague about scope—does it close the current tab, the entire browser, or something else? It distinguishes from siblings like browser_navigate or browser_tabs by focusing on termination rather than navigation or inspection, but lacks specificity on what exactly is being closed.
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 explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., needing an open page), exclusions, or comparisons to siblings like browser_tabs (which might list tabs) or browser_navigate_back (for navigation). Usage is implied by the action alone, with no contextual advice.
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 destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a state-changing action ('press'). The description adds no additional behavioral context about side effects, timing, or error conditions, but doesn't contradict annotations. With annotations covering the safety profile, 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?
Extremely concise single sentence with zero wasted words. The description is front-loaded with the core action and gets straight to the point without any unnecessary elaboration or formatting.
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 single-parameter destructive action with good annotations but no output schema, the description is minimally adequate. It states what the tool does but lacks context about browser state requirements, expected outcomes, or error handling that would be helpful for an agent.
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 'key' fully documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, meeting the baseline expectation when schema coverage is complete.
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 ('press') and target ('key on the keyboard'), making the purpose immediately understandable. It distinguishes from siblings like browser_type (continuous typing) and browser_click (mouse action). However, it doesn't specify this is for browser automation versus general keyboard input.
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 like browser_type or browser_click. The description provides no context about appropriate use cases, 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 provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation. The description adds context by specifying it captures an 'accessibility snapshot,' which suggests it might include metadata like ARIA roles or contrast ratios, beyond a visual screenshot. However, it doesn't detail what exactly is captured, the format, or any behavioral traits like rate limits or permissions. With annotations covering safety, the description adds some value but lacks rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Capture accessibility snapshot of the current page, this is better than screenshot.' It's front-loaded with the core purpose and adds a comparative note without waste. Every part earns its place, 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 complexity (capturing accessibility data), annotations provide safety hints, but there's no output schema. The description hints at the output being an 'accessibility snapshot' but doesn't explain return values, format, or what makes it 'better.' For a tool with potential rich output and no output schema, the description is incomplete, leaving gaps in understanding the result.
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 is 1 parameter with 100% schema description coverage, so the schema fully documents the 'filename' parameter. The description doesn't add any parameter-specific information, which is acceptable given the high coverage. Since there's only one optional parameter, the baseline is 4, as the description doesn't need to compensate for gaps, and it's not misleading.
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: 'Capture accessibility snapshot of the current page' with a specific verb ('capture') and resource ('accessibility snapshot'). It distinguishes from the sibling 'browser_take_screenshot' by noting 'this is better than screenshot,' though it doesn't explicitly name the sibling. The purpose is clear but could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by contrasting with 'screenshot' (likely referring to 'browser_take_screenshot'), suggesting it's preferred for accessibility purposes. However, it doesn't explicitly state when to use this tool versus alternatives like 'browser_take_screenshot' or other siblings, nor does it provide context on prerequisites or exclusions. The guidance is implied but not comprehensive.
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 openWorldHint=true, which the description doesn't contradict. The description adds valuable context beyond annotations by specifying that the code will be executed with a page argument for interactions, which helps the agent understand the execution environment. However, it doesn't mention potential side effects like page navigation or resource consumption that destructiveHint=true implies.
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 'Run Playwright code snippet' is extremely concise at just four words, front-loading the core purpose without any wasted words. Every element earns its place by clearly communicating the tool's function in minimal space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (executing arbitrary code with destructive potential) and the absence of an output schema, the description is somewhat incomplete. It doesn't explain what the tool returns (e.g., the result of the executed function) or error handling. However, annotations provide safety context, and the schema covers the parameter well, making it minimally adequate but with clear gaps for a code execution 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 the parameter 'code' fully documented in the schema as a JavaScript function containing Playwright code. The description doesn't add any additional parameter semantics beyond what's already in the schema. With high schema coverage, the baseline score of 3 is appropriate since the description doesn't compensate but also doesn't need to.
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 'Run Playwright code snippet' clearly states the action (run) and resource (Playwright code snippet), making the purpose immediately understandable. It distinguishes from siblings by focusing on executing arbitrary code rather than specific browser actions like click or navigate. However, it doesn't explicitly mention browser automation context, which could make the distinction slightly less sharp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing custom Playwright scripts, suggesting it should be used when specific browser actions aren't available as dedicated tools. However, it doesn't provide explicit guidance on when to use this vs alternatives like browser_click or browser_type, nor does it mention prerequisites like needing an active browser session. The context is clear but lacks explicit alternatives 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds context about the action limitation (can't perform actions based on screenshot) and the viewport vs element screenshot behavior, but doesn't provide details about return format, error conditions, or performance characteristics.
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 consists of just two sentences that are completely front-loaded with essential information. Every word serves a purpose - the first sentence states the core function, the second provides critical usage guidance. There's zero wasted verbiage.
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?
For a read-only tool with comprehensive parameter documentation and clear annotations, the description provides adequate context. The main gap is the lack of output schema, but the description compensates somewhat by clarifying the tool's limitations relative to browser_snapshot. It could benefit from mentioning what the tool returns (presumably an image file reference).
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 already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation when schema coverage is complete.
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 provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 explicitly provides when-not-to-use guidance: 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This gives clear alternative usage context and distinguishes between screenshot capture versus interactive snapshot tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, implying a state-changing operation. The description adds context by specifying it navigates to the 'previous page', which aligns with annotations and clarifies the action beyond just 'destructive'. No contradiction with 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, front-loaded sentence with zero waste. It's appropriately sized for a simple, parameterless tool and gets straight to the point.
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 annotations covering safety (destructive), the description is complete enough. However, it could briefly mention browser state dependency or error cases for full completeness.
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. The description doesn't need to explain parameters, and it efficiently states the action without redundancy.
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 verb ('go back') and resource ('previous page'), distinguishing it from siblings like 'browser_navigate' (forward navigation) and 'browser_tabs' (tab management). It's specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in a browser context after navigation has occurred, but it doesn't explicitly state when not to use it or name alternatives. It provides clear context but lacks exclusions or direct sibling comparisons.
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 destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds valuable context about when to use the tool (error recovery scenario) that goes beyond what annotations provide. However, it doesn't mention potential side effects like system changes or installation time, which would be helpful additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the purpose, the second provides usage guidance. Every word earns its place, and the most important information (what it does) comes first.
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?
For a destructive tool with no parameters and no output schema, the description provides good context about purpose and usage. However, it doesn't mention what 'the config' refers to or what happens after installation (e.g., whether browser becomes available immediately), leaving some contextual gaps despite the tool's simplicity.
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, the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, and instead focuses on the tool's purpose and usage context, which adds semantic value beyond the empty schema.
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 ('Install') and resource ('the browser specified in the config'), distinguishing it from all sibling tools which are browser interaction commands rather than setup/installation tools. It provides explicit differentiation by focusing on installation rather than runtime operations.
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 when-to-use guidance: 'Call this if you get an error about the browser not being installed.' This gives clear context for invocation and implicitly suggests alternatives (don't call it unless you encounter that specific error condition).
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/Angeluis001/playwright-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Angeluis001/playwright-mcp)

Score Badge

Copy to your README.md:

[![playwright-mcp MCP server](https://glama.ai/mcp/servers/Angeluis001/playwright-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Angeluis001/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/Angeluis001/playwright-mcp'

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