Playwright MCP

Server Quality Checklist

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

Latest release: v1.0.5
Disambiguation4/5
Most tools have distinct purposes, such as browser_click for clicking, browser_fill_form for form filling, and browser_take_screenshot for screenshots. However, some overlap exists: browser_snapshot and browser_take_screenshot both capture page states, and browser_evaluate and browser_run_code both execute JavaScript, which could cause confusion. Descriptions help clarify differences, but the overlap is noticeable.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with a 'browser_' prefix for most tools, such as browser_click, browser_navigate, and browser_wait_for. The only exception is health_check, which still uses snake_case and fits the overall style. This consistency makes the tool set predictable and easy to navigate.
Tool Count3/5
With 23 tools, the count is on the higher side for a Playwright automation server, which typically involves many actions. It feels slightly heavy but reasonable given the domain's complexity. However, it borders on being overwhelming, as some tools might be combined or streamlined to reduce the number without losing functionality.
Completeness5/5
The tool set provides comprehensive coverage for web automation tasks, including navigation, interaction (click, type, hover), form handling, file uploads, dialog management, and debugging (console messages, network requests). It also includes utility functions like health_check and browser_install, ensuring no obvious gaps for common Playwright workflows. The surface is well-rounded and supports full automation lifecycles.
Average 3.5/5 across 23 of 23 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
Tools from this server were used 22 times in the last 30 days.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, suggesting this tool performs a mutation. The description doesn't contradict these annotations, as 'handle' implies an action that could change state. However, it adds minimal behavioral context beyond annotations—it doesn't specify what happens when a dialog is handled (e.g., dismissed, accepted, or text entered) or any side effects like page changes. The description compensates slightly by implying interaction with dialogs, but lacks detail on behavior traits like error handling or prerequisites.
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, making it 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 or redundant phrasing, which aligns with efficient communication despite the lack of detail.
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 complexity of handling dialogs (which can involve various types like alerts, prompts, or confirmations), the description is incomplete. With no output schema and annotations that only hint at destructiveness, the description fails to explain what the tool returns or how it behaves in different scenarios. Sibling tools like browser_wait_for might overlap in functionality, but no context is provided to differentiate or guide usage, leaving significant gaps for an agent to understand when and how to invoke this tool effectively.
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 additional meaning beyond the schema, such as explaining when promptText is required or how accept interacts with dialog types. Since the schema fully covers parameters, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding.
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 merely restates the tool name without specifying what kind of dialog or what handling entails. It doesn't distinguish this tool from sibling tools like browser_click or browser_press_key, which also handle UI interactions. The verb 'handle' is vague compared to more specific sibling actions like 'click', 'navigate', or 'type'.
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 types of dialogs it handles (e.g., alerts, prompts, confirmations) or under what conditions it should be invoked. With siblings like browser_wait_for that might interact with dialogs indirectly, there's no context to help an agent choose appropriately.
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 operation. The description adds minimal behavioral context beyond this, mentioning 'file chooser is cancelled' if paths are omitted, which hints at interactive behavior. It doesn't elaborate on side effects like overwriting files or UI changes, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise ('Upload one or multiple files'), which is efficient and front-loaded. However, it's arguably too brief for a tool with complex behavioral implications (destructive, open-world), missing explanatory context that could help the agent. Every word earns its place, but more detail might be warranted.
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 (destructive mutation, open-world, no output schema) and rich annotations, the description is incomplete. It lacks details on expected outcomes, error handling, or integration with browser state. While annotations cover safety, the description should provide more context about how uploads work in the browser environment to guide the agent effectively.
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 'paths' parameter fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., no details on file types, size limits, or upload mechanisms). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate with extra insights.
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 ('files'), specifying it can handle 'one or multiple files'. It distinguishes from siblings like browser_navigate or browser_take_screenshot by focusing on file uploads, though it doesn't explicitly differentiate from all browser tools. The purpose is specific but could be more precise about the browser context.
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 session), context (e.g., for file inputs in web forms), or exclusions. With many sibling tools, this lack of usage context leaves the agent to infer when upload is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide significant behavioral information: readOnlyHint=false (mutation), openWorldHint=true (dynamic environment), and destructiveHint=true (potentially changes state). The description adds minimal context beyond this - it confirms the action is a click but doesn't elaborate on what gets destroyed, potential side effects, or rate limits. The description doesn't contradict annotations, but adds little value beyond what annotations already declare.
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 5 words, with zero wasted language. It's front-loaded with the core action and immediately states what the tool does. Every word earns its place, making this description highly efficient despite its brevity.
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 5 parameters and no output schema, the description is insufficient. It doesn't explain what happens after a click (navigation, form submission, etc.), error conditions, or return values. The annotations help but don't compensate for the lack of behavioral context in the description itself. Given the complexity of browser interactions, more guidance 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?
With 100% schema description coverage, all parameters are already documented in the input schema. The description adds no additional parameter semantics - it doesn't explain the relationship between 'element' and 'ref', when to use doubleClick, or practical examples of modifier usage. The baseline score of 3 is appropriate since the schema does the heavy lifting for 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 clearly states the action ('perform click') and resource ('on a web page'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like browser_press_key or browser_select_option, which also involve user interactions on web pages. The description is specific 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. It doesn't mention when clicking is appropriate compared to other interaction methods like typing, hovering, or selecting options. There's no indication of prerequisites (e.g., needing a page snapshot first) or exclusions, leaving 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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no behavioral context beyond what annotations provide, such as rate limits, authentication needs, or what 'all console messages' entails (e.g., format, 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 with a single sentence ('Returns all console messages'), which is front-loaded and wastes no words. Every word earns its place by directly stating the tool's core 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?
Given the tool's low complexity (1 parameter, 100% schema coverage, read-only operation), the description is minimally adequate. However, with no output schema, it doesn't explain return values (e.g., message format, structure), leaving a gap in completeness for the 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 'level' fully documented in the schema. The description adds no parameter semantics beyond what the schema provides, as it doesn't mention parameters at all. Baseline 3 is appropriate 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 clearly states the tool's purpose with a specific verb ('Returns') and resource ('all console messages'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'browser_network_requests' or 'browser_snapshot', 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name and purpose 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 destructiveHint=true and readOnlyHint=false, which the description doesn't contradict (it implies mutation via 'drag and drop'). However, the description adds minimal behavioral context beyond annotations—it doesn't explain what 'destructive' means here (e.g., element state changes) or mention potential side effects like page reloads. 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, direct sentence with zero wasted words. It front-loads the core action ('Perform drag and drop') and specifies the scope ('between two elements') efficiently, 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?
For a destructive tool with no output schema, the description is minimal but covers the basic purpose. It lacks details on error conditions, performance implications, or integration with sibling tools like browser_snapshot for obtaining references. Given the annotations provide safety context, it's adequate but not 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 clear descriptions for all four parameters (e.g., 'Human-readable source element description'). The description adds no additional parameter semantics beyond the schema, such as explaining how startRef and endRef relate to browser_snapshot. 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 action ('perform drag and drop') and the target ('between two elements'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like browser_click or browser_hover, which also involve element interaction but with 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. It doesn't mention prerequisites (e.g., needing a browser session or element references), nor does it compare to siblings like browser_click for simpler interactions or browser_file_upload for drag-and-drop file operations.
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 critical information (destructiveHint: true, readOnlyHint: false, openWorldHint: true), but the description adds some context by specifying that evaluation occurs 'on page or element' and implies interaction with elements. However, it doesn't elaborate on risks like potential page modifications or security implications beyond what annotations 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 with just one sentence that directly states the tool's purpose. It's front-loaded with no wasted words, making it easy to parse quickly while still 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 (JavaScript evaluation with destructive potential) and lack of output schema, the description is minimally adequate. It covers the basic action but doesn't address return values, error conditions, or the scope of what 'Evaluate' entails, leaving gaps for the agent to infer.
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 three parameters. The description adds minimal value by hinting at the relationship between 'function' and 'element' parameters, but doesn't provide additional syntax, examples, or constraints beyond what's in the schema 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 verb 'Evaluate' and the resource 'JavaScript expression on page or element', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'browser_run_code' 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_run_code' or other browser interaction tools. It lacks context about appropriate use cases, prerequisites, or exclusions, leaving the agent with minimal 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 indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds minimal behavioral context beyond annotations—it implies navigation changes the browser state but doesn't detail effects like page loading, potential errors, or interaction with other tools. With annotations covering safety, it earns a baseline score for not adding significant 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 'Navigate to a URL', using only three words to convey the core action. It's front-loaded and wastes no space, making it efficient for quick understanding 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 moderate complexity (navigation with destructive potential) and rich annotations (destructiveHint, openWorldHint), the description is minimally adequate. It lacks details on output or error handling, but annotations provide safety context. Without an output schema, more behavioral info would help, but it meets a basic threshold.
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 single parameter 'url' fully documented in the schema. The description doesn't add any semantic details beyond what the schema provides, such as URL format examples or validation rules. Baseline score 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.
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 immediately understandable. It distinguishes from siblings like browser_click or browser_type by focusing on URL navigation rather than interaction or input. However, it doesn't specify the browser context or differentiate from browser_navigate_back, keeping it from 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 like needing an open browser, compare to browser_navigate_back for backward navigation, or indicate when other tools like browser_wait_for might be needed after navigation. This lack of context leaves 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 already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds the temporal constraint 'since loading the page,' which provides useful behavioral context not in the annotations. However, it lacks details on output format, pagination, or rate limits, keeping it at a baseline level.
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 no wasted words. It front-loads the core functionality efficiently, making it easy for an agent to parse and 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 (1 parameter, no output schema) and rich annotations, the description is minimally adequate. It covers the basic action but lacks details on output structure or error handling, which could be helpful for an agent despite the 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?
Schema description coverage is 100%, with the single parameter 'includeStatic' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline score without compensating for gaps.
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'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'browser_console_messages' or 'browser_snapshot' that might also provide browser activity insights, 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 like debugging network issues, monitoring performance, or how it complements other browser tools, 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 destructiveHint=true and readOnlyHint=false, indicating this is a write operation that can change state. The description doesn't add behavioral context beyond this, such as what happens if no browser is open, whether it waits for page load, or if it has side effects like triggering events. It doesn't contradict annotations but adds minimal value beyond 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 efficiently communicates the essential function without unnecessary elaboration. Every word earns its place, 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?
For a single-parameter tool with full schema coverage and annotations covering safety (destructive) and scope (openWorld), the description is minimally adequate. However, it lacks context about the browser environment, error conditions, or what constitutes valid key names beyond the schema examples. Without an output schema, it doesn't describe return values or success indicators.
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 'key' parameter fully documented in the schema as 'Name of the key to press or a character to generate'. The description adds no additional parameter semantics beyond what the schema provides, such as examples beyond ArrowLeft/a or special key combinations. 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 action ('Press') and target ('a key on the keyboard'), making the purpose immediately understandable. It distinguishes from siblings like browser_type (which types text) and browser_click (which clicks mouse), though it doesn't explicitly mention these distinctions. The description is specific but could be more precise about scope.
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 choose browser_press_key over browser_type (for single keys vs text input) or browser_click (for mouse interactions), nor does it specify prerequisites like requiring an active browser session. Usage context is implied but not 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 indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=true, covering key behavioral traits. The description adds no additional context beyond the basic action, such as effects on browser state or potential side effects. It does not contradict annotations, but offers minimal value beyond 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, direct sentence with zero wasted words, making it highly efficient and front-loaded. It conveys the core action without unnecessary elaboration, which is ideal for a simple tool like this.
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, two well-documented parameters, and annotations covering key behaviors, the description is minimally adequate. However, with no output schema and destructiveHint=true, it could benefit from more detail on outcomes or errors, but the annotations partially compensate.
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 documentation for 'width' and 'height' parameters. The description does not add any semantic details beyond what the schema provides, such as unit explanations or valid ranges. Baseline score of 3 is appropriate given the schema's completeness.
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 verb ('Resize') and resource ('browser window'), making the purpose immediately understandable. However, it does not differentiate from sibling tools like 'browser_snapshot' or 'browser_take_screenshot' that also involve browser window manipulation, so it lacks sibling distinction for 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 does not mention prerequisites (e.g., an open browser window), exclusions, or comparisons to sibling tools like 'browser_snapshot' for capturing size changes, leaving 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 indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. However, the description adds minimal behavioral context beyond annotations—it doesn't explain what 'destructive' means here (e.g., changes page state) or mention permissions/rate limits, though annotations cover some 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, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, 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 (3 parameters, destructive operation) and lack of output schema, the description is minimal but adequate with good annotations. It could benefit from more context on usage or behavior, but annotations provide some safety information, making it passable.
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 well-documented in the schema. The description doesn't add any extra meaning about parameters like 'element' or 'ref', relying entirely on the schema. 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 'Select an option in a dropdown' clearly states the action (select) and target (option in a dropdown), making the purpose understandable. However, it doesn't differentiate from sibling tools like browser_click or browser_fill_form that might also interact with dropdowns, keeping it from 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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify if this is for single/multi-select dropdowns or how it differs from browser_click for dropdown interaction, leaving the agent without 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 indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=true, covering key behavioral traits like mutability and potential data loss. The description adds minimal context by listing actions, but doesn't elaborate on specifics like what 'close' destroys, auth needs, or rate limits. It doesn't contradict annotations, so it earns a baseline score for adding some value beyond the structured data.
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 and front-loaded, using a single sentence that efficiently lists all possible actions without any wasted words. Every part of the sentence directly contributes to understanding the tool's scope, making it well-structured 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 moderate complexity (multiple actions via a parameter), rich annotations, and no output schema, the description is somewhat complete but lacks details on return values or error handling. It covers the basic functionality but doesn't fully compensate for the absence of an output schema, leaving gaps in understanding the tool's full 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?
Schema description coverage is 100%, with clear descriptions for both parameters, including an enum for 'action' and details for 'index'. The description doesn't add meaning beyond the schema, such as explaining the semantics of 'new' versus 'select' or default behaviors. Given the high coverage, a baseline score of 3 is appropriate as the schema handles 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 clearly states the tool's purpose with specific verbs ('list, create, close, or select') and resource ('a browser tab'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'browser_close' or 'browser_navigate', which handle related but distinct browser operations, 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, such as distinguishing it from 'browser_close' for closing tabs or 'browser_navigate' for creating new tabs. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the action parameter alone.
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 the annotations (which show destructiveHint=true, readOnlyHint=false, openWorldHint=true). While the annotations already indicate this is a destructive, non-read-only operation, the description adds useful context by specifying it runs 'Playwright code snippet' - implying execution of arbitrary browser automation code, which aligns with the open-world nature.
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 4 words, front-loading the essential information with zero wasted words. Every element ('Run', 'Playwright', 'code', 'snippet') contributes directly to understanding the tool's purpose.
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 (destructiveHint=true) with no output schema, the description is insufficient. It doesn't explain what 'Run' entails operationally, what happens during execution, potential side effects, or what kind of results to expect. Given the complexity implied by arbitrary code execution and the destructive nature, more context 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?
With 100% schema description coverage, the input schema already fully documents the single 'code' parameter. The description doesn't add any additional parameter semantics beyond what's in the schema, so it 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 ('Run') and the resource ('Playwright code snippet'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like browser_evaluate or browser_click, which also execute browser 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention that this is for arbitrary Playwright code execution while siblings handle specific actions, nor does it provide any context about prerequisites or appropriate use cases.
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 (mutation) and openWorldHint=true (dynamic environment), which the description aligns with by implying form interaction. The description adds value by specifying 'multiple form fields,' suggesting batch capability, though it doesn't detail side effects like page reloads or validation triggers. 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 ('Fill multiple form fields') that is front-loaded with the core action. There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.
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 form filling with multiple field types) and rich schema coverage, the description is minimal but adequate. However, with no output schema and annotations only covering basic hints, it lacks details on error handling, success indicators, or interaction with page state, leaving some contextual gaps.
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 detailed parameter documentation in the schema itself. The description adds no additional parameter semantics beyond implying batch processing ('multiple'), which is already covered by the array type in the schema. Baseline score of 3 is appropriate as the schema handles most of the parameter explanation.
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 'Fill multiple form fields' clearly states the verb ('fill') and resource ('form fields'), and the 'multiple' qualifier distinguishes it from single-field tools like browser_type. However, it doesn't explicitly differentiate from browser_select_option (which handles comboboxes) or browser_click (which could interact with checkboxes/radio buttons).
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 like browser_type (for textboxes), browser_select_option (for comboboxes), or browser_click (for checkboxes/radio buttons). The description implies batch form filling but offers no explicit usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful context beyond annotations. While annotations indicate this is a destructive, non-read-only operation with open-world implications, the description clarifies this is a mouse interaction that simulates user behavior. It doesn't contradict annotations but provides specific behavioral context about what 'hover' means in a browser automation 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 extremely concise at just four words, front-loading the core action and target without any unnecessary elaboration. Every word earns its place, making it easy for an AI agent to quickly understand 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 moderate complexity (interactive browser action with destructive potential) and complete schema coverage but no output schema, the description is minimally adequate. It states what the tool does but doesn't explain what happens after hovering (e.g., does it wait for page changes? what's the return value?). The annotations help but don't fully compensate for the lack of behavioral details in the description.
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 fully documents both parameters ('element' and 'ref'). The description doesn't add any additional meaning about parameter usage, purpose, or relationships beyond what's in the schema. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('hover over') and target ('element on page'), providing a specific verb+resource combination. It distinguishes this from obvious siblings like 'browser_click' by specifying a different interaction type. However, it doesn't explicitly differentiate from more subtle siblings like 'browser_wait_for' which might also involve element interaction.
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 hovering is appropriate (e.g., to trigger dropdowns or tooltips) versus when clicking or other interactions are needed, nor does it reference any sibling tools as alternatives or complementary actions.
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 with open-world assumptions. The description adds value by specifying it captures an 'accessibility snapshot' (implying structured data like ARIA roles) rather than just a visual image, but doesn't detail output format, permissions, or rate limits. 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, efficient sentence that front-loads the core purpose and includes a comparative note. There is no wasted wording, 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 has annotations covering safety and world assumptions, and a simple input schema with full coverage, the description is minimally adequate. However, without an output schema, it doesn't explain what the snapshot returns (e.g., structured data vs. file), leaving a gap in completeness for a tool that implies specialized output.
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 one parameter 'filename' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as file format details or examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but 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 clearly states the tool captures an accessibility snapshot of the current page, specifying the verb 'capture' and resource 'accessibility snapshot'. It distinguishes from the sibling 'browser_take_screenshot' by noting it's 'better than screenshot', though it doesn't fully explain how it differs beyond that comparison.
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 comparing to 'browser_take_screenshot', suggesting this tool should be used when an accessibility snapshot is preferred over a regular screenshot. However, it lacks explicit guidance on when to choose this over alternatives or any prerequisites, leaving some context to inference.
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 (which indicate it's not read-only, is open-world, and destructive). While annotations cover the basic safety profile, the description adds useful behavioral context by specifying the target ('editable element'), which helps the agent understand this is for interactive typing rather than general text manipulation. However, it doesn't elaborate on potential side effects like triggering page events or form submissions.
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 immediately conveys the core functionality without any wasted words. It's perfectly front-loaded and appropriately sized for a straightforward 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?
For a destructive tool with no output schema, the description is minimally adequate. It identifies the action and target but doesn't explain what constitutes success/failure, how it interacts with page state, or potential error conditions. Given the annotations provide safety context and the schema covers parameters, the description meets basic requirements but lacks depth 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?
With 100% schema description coverage, the input schema already fully documents all 5 parameters. The description doesn't add any parameter-specific semantics beyond what's in the schema (like explaining how 'element' and 'ref' work together or when to use 'slowly'). This 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.
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 text) and target (editable element), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like browser_fill_form or browser_press_key, which might have overlapping functionality for text input scenarios.
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. There's no mention of when to choose browser_type over browser_fill_form (for form filling), browser_press_key (for keyboard input), or other text-input related siblings, leaving the agent without contextual 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 readOnlyHint=true and destructiveHint=false, indicating a safe, non-mutating operation. The description adds behavioral context by specifying what triggers the wait (text appearance/disappearance or time), which goes beyond annotations. However, it doesn't detail aspects like timeout behavior, concurrency, or error handling, leaving some 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 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), 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, the description is minimally adequate. It covers the basic purpose but lacks details on return values, error conditions, or integration with sibling tools. With annotations handling safety, completeness is borderline but not fully robust for a waiting operation in a browser 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 parameter descriptions for time, text, and textGone. The description adds minimal semantic value by mentioning these parameters implicitly ('text to appear or disappear or a specified time'), but doesn't clarify interactions (e.g., if multiple parameters are used together) or default behaviors. 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_type by focusing on waiting rather than interaction. However, it doesn't explicitly mention the browser context, which is implied but could be more precise.
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 scenarios (waiting for text changes or time), but lacks explicit guidance on when to use this versus alternatives like browser_network_requests for monitoring requests or browser_handle_dialog for pop-ups. No exclusions or prerequisites are mentioned, leaving usage context somewhat open-ended.
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 doesn't contradict. The description adds value by specifying 'the page' as the target, clarifying it closes a page rather than the entire browser or other resources, which is useful context 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, direct sentence with no wasted words, making it highly efficient and easy to understand. It's appropriately sized for a simple tool with no parameters.
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 adequate but minimal. It lacks details on effects (e.g., what happens to the page or browser state) or error conditions, which could be helpful for 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 doesn't add or detract from the schema, maintaining clarity for a parameterless tool.
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 (page), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like browser_tabs or browser_navigate_back, which might also involve page management, 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 page), exclusions, or comparisons to siblings like browser_tabs for tab management, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action ('perform a local system health check') and return value ('returns system information and configuration status'), but doesn't specify potential side effects, error conditions, performance characteristics, or authentication requirements. The description provides basic behavioral context but lacks depth for a diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the action and purpose, while the second explains the return value. There's zero wasted language, and the information is front-loaded with the most important details first.
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 no annotations and no output schema, the description provides basic context about what the tool does and what it returns. However, for a health check tool that presumably returns structured diagnostic information, the description could be more complete by specifying what 'system information and configuration status' includes or providing examples of typical output.
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 schema has 100% description coverage for its single optional parameter, so the baseline is 3. The description doesn't add parameter-specific information beyond what's in the schema, but since there's only one optional parameter and the tool's primary function doesn't depend on it, this represents minimal parameter burden. The description focuses appropriately on the core functionality.
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 tool's purpose with specific verbs ('perform', 'verify') and resources ('local system health check', 'Playwright MCP server configuration and connectivity'). It distinguishes itself from sibling tools by focusing on system diagnostics rather than browser interactions like clicking, navigating, or taking screenshots.
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 context ('to verify Playwright MCP server configuration and connectivity') but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided on prerequisites, timing, or exclusions, leaving the agent to infer 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 provide readOnlyHint=false, openWorldHint=true, and destructiveHint=true, indicating this is a mutable, open-ended, and potentially destructive operation. The description adds context by specifying it affects browser navigation (going back), which aligns with annotations but doesn't elaborate on risks like losing unsaved data or navigation limits. 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, efficient sentence ('Go back to the previous page') that is front-loaded with the core action. It wastes no words and directly communicates the tool's purpose without unnecessary elaboration.
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 low complexity (0 parameters, no output schema) and rich annotations, the description is complete enough for basic understanding. However, it could improve by mentioning potential side effects (e.g., page reloads, history dependence) or error cases, though annotations cover safety aspects.
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 does not discuss parameters, focusing on the tool's action. A baseline of 4 is applied as it compensates for the lack of parameters by being clear about the tool's function.
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 action (go back) and the resource (previous page), making the purpose specific and unambiguous. It distinguishes from siblings like 'browser_navigate' (which goes to a new page) and 'browser_close' (which closes the browser/tab).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you want to return to a previous page in browser navigation), but does not explicitly state when not to use it or name alternatives. For example, it doesn't clarify if this only works within a browsing session history or mention sibling tools like 'browser_navigate' for forward navigation.
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, suggesting a mutable, open-ended, and potentially destructive operation. The description adds context by specifying it's for installation triggered by errors, which aligns with these annotations and provides practical behavioral insight beyond the structured hints.
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 sentences that are front-loaded and efficient: the first states the purpose, and the second provides usage guidance. Every sentence adds value without redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (installation with destructive potential), annotations cover key behavioral aspects, and the schema fully documents parameters. The description adds usage context, but without an output schema, it could benefit from mentioning what happens post-installation (e.g., success confirmation). However, it's largely complete for its scope.
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 param details, but this is acceptable given the schema's completeness. A baseline of 4 is appropriate as it doesn't detract from the schema's clarity.
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 the resource ('browser specified in the config'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like browser_click or browser_navigate, which are interaction tools rather than setup tools, so it misses 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 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, helping the agent distinguish it from alternatives like browser_navigate or browser_run_code that assume an installed browser.
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 and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds context by clarifying that actions cannot be performed based on the screenshot, which is useful behavioral information beyond the annotations. However, it doesn't mention rate limits, authentication needs, or output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which earn their place. The first sentence states the core purpose, and the second provides crucial usage guidance. There is no wasted text, and information is front-loaded effectively.
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 (5 parameters, no output schema) and rich annotations (readOnlyHint, openWorldHint), the description is mostly complete. It covers purpose and usage guidelines well but lacks details on output format (e.g., what the screenshot returns) and behavioral constraints like rate limits. The annotations help compensate for some gaps.
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%, meaning all parameters are well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. No additional semantic value is provided for parameters like 'element' or 'fullPage'.
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 differentiates by stating 'use browser_snapshot for actions', making the purpose unambiguous and distinct.
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 versus alternatives: 'use browser_snapshot for actions' indicates this tool is for capturing screenshots without performing actions, while browser_snapshot is for interactive tasks. This clear distinction helps the agent choose correctly.
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/Playwright-os/Playwright-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Playwright-os/Playwright-MCP)

Score Badge

Copy to your README.md:

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

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