EasyPlaywrightMCP

by Macioa

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clear, distinct purpose: authentication (login, set_session_auth), session querying (query_sessions, query_session), session lifecycle (start_session, orchestrate_session, end_session), and video compilation (compile_demo). No two tools overlap in functionality.
Naming Consistency4/5
Tool names follow a mostly consistent verb_noun pattern with snake_case (e.g., query_sessions, start_session). The exception is 'login', which is a bare verb, but it's a common convention and does not cause confusion.
Tool Count5/5
With 8 tools, the server is well-scoped. Each tool adds necessary functionality for Playwright automation and demo creation without redundancy or bloat.
Completeness4/5
The tool surface covers core workflows: authentication, session management, interaction orchestration, and video compilation. A minor gap is the lack of explicit profile management (e.g., list/delete profiles), but it does not break essential workflows.
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 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
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 provided, so description carries full burden. It suggests read-only behavior ('digest'), but does not explicitly confirm idempotency, side effects, error conditions, or auth requirements. The term 'fast' hints at performance but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus an example. Key purpose is front-loaded ('Fast page digest for LLM navigation decisions'). No redundant words.
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?
Adequate for a simple query tool with one parameter and no output schema. Lists expected fields in return, but lacks detail on format, pagination, error handling, or what happens for invalid session. The example aids 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?
Input schema provides full description of sessionId ('Session id from start_session'), and description adds an example of its format. With 100% schema coverage, incremental value is limited; description does not explain sessionId further.
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?
Description clearly states it provides a 'page digest' for LLM navigation decisions, listing specific fields (url, title, viewport, ariaSnapshot, interactive controls). The verb 'query' and resource 'session' are specific, but it does not explicitly differentiate from sibling tools like 'query_sessions' or 'orchestrate_session'.
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?
Implies usage for quick navigation decisions via 'Fast page digest for LLM navigation decisions', but no explicit guidance on when not to use or alternatives. Lacks prerequisites or conditions (e.g., session must be active), though sessionId is required.
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 must convey behavioral traits. It states 'list all active sessions' implying a read-only operation, but lacks details about performance, pagination, or any limitations. The brevity leaves ambiguity about whether this is safe or has side effects.
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 sentence, efficiently conveying the tool's action and output fields. However, it is somewhat terse and could benefit from slight elaboration on usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately covers what the tool returns. It is complete enough for a straightforward list operation, though it omits any note about read-only behavior or rate limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, so the description naturally adds no parameter information. Per the guidelines, a baseline of 4 is appropriate for 0-parameter tools.
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: list all active sessions. It specifies the fields returned (sessionId, url, title, recording, createdAt, headed), distinguishing it from sibling tools like query_session (singular) and start_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it does not explain when to use query_sessions vs query_session, nor any context about filtering or prerequisites.
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?
With no annotations, the description carries full burden and explains key behaviors: timing differences between recording and testing, fill flag for live typing, optional logging. However, it omits failure handling and idempotency.
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 front-loaded with purpose, followed by behavioral details and a concrete example. Reasonably concise, though the example adds length. No wasted sentences.
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 (multiple actions, modes) and no output schema, the description explains modes and timing but does not specify return value or error handling. Incomplete for full agent decision-making.
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 low (33%), and the description does not systematically explain parameters. However, the example helps convey usage of startMs, endMs, fill, and recordStepsPath. Lacks detail on sessionId and command properties.
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: 'Execute ordered tap/cursor/keyboard actions.' This is a specific verb+resource combination that distinguishes it from sibling tools like start_session, end_session, and compile_demo.
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 implicitly indicates usage contexts (recording/demoMode vs testing) but does not explicitly state when to use this tool versus alternatives. Lacks explicit when-not 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?
With no annotations, the description carries full burden. It discloses trimming idle head/tail and returning videoPath for recording sessions. However, it does not detail error handling, authorization needs, or behavior for non-recording sessions.
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 concise with two sentences and an example. It front-loads the purpose and includes an example without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers main behavior and return. It lacks context for non-recording sessions and error scenarios, but is largely complete for a single-parameter tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (sessionId). The description adds minimal extra meaning beyond the schema, only showing the parameter in an example. Baseline 3 applies.
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 ends a session and finalizes recorded video. It explains the trimming behavior and provides an example, which distinguishes it from siblings like start_session and orchestrate_session.
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 when to use (after starting a session), but does not explicitly state when not to use or provide alternatives among sibling tools. Usage context is clear but not comparative.
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?
With no annotations, the description carries full burden. It discloses recording specifics (resolution, cursor, click highlight), demoMode behavior, and return shape. It does not mention destructive aspects (none expected) but adequately describes key behaviors.
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 concise, front-loaded with purpose, and includes a helpful JSON example. It earns its sentences without significant redundancy.
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 8 parameters and no output schema, the description covers return values and key context (profileId, recording settings). It addresses the complexity adequately, though it could mention error scenarios or session lifecycle briefly.
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?
Schema coverage is 100%, but description adds meaning beyond schema by explaining interactions (e.g., recordVideoPath enables recording with specific quality, narrate defaults to true). It clarifies the purpose of parameters in context.
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 verb 'start' and the resource 'Playwright Chromium session', and distinguishes from sibling tools like login and orchestrate_session by focusing on session initialization. It covers key modes (headless/windowed) and optional recording.
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 after login or set_session_auth via profileId mention, and for recording via recordVideoPath. However, it does not explicitly state when not to use this tool or provide direct alternatives for specific scenarios.
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?
No annotations are provided, so the description carries full burden. It discloses the pipeline steps (convert → burn captions → VO → splice) and explains behavior for clips (cues.json wins over hand-authored narration). No contradictions.
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 summary, a pipeline overview, specific guidance, and a clear JSON example. Every sentence earns its place with no redundancy.
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 5 parameters and nested content, the description covers the two content kinds, pipeline, and narration logic. No output schema exists, but return values are implied (an MP4 file). Slightly lacking detail on outputPath behavior, but adequate.
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?
Schema coverage is 80% (high), but the description adds meaning beyond the schema. It explains the pipeline, the `fast` parameter for skipping minterpolate, and the narration precedence via example. This helps the agent understand parameter interplay.
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 'Compile demo clips + slate segways into one narrated MP4.' It uses a specific verb (compile) and resource (demo clips/slates, output MP4). This distinguishes it from sibling tools like 'login' or 'orchestrate_session' which have 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use clips vs slates: for recorded clips, pass videoPath only to load .cues.json, while slates take explicit narration. However, it does not explicitly state when not to use this tool or mention alternatives, though siblings are unrelated.
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?
Discloses auto vs headed behavior, persistence of storageState, and waiting. No annotations provided, so description bears full burden. Lacks details on error handling or side effects but is generally transparent.
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?
Well-structured with front-loaded purpose, strategies, warning, and example. Slightly lengthy but every part earns its place; no wasted sentences.
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 no output schema, the example output is helpful. Covers strategies, exclusions, and sample input. Minor gaps in error behavior and full return values, but adequate for complexity.
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?
Schema coverage is 100% with descriptions. The description adds context by linking parameters to strategies (e.g., username/password for password form) and provides an example input, enhancing understanding beyond schema alone.
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 purpose: 'Orchestrate login and persist Playwright storageState.' It lists multiple strategies and distinguishes the tool from sibling set_session_auth by explicitly forbidding use for restricted IdPs.
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?
Explicitly states when to use (various login methods) and when not to use (Google OAuth, social logins, Cloudflare bot walls), directing to set_session_auth and a user-message template.
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?
With no annotations, the description carries the full burden. It describes the tool as injecting credentials, saving a profileId, and optionally applying to a live session. It explains the input format (credentialsJson from console snippet) and the output. However, it does not explicitly state that the operation is destructive (e.g., overwriting existing credentials) or mention any side effects beyond the return. Still, it provides sufficient behavioral context for an agent to understand the action.
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 well-structured and front-loaded: the first sentence gives the core purpose. Prerequisites are highlighted in uppercase for emphasis. Triggers are listed in a bullet-style format. An example is provided. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters (2 required) and no output schema, the description covers all necessary aspects: input format, output structure, usage prerequisites, and trigger scenarios. It provides enough context for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage with descriptions for all parameters. The description adds value by clarifying the role of siteUrl ('inject/navigate origin') and credentialsJson ('paste from the restricted-auth console snippet or Playwright storageState'). It includes an example mapping parameters to usage, which is helpful for proper invocation.
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: 'Inject user-browser credentials into Playwright (restricted auth).' It specifies the action (inject), the resource (Playwright), and the context (restricted auth). It also distinguishes from siblings by mentioning it is for flows like Google OAuth and other social IdPs that Playwright cannot complete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: a list of triggers (e.g., Google OAuth, Microsoft/Entra). It also states prerequisites: 'BEFORE calling this tool: you MUST already have sent the user... the login URL + Network Cookie steps + JS snippet.' It includes a warning: 'Never call this tool speculatively.' This is thorough and leaves no ambiguity.
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:

[![EasyPlaywrightMCP MCP server](https://glama.ai/mcp/servers/Macioa/EasyPlaywrightMCP/badges/card.svg)](https://glama.ai/mcp/servers/Macioa/EasyPlaywrightMCP)

Score Badge

Copy to your README.md:

[![EasyPlaywrightMCP MCP server](https://glama.ai/mcp/servers/Macioa/EasyPlaywrightMCP/badges/score.svg)](https://glama.ai/mcp/servers/Macioa/EasyPlaywrightMCP)

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/Macioa/EasyPlaywrightMCP'

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