Playwright Server MCP

by ziux

Overview Schema Related Servers Score Discussions

Python

Local

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: navigation, session creation, HTML/text extraction, JavaScript evaluation, and action execution. However, 'playwright_action' is somewhat broad and could potentially overlap with more specific actions, but descriptions help clarify boundaries.
Naming Consistency5/5
All tools follow a consistent 'playwright_' prefix with snake_case naming, using descriptive nouns or verbs like 'navigate', 'evaluate', and 'get_html_content'. This pattern is predictable and readable throughout the set.
Tool Count5/5
With 6 tools, this is well-scoped for a Playwright automation server. Each tool serves a clear purpose in browser interaction, from session management to content retrieval, without feeling bloated or insufficient.
Completeness3/5
The set covers core browser automation tasks like navigation, session handling, and content extraction, but lacks explicit CRUD operations for elements (e.g., create/update/delete) and advanced interactions like waiting or screenshots. Agents can work around this, but notable gaps exist.
Average 3/5 across 6 of 6 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 but fails to do so. It doesn't mention that this is a mutation tool (e.g., for clicking, filling forms), its potential side effects, error handling, or performance characteristics. The description is too generic to inform the agent about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function. It's front-loaded and wastes no words, making it efficient for quick scanning, though this brevity contributes to its lack of detail 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?
For a complex tool with 23 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the tool's role in browser automation, the expected outcomes, or how it integrates with sibling tools. The high parameter count and lack of behavioral context make this description incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with detailed parameter descriptions in the input schema. The tool description adds no additional parameter semantics beyond what's already documented in the schema, such as explaining how parameters interact or providing examples. 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '根据给定的locator 和action 执行操作' (Execute an action based on given locator and action) is a tautology that restates the tool name 'playwright_action' without specifying what kind of actions it performs or what resources it operates on. It mentions 'locator' and 'action' but doesn't clarify this is for browser automation or web page interaction, making it vague and minimally informative.
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 like playwright_navigate, playwright_evaluate, or playwright_get_text_content. It lacks any context about prerequisites, typical use cases, or distinctions from sibling tools, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool executes JavaScript and returns results, but lacks details on execution context (e.g., page scope, timing), error handling, security implications, or performance considerations. For a tool that interacts with a browser, 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 that directly states the tool's function without unnecessary words. It's front-loaded with the core action and outcome, making it easy to parse. Every part of the sentence contributes 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?
Given the complexity of browser JavaScript execution and the lack of annotations and output schema, the description is incomplete. It doesn't address potential risks (e.g., script injection), execution environment details, or what the return values might look like (e.g., types of results). For a tool with no structured safety or output information, 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?
The description doesn't add parameter-specific information beyond what the input schema provides. The schema has 100% coverage with a clear description for the 'script' parameter. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate with additional semantics like script format examples or constraints.
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: '在浏览器控制台中执行JavaScript代码并返回执行结果' (Execute JavaScript code in the browser console and return the execution result). This specifies both the verb (execute JavaScript) and resource (browser console), though it doesn't explicitly differentiate from sibling tools like playwright_action or playwright_get_html_content, which may also involve browser 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. It doesn't mention scenarios where this is preferred over other sibling tools (e.g., playwright_get_html_content for DOM extraction) or any prerequisites, such as needing an active browser session. This leaves the agent without contextual usage cues.
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 context. It states what the tool does but doesn't disclose whether it's read-only/destructive, requires authentication, has rate limits, returns errors for invalid selectors, or what format the HTML content returns (full element vs inner HTML). The description doesn't contradict annotations since none exist, but provides inadequate behavioral transparency for a tool interacting with a browser/page.
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 Chinese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool with one parameter and is front-loaded with the core functionality. Every word earns its place.
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 retrieves content from a page. It doesn't explain what happens if the selector doesn't match, whether it returns inner/outer HTML, if it waits for elements to load, or the return format. For a Playwright tool interacting with dynamic pages, more context about behavior and output is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema provides ('CSS选择器，用于定位需要获取HTML内容的页面元素'). It doesn't explain selector syntax examples, multiple element handling, or timeout behavior. Baseline 3 is appropriate since the schema adequately covers the single parameter.
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 ('获取' meaning 'get') and resource ('HTML内容' meaning 'HTML content') with specific targeting ('指定元素' meaning 'specified element'). It distinguishes from sibling playwright_get_text_content by specifying HTML vs text content. However, it doesn't explicitly differentiate from playwright_evaluate which might also retrieve content.
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 playwright_get_text_content or playwright_evaluate. There's no mention of prerequisites (e.g., needing an active session), performance considerations, or error conditions. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating a session and optionally visiting a URL, but doesn't describe what type of browser is opened (e.g., headless vs. headed), session lifecycle (e.g., how long it persists, how to close it), authentication needs, or performance implications. For a session creation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the core functionality: session creation, window opening, and optional URL navigation. There's no wasted verbiage or redundant information, making it appropriately front-loaded and concise.
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 (session creation with optional navigation), no annotations, no output schema, and 100% schema coverage for the single parameter, the description is minimally adequate. It covers the basic purpose but lacks details about session management, browser configuration, or integration with sibling tools, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'url' well-documented in the schema as '需要访问的初始网址，可选参数，不填则只打开浏览器' (initial URL to visit, optional parameter, if not filled then only opens browser). The description adds no additional parameter semantics beyond what's already in the schema, so 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 tool's purpose: '创建新的浏览器会话，打开一个浏览器窗口并可选择性地访问指定网址' (Create a new browser session, open a browser window and optionally visit a specified URL). It specifies the verb ('创建新的浏览器会话' - create new browser session) and resource ('浏览器窗口' - browser window), but doesn't explicitly differentiate from sibling tools like 'playwright_navigate' which might also involve URL navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'playwright_navigate' (for navigation within existing sessions) or 'playwright_action' (for performing actions), nor does it specify prerequisites or appropriate contexts for session creation versus using existing sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions '智能过滤重复内容' (intelligently filter duplicate content), which adds some behavioral context about output processing. However, it lacks critical details: whether this requires a page to be loaded, what 'visible' means (e.g., viewport vs. DOM), error handling, performance implications, or output format. For a tool with no annotations, this is insufficient disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '获取当前页面中所有可见元素的文本内容，智能过滤重复内容'. It is front-loaded with the core purpose and adds a useful behavioral note ('智能过滤重复内容') without redundancy. Every word earns its place, making it appropriately concise.
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, no output schema, and moderate complexity (involving page interaction and text processing), the description is incomplete. It doesn't explain what 'visible' entails, how duplicates are filtered, the return format (e.g., string, array), or error cases. For a tool that likely interacts with a browser/page, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, so it meets the baseline of 4 for zero-parameter tools. No additional parameter information is required or provided.
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: '获取当前页面中所有可见元素的文本内容' (get text content of all visible elements on the current page). It specifies the verb ('获取' - get) and resource ('文本内容' - text content), and distinguishes from sibling tools like playwright_get_html_content by focusing on text rather than HTML. However, it doesn't explicitly differentiate from playwright_evaluate which might also retrieve text content.
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: it should be used when you need text content from visible elements on a page, and the '智能过滤重复内容' (intelligently filter duplicate content) suggests it's preferable when dealing with redundant text. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings (e.g., playwright_get_html_content for HTML, playwright_evaluate for custom JavaScript).
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. It discloses key behavioral traits: automatic session creation if none exists, which is useful context beyond basic navigation. However, it lacks details on error handling, timeout behavior, or what happens after navigation (e.g., page load completion), leaving gaps for a mutation 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 appropriately sized and front-loaded: a single, efficient sentence in Chinese that states the core action and key behavioral trait. Every part earns its place with no wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (navigation with session management), no annotations, and no output schema, the description is minimally adequate. It covers the main action and a critical behavioral aspect (session creation), but lacks details on return values, error cases, or interaction with siblings, leaving room for improvement.
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 parameter 'url' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., no extra syntax or format details). According to the rules, baseline is 3 when schema coverage is high (>80%).
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: '浏览器导航到指定网址' (browser navigates to specified URL). It uses a specific verb ('导航到' - navigate to) and resource ('指定网址' - specified URL). However, it doesn't explicitly distinguish from sibling tools like 'playwright_action' or 'playwright_new_session', which prevents a 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: '如果没有活跃的浏览器会话，会自动创建一个新会话' (if there's no active browser session, it will automatically create a new one). This suggests when to use it (for navigation with session handling) but doesn't explicitly compare to alternatives like 'playwright_new_session' or specify when not to use it, keeping it at a 3.
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-plus-python-mcp MCP server](https://glama.ai/mcp/servers/ziux/playwright-plus-python-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ziux/playwright-plus-python-mcp)

Score Badge

Copy to your README.md:

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

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