MCP Playwright CDP

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 playwright_click and playwright_select as both interact with page elements, which could cause minor confusion. The HTTP methods (GET, POST, PUT, PATCH, DELETE) are clearly differentiated, and other tools like playwright_navigate, playwright_screenshot, and playwright_evaluate have unique functions.
Naming Consistency5/5
All tool names follow a consistent 'playwright_' prefix with a verb or action (e.g., click, get, navigate), using snake_case uniformly. This predictable pattern makes it easy for agents to understand and navigate the tool set without naming conflicts or style variations.
Tool Count5/5
With 12 tools, the count is well-scoped for a Playwright CDP server, covering essential web automation tasks like navigation, interaction, HTTP requests, and debugging. Each tool serves a specific purpose, avoiding bloat while providing comprehensive functionality for the domain.
Completeness4/5
The tool set covers key areas: navigation, element interaction, HTTP methods, and debugging (screenshot, evaluate). Minor gaps exist, such as missing tools for handling cookies, waiting for elements, or managing browser contexts, but core workflows are well-supported, allowing agents to perform most common automation tasks.
Average 2.8/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Select') but doesn't explain what this entails—e.g., whether it triggers events, changes page state, requires specific permissions, or has side effects. For a tool that likely modifies page state (selecting a dropdown option), this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/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 function. It's front-loaded with the core action and target, with no wasted words. However, the phrasing 'Select tag' could be slightly ambiguous, slightly reducing clarity.
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 no annotations and no output schema, the description is incomplete for a tool that likely performs page interactions. It doesn't cover behavioral aspects (e.g., what happens after selection), error conditions, or return values. For a 2-parameter tool in a web automation context, this leaves too many gaps for reliable 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 descriptions for both parameters (selector and value). The description adds no additional meaning beyond the schema, such as examples or constraints (e.g., selector must target a <select> element). Baseline 3 is appropriate since the schema adequately documents parameters.
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 states the action ('Select an element') and target ('on the page with Select tag'), which clarifies the tool's purpose. However, it's somewhat vague about what 'Select tag' specifically means (HTML <select> element vs. general selection), and it doesn't distinguish this from sibling tools like playwright_click or playwright_fill, which also interact with page elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 page loaded), exclusions, or comparisons to siblings like playwright_fill (for input fields) or playwright_click (for buttons), 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the HTTP method but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'DELETE' implies (e.g., resource removal). This is a significant gap for a mutation tool with zero annotation coverage.
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 appropriately sized and front-loaded, clearly stating the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an HTTP DELETE operation (a mutation tool), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or prerequisites, leaving critical 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?
Schema description coverage is 100%, with the parameter 'url' clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as URL format constraints or examples, so it meets the baseline of 3 when the schema does the heavy lifting.
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 states the action ('Perform an HTTP DELETE request') which is a specific verb, but it doesn't mention what resource this operates on or distinguish it from siblings like playwright_patch or playwright_put. It's vague about the actual target beyond 'HTTP'.
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 playwright_patch or playwright_put. The description lacks context about appropriate scenarios or exclusions, leaving the agent to infer usage based on HTTP method knowledge alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Navigate to a URL' implies a navigation action but does not disclose key traits like whether it loads a page in a browser, handles redirects, requires network connectivity, or has side effects (e.g., changing browser state). This leaves significant gaps in understanding the tool's behavior.
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, 'Navigate to a URL', which is front-loaded and wastes no words. It efficiently conveys the core action without unnecessary elaboration, making it easy to parse.
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 a navigation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on what the tool returns (e.g., page content, status), error handling, or how it integrates with other playwright tools, leaving the agent with insufficient context for effective 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?
The input schema has 80% description coverage, providing details for parameters like width, height, timeout, and waitUntil. The description does not add meaning beyond the schema, as it only mentions 'a URL' without explaining parameter usage or interactions. With high schema coverage, the baseline is 3, but the description does not compensate for the 20% gap (e.g., explaining the 'url' parameter further).
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 (a URL), which is a specific verb+resource. However, it does not distinguish this tool from its siblings like 'playwright_get' or 'playwright_post', which might also involve navigation or URL interactions, leaving the purpose somewhat vague in 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 does not mention any context, prerequisites, or exclusions, such as how it differs from other playwright tools like 'playwright_get' for HTTP requests or 'playwright_screenshot' for capturing pages after navigation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but doesn't disclose behavioral traits such as error handling, authentication needs, rate limits, side effects (e.g., modifying page state), or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, clearly stating 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an HTTP PATCH tool (a mutation operation) with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, and expected outcomes, making it insufficient for safe and effective use by an AI 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%, so the schema already documents both parameters ('url' and 'value') adequately. The description doesn't add any meaning beyond what the schema provides, such as examples or constraints, but the baseline is 3 since the schema does the heavy lifting.
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 states the action ('Perform an HTTP PATCH request'), which is clear but generic. It doesn't specify what resource or domain this operates on (e.g., web pages, APIs), and while it distinguishes from siblings like 'playwright_get' or 'playwright_post' by specifying PATCH, it lacks specificity about the context (e.g., browser automation vs. general HTTP).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a page loaded), exclusions, or comparisons to siblings like 'playwright_put' or 'playwright_post', leaving the agent to infer usage based on the HTTP method alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't describe traits like authentication needs, rate limits, error handling, or what the response might look like (e.g., status codes, body content). For a tool that performs HTTP operations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary details, 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?
Given the complexity of HTTP POST requests and the lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral aspects like idempotency or side effects. For a tool with no structured support, this minimal description leaves critical gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (url and value) with descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 an HTTP POST request' states the action (POST) and resource type (HTTP request), which is clear but vague. It doesn't specify what kind of POST request (e.g., to a web page, API endpoint) or distinguish it from siblings like playwright_put or playwright_patch, which are also HTTP methods.
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 POST over PUT or PATCH (sibling tools), nor does it specify any prerequisites or contexts for usage, such as needing a valid URL or specific data formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the basic action but doesn't mention important behavioral traits like: whether this waits for element visibility, handles retries, triggers page navigation, requires specific page state, or what happens on failure. The description is minimal and lacks operational 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 - a single sentence that directly states the tool's purpose. There's zero waste or unnecessary elaboration, making it front-loaded and efficient for an agent to parse.
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 this is an action tool with no annotations, no output schema, and minimal description, the completeness is inadequate. For a tool that performs page interactions, the description should address more about execution context, error handling, and behavioral expectations beyond the basic action statement.
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% (the 'selector' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema - it doesn't explain selector best practices, provide examples, or discuss edge cases.
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 ('click') and target ('an element on the page'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling interactions like 'hover' or 'select' beyond the obvious action difference.
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. While the action is self-explanatory, there's no mention of prerequisites (e.g., element must be visible), error conditions, or comparison to similar tools like 'playwright_hover' or 'playwright_select'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical details: it doesn't specify execution context (e.g., current page, frame), error handling, security implications, or what happens if the script fails. This is a significant gap for a tool that executes arbitrary code.
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, direct sentence with no wasted words. It's front-loaded with the core action, making it easy to understand at a glance while remaining complete in its basic statement.
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 executing JavaScript in a browser (which can have side effects, errors, and security considerations), the description is inadequate. With no annotations, no output schema, and minimal behavioral details, it fails to provide enough context for safe and effective use, especially compared to sibling tools that are more straightforward (e.g., playwright_click).
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 schema description coverage is 100%, with the single parameter 'script' clearly documented as 'JavaScript code to execute'. The description adds no additional meaning beyond this, such as examples of valid scripts or constraints. However, since the schema fully covers the parameter, the baseline score of 3 is appropriate.
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 ('Execute JavaScript') and the context ('in the browser console'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like playwright_get or playwright_navigate, which might also involve browser interaction but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where executing JavaScript is preferred over other playwright tools (e.g., for dynamic content manipulation vs. simple navigation), nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't cover key traits such as whether it waits for the element to be visible, handles errors if the selector is invalid, or interacts with the DOM in a specific way (e.g., triggering events). This leaves significant gaps in understanding the tool's behavior.
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 'fill out an input field' is extremely concise—just four words—and front-loaded with the core action. There is no wasted language, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a browser automation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., error handling, timing), usage context, and what the tool returns, which are crucial for effective agent use in this domain.
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 both parameters (selector as CSS selector, value as value to fill). The description doesn't add any additional meaning beyond this, such as examples or constraints, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'fill out an input field' clearly states the action (fill) and target (input field), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like playwright_click or playwright_select, which might also interact with input fields in different ways.
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 form completion, text entry, or how it differs from similar tools like playwright_click (for buttons) or playwright_select (for dropdowns), leaving usage context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but lacks critical details: it doesn't mention authentication needs, rate limits, error handling, response format, or whether it follows redirects. For a network tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Perform an HTTP GET request')—a single, front-loaded sentence with zero waste. It efficiently communicates the core action without unnecessary words, 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?
Given the complexity of HTTP requests and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication, error handling, or response structure, which are crucial for an agent to use this tool effectively. The description fails to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'url' parameter fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples or constraints on URL format). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
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 an HTTP GET request') with a specific verb ('GET') and resource ('HTTP request'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (like playwright_post or playwright_patch) beyond the HTTP method, missing explicit 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. With siblings like playwright_post, playwright_put, and playwright_patch available, there's no indication of when GET is appropriate (e.g., for retrieving data) versus when other methods should be used, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the action but doesn't mention potential side effects (e.g., triggering hover states, tooltips, or animations), error conditions (e.g., if selector not found), or performance implications. This leaves significant gaps for a tool that interacts with dynamic page elements.
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 ('Hover an element on the page') that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that performs a UI interaction. It doesn't explain what happens after hovering (e.g., does it wait for effects, return success/failure, or trigger events?), leaving the agent with insufficient context to use it effectively in complex scenarios.
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 'selector' parameter clearly documented as a CSS selector. The description doesn't add any meaning beyond this, such as examples of valid selectors or tips for targeting elements. Given the high schema coverage, the baseline score of 3 is appropriate.
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 an element on the page' clearly states the action (hover) and target (element on page), providing a specific verb+resource. However, it doesn't differentiate from sibling tools like playwright_click or playwright_select, which also interact with page elements, leaving some ambiguity about when to use hover versus other interactions.
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 playwright_click, playwright_fill, and playwright_select available, there's no indication of whether hovering is for triggering UI effects, inspecting elements, or other purposes, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits like authentication requirements, error handling, response format, rate limits, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or important behavioral aspects. For a tool that performs HTTP PUT operations, 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?
Schema description coverage is 100%, so the schema already documents both parameters (url and value). The description doesn't add any meaning beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform an HTTP PUT request') with a specific HTTP verb. It distinguishes from siblings like playwright_get, playwright_post, and playwright_delete by specifying the PUT method. However, it doesn't explicitly mention what resource it operates on beyond HTTP endpoints.
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 explain when PUT is appropriate compared to POST, PATCH, or other HTTP methods, nor does it mention any prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'take a screenshot' but doesn't disclose critical traits like whether it's a read-only operation, if it requires specific page states, potential side effects (e.g., page reload), or output format details beyond parameters. This leaves significant gaps for a tool with 7 parameters.
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 any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It lacks context about the tool's behavior, output format (beyond parameter hints), error conditions, or integration with other Playwright tools. This leaves the agent with significant uncertainty about how to effectively use it.
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 clear documentation for all 7 parameters. The description adds no parameter-specific information beyond implying 'current page' as a default when selector isn't specified, which is minimal value. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Take a screenshot') and target ('current page or a specific element'), which is specific and unambiguous. However, it doesn't differentiate this tool from potential screenshot-related siblings (none exist in the provided list), so it doesn't reach the highest score of 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. There's no mention of prerequisites (e.g., requiring a page to be loaded), comparison with other screenshot methods, or scenarios where it's preferred over other tools like playwright_get for capturing content.
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:

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

Score Badge

Copy to your README.md:

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

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/lars-hagen/mcp-playwright-cdp'

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