The EasyPlaywrightMCP server enables LLM-driven browser automation for automated testing and demo video creation.
Authentication: Login using password forms, HTTP Basic, OAuth, tokens, or manual headed windows. Handles restricted logins (Google, Microsoft, Apple, etc.) by injecting user-provided credentials. Saves reusable authentication profiles.
Session Management: Start headless or headed Chromium sessions, optionally recording WebM video with synthetic cursor, click highlights, and TTS narration (edge-tts). Query session state (URL, title, ARIA snapshot) to guide LLM decisions.
Action Orchestration: Execute ordered sequences of browser actions (click, type, navigate, scroll, hover, etc.). In demo mode, actions are paced to narration and logged with timing cues.
Video Recording & Compilation: End sessions to finalize recorded videos, trimming idle segments. Compile multiple clips and transition slates into a single narrated MP4 demo with frame interpolation (60fps) and voiceover synchronization.
Use Cases: Automated end-to-end testing with pass/fail reporting, generating narrated product demos from prompts, testing features behind complex OAuth flows, and recording walkthroughs of features or documentation.
Supports automated login with Auth0 OAuth for testing and demo recording, handling session management and restricted auth.
Enables automated authentication against Cloudflare-protected sites, including bot walls, for testing and demo videos.
Facilitates automated login with Discord OAuth, managing sessions for testing and demo recording.
Integrates with Google OAuth (including Sign in with Google) for automated login and session management in testing and demo workflows.
Supports automated login with Okta social authentication, managing sessions for testing and demo video creation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@EasyPlaywrightMCP Make a demo video of my last PR"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
LLM-driven Playwright MCP for automated testing and demo videos.
Capture: synthetic cursor + always-on click highlight, 1920×1080 @ deviceScaleFactor 2, WebM→H.264 60fps minterpolate, smooth rAF scroll.
Narration: Microsoft Edge neural TTS via edge-tts.
Client | Guide |
Cursor | |
Cursor CLI | |
Claude Desktop | |
Claude CLI |
Using EasyPlaywrightMCP Make a demo video of the feature in my last PR
Using EasyPlaywrightMCP Connect my google oauth and test this feature in production. Report the success or failure reason for each operation
Using EasyPlaywrightMCP Create a demo video of the steps in this MD
login → save profileId (or set_session_auth for Google/bot-blocked OAuth)
start_session (usually headless) with profileId
Loop: query_session → orchestrate_session
end_session
Short answer to the user (pass/fail + findings)
login if auth is needed (or set_session_auth for restricted providers)
start_session with recordVideoPath (demoMode / auto-narrate on by default)
Loop: query_session → orchestrate_session — put spoken lines in description / narration; server TTS + holds
end_session (finalizes WebM, trims idle, writes/updates .cues.json)
compile_demo with clip videoPath only (loads cues automatically)
Demo vs testing: Recording sessions conjoin speech and UI on the server. Testing sessions (no recordVideoPath) keep snappy startMs/endMs pacing.
Restricted auth: For Google OAuth / Sign in with Google (and Microsoft, Discord, Cloudflare bot walls, etc.), do not use headed login. Immediately give the user the login URL, Network → Cookie header steps, and the console snippet from MCP instructions; then set_session_auth with their paste → start_session({ profileId }).
Per-app cookie guides: LinkedIn · Google OAuth / Workspace
Related MCP server: Limetest MCP Server
login// LoginInput
{
siteUrl: "https://app.example.com",
authUrl: "https://app.example.com/login",
username?: "user@example.com",
password?: "secret",
oauth?: {
accessToken?: "eyJ...",
cookies?: [{ name: "sid", value: "x", domain: "app.example.com" }],
localStorage?: [{ name: "token", value: "eyJ..." }]
},
httpCredentials?: { username: "u", password: "p" },
tokens?: { bearer?: "eyJ...", cookies?: [], localStorage?: [] },
timeoutMs?: 120000,
profileId?: "prof_abc" // reuse
}
// LoginResult → { ok: true, profileId: "prof_…", strategy: "password" }Strategies: password · http_basic · token_inject · oauth_tokens · manual (headed OAuth/password window) · reuse_profile
set_session_auth// SetSessionAuthInput
{
siteUrl: "https://app.example.com/dashboard",
credentialsJson: JSON.stringify({
origin: "https://app.example.com",
cookies: [{ name: "session", value: "abc", domain: "app.example.com", path: "/" }],
localStorage: [{ name: "token", value: "eyJ..." }],
sessionStorage: []
}),
sessionId?: "sess_…", // optional: also inject into a live session
authUrl?: "https://app.example.com/login"
}
// → { ok: true, profileId: "prof_…", strategy: "restricted_auth", sessionId?: "sess_…" }Use when the user must log in in their own browser. Always (Google OAuth / Sign in with Google, Microsoft, Apple, Discord, Cloudflare Turnstile, Okta/Auth0 social). Accepts Network Cookie-header snippet JSON or Playwright storageState. Always saves a reusable profileId.
start_session{
startUrl?: "https://app.example.com/dashboard",
headed?: false,
recordVideoPath?: "C:/Videos/clip.webm", // omit = no record; set => demoMode
narrate?: true, // default true when recording; false = silent capture
voice?: "en-US-AndrewNeural",
rate?: "+10%",
profileId?: "prof_abc"
}
// → { sessionId: "sess_…", headed: false, recording: true, demoMode: true, startUrl?: "…" }query_sessions / query_session// query_session
{ sessionId: "sess_…" }
// → { url, title, viewport, ariaSnapshot, interactive: [{ role, name, selectorHint, inputType? }] }orchestrate_session{
sessionId: "sess_…",
recordStepsPath?: "C:/Videos/steps.md",
commands: [
{
action: "click", // move|click|tap|type|press|scroll|wait|navigate|select|hover|upload
description: "Open Settings from the sidebar", // also default VO text in demoMode
narration?: "Spoken override",
skipNarration?: false,
startMs: 0, // ignored for pacing while recording
endMs: 1000,
selector: "nav >> text=Settings",
speed: "fast", // fast (default) | slow | timed
fill?: false, // demos: false for live typing
files?: ["C:/path/to/file.pdf"], // upload action
useFileChooser?: false // upload: click + FileChooser instead of setInputFiles
}
]
}
// → { commands: [{ index, description, action, startMs, endMs, videoStartMs?, videoEndMs?, ok, reason? }] }
// Recording also writes C:/Videos/clip.cues.jsonend_session{ sessionId: "sess_…" }
// → { ok: true, videoPath?: "C:/Videos/clip.webm" }compile_demo{
outputPath: "C:/Videos/final-demo.mp4",
fast?: false, // skip minterpolate for quick check
content: [
{
kind: "slate",
eyebrow: "INTRO",
heading: "Product Demo",
body: "A quick walkthrough",
durationMs: 3000,
narration: [{ startMs: 0, endMs: 2800, text: "Welcome to the demo." }]
},
{
kind: "clip",
videoPath: "C:/Videos/clip.webm" // loads clip.cues.json automatically
}
]
}
// → { ok: true, outputPath: "C:/Videos/final-demo.mp4" }Node 20+
ffmpeg / ffprobe on PATH (Gyan build: winget install Gyan.FFmpeg)
python -m pip install edge-tts
Chromium via npx playwright install chromium (runs on npm install)
Hey Siri, install https://github.com/Macioa/EasyPlaywrightMCP to cursor
Client | Doc |
Cursor IDE | |
Cursor CLI | |
Claude Desktop | |
Claude Code CLI |
npm install
npm run build
npm start # stdio MCP
npm test
npm run typecheckAuth profiles and scratch files live under %USERPROFILE%\.easy-playwright-mcp\.
Compile demo clips + slate segways into one narrated MP4. Pipeline: convert (minterpolate 60fps H.264) → burn captions → VO → splice. For recorded clips, pass videoPath only — loads sibling .cues.json (wins over hand-authored narration). Slates still take explicit narration.
Example:
{
"outputPath": "C:/Videos/final-demo.mp4",
"fast": false,
"content": [
{
"kind": "slate",
"eyebrow": "INTRO",
"heading": "Product Demo",
"body": "A quick walkthrough",
"durationMs": 3000,
"narration": [{ "startMs": 0, "endMs": 2800, "text": "Welcome to the demo." }]
},
{
"kind": "clip",
"videoPath": "C:/Videos/demo-clip.webm"
}
]
}| Name | Required | Description | Default |
|---|---|---|---|
| fast | No | Skip minterpolate for quick validation encode (default false) | |
| rate | No | edge-tts rate (default +10%) | |
| voice | No | edge-tts voice (default en-US-AndrewNeural) | |
| content | Yes | ||
| outputPath | Yes | Final MP4 output path |
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.
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.
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.
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.
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.
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.
End a session and finalize recorded video if any. Recording sessions: trims idle head/tail using cues.json actionSpan, then returns videoPath. Example: { "sessionId": "sess_01HXYZ" } Returns: { "ok": true, "videoPath": "C:/Videos/demo-clip.webm" }
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from start_session |
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.
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.
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.
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.
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.
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.
Orchestrate login and persist Playwright storageState. Strategies: password form, HTTP Basic, bearer/token inject, OAuth cookies/tokens, manual/OAuth window, reuse profileId. Auto (headless) when enough creds/tokens are provided; otherwise opens a headed window and waits.
DO NOT use this tool for Google OAuth / Sign in with Google, Microsoft/Apple/Discord social login, Cloudflare bot walls, or other restricted IdPs — those require set_session_auth. If you are about to open a headed login for Google OAuth, stop and follow the Restricted auth user-message template instead.
Example input:
{
"siteUrl": "https://app.example.com",
"authUrl": "https://app.example.com/login",
"username": "user@example.com",
"password": "secret"
}Example success: { "ok": true, "profileId": "prof_abc", "strategy": "password" }
| Name | Required | Description | Default |
|---|---|---|---|
| oauth | No | OAuth tokens / cookies / storage to inject | |
| tokens | No | Generic bearer / cookie / storage tokens | |
| authUrl | Yes | Login / OAuth start URL | |
| siteUrl | Yes | Target application URL after login | |
| password | No | Password for password login | |
| username | No | Username or email for password login | |
| profileId | No | Reuse an existing auth profile id instead of logging in again | |
| timeoutMs | No | Max wait ms (default 120000) | |
| httpCredentials | No | HTTP Basic auth credentials |
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.
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.
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.
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.
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.
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.
Execute ordered tap/cursor/keyboard actions. Recording/demoMode: server synthesizes TTS from narration|description, runs the action, holds until VO ends. startMs/endMs are ignored for pacing while recording (placeholders OK). fill=false for live typing. Testing (no recording): startMs/endMs pace the batch; each call clock starts near 0. Optional recordStepsPath writes an MD log. Recording also writes sibling .cues.json.
Example (demo):
{
"sessionId": "sess_01HXYZ",
"commands": [
{
"action": "click",
"description": "Open Settings from the sidebar",
"startMs": 0,
"endMs": 1000,
"selector": "nav >> text=Settings",
"speed": "fast"
},
{
"action": "type",
"description": "Enter the billing search query",
"narration": "Now we search for billing.",
"startMs": 0,
"endMs": 1000,
"selector": "input[type=search]",
"text": "billing",
"fill": false
}
]
}| Name | Required | Description | Default |
|---|---|---|---|
| commands | Yes | ||
| sessionId | Yes | ||
| recordStepsPath | No | If set, write markdown log of commands+results; omit to skip MD |
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.
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.
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.
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.
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.
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.
Fast page digest for LLM navigation decisions: url, title, viewport, ariaSnapshot, interactive controls. Example: { "sessionId": "sess_01HXYZ" }
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session id from start_session |
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.
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.
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.
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.
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.
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.
List all active sessions with sessionId, url, title, recording, createdAt, headed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Inject user-browser credentials into Playwright (restricted auth). ALWAYS saves profileId; optional sessionId applies to a live session.
BEFORE calling this tool: you MUST already have sent the user (same conversation) the login URL + Network Cookie steps + JS snippet from server instructions. Never call this tool "speculatively" without first giving those instructions. Never open headed login for Google OAuth — use this flow.
Triggers: Google OAuth / Sign in with Google, Gmail/Google apps, Microsoft/Entra, Apple, Discord OAuth, Cloudflare Turnstile on login, Okta/Auth0 social IdP, or any login Playwright cannot complete.
Accepts credentialsJson from the console snippet (Cookie header + storage) or Playwright storageState JSON.
Example (after user pastes):
{
"siteUrl": "https://mail.google.com/",
"credentialsJson": "{...paste from user...}"
}Returns: { "ok": true, "profileId": "prof_…", "strategy": "restricted_auth" }
| Name | Required | Description | Default |
|---|---|---|---|
| authUrl | No | Optional auth URL for profile meta (defaults to siteUrl) | |
| siteUrl | Yes | Target application URL (inject / navigate origin) | |
| sessionId | No | If set, also inject credentials into this live session | |
| credentialsJson | Yes | JSON paste from the restricted-auth console snippet (Network Cookie header + storage) or Playwright storageState. Only call set_session_auth after the user was given the login URL + snippet and has pasted this JSON. |
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.
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.
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.
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.
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.
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.
Start a Playwright Chromium session (headless or windowed) and keep it open. Optional recordVideoPath enables WebM capture at 1920×1080 @ deviceScaleFactor 2 with synthetic cursor and always-on click highlight. When recording, demoMode is on (narrate defaults true): orchestrate auto-paces to TTS. Pass profileId from login or set_session_auth to reuse auth.
Example:
{
"startUrl": "https://app.example.com/dashboard",
"headed": false,
"recordVideoPath": "C:/Videos/demo-clip.webm",
"profileId": "prof_abc"
}Returns: { "sessionId": "sess_…", "headed": false, "recording": true, "demoMode": true, "startUrl": "…" }
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | edge-tts rate for demoMode (default +10%) | |
| voice | No | edge-tts voice for demoMode (default en-US-AndrewNeural) | |
| headed | No | Open a visible window (default false) | |
| narrate | No | When recording, auto-pace actions to TTS (default true). Set false for silent recording. | |
| startUrl | No | Optional URL to open first | |
| profileId | No | Auth profile from login | |
| recordVideoPath | No | If set, record WebM to this path; omit to skip recording | |
| storageStatePath | No | Optional path to a Playwright storageState JSON file |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0compile_demoend_sessionloginorchestrate_sessionquery_sessionquery_sessionsset_session_authstart_sessionEach 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.
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.
With 8 tools, the server is well-scoped. Each tool adds necessary functionality for Playwright automation and demo creation without redundancy or bloat.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run multi-step tasks in a real Chrome browser: persistent environments, live view, human takeover.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
Turn a product URL into a narrated cinematic demo video, launch video, or deck.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
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
