The Playwright MCP server built for modern web apps — persistent sessions, React/Vue/Angular support, 143+ devices and smart DOM waiting.
Installation · Why · Tools · Examples · Limitations
An MCP server that drives a real Chromium browser, purpose-built for Single Page Applications. Your assistant can log in, click, type and screenshot — and the SPA's state survives across calls:
You: Log into app.example.com, open the dashboard and screenshot it.
Assistant: (calls
spa_session_start, thenspa_chain[type-realistic → click → wait-for-idle], thenspa_screenshot) Logged in and captured the dashboard — React state preserved across the session.
Related MCP server: MCP Playwright Server
Feature | playwright-spa-mcp | Other Playwright MCPs |
Persistent sessions | ✅ | ❌ |
React/Vue/Angular detection | ✅ | ❌ |
Smart DOM idle waiting | ✅ | ❌ |
Realistic typing | ✅ | ❌ |
Device emulation | 143+ | Limited |
Action chains | ✅ | ❌ |
HTTP with browser cookies | ✅ | ❌ |
# One command — no clone needed
claude mcp add playwright-spa -- npx -y github:manganate006/playwright-spa-mcp
# Install the Chromium browser Playwright drives
npx playwright install chromiumClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"playwright-spa": {
"command": "npx",
"args": ["-y", "github:manganate006/playwright-spa-mcp"]
}
}
}git clone https://github.com/manganate006/playwright-spa-mcp.git
cd playwright-spa-mcp
npm install
npx playwright install chromium
claude mcp add playwright-spa -- node $(pwd)/src/index.js22 tools, spa_ prefix. Chain-action list, 143+ device shortcuts and CLI usage: docs/ADVANCED.md.
Group | Tools |
📸 Screenshot & navigation |
|
📝 Interactions |
|
⛓️ Chains |
|
🔐 Sessions |
|
🔎 Inspection |
|
🖼️ iframes |
|
ℹ️ Discovery |
|
Log into a React app and keep the session — realistic typing fires React's onChange:
spa_session_start({ session: "myapp" })
spa_chain({
session: "myapp",
url: "https://app.example.com/login",
spaMode: "react",
chain: [
{ action: "type-realistic", selector: "#email", value: "user@example.com" },
{ action: "type-realistic", selector: "#password", value: "secret123" },
{ action: "click", selector: "button[type=submit]" },
{ action: "wait-for-idle" },
{ action: "screenshot" }
]
})
// Same session — React state is preserved
spa_click({ session: "myapp", selector: ".dashboard-item" })Mobile device emulation:
spa_screenshot({ url: "https://example.com", device: "iPhone 15 Pro", fullPage: true })Authenticated API call reusing the session cookies:
spa_http_request({ session: "myapp", url: "https://api.example.com/user/profile", method: "GET" })Chromium only — Firefox/WebKit are not wired up; requires npx playwright install chromium
Local browser — spawns a real browser process; not suited to sandboxes without one
SPA heuristics — React/Vue/Angular readiness is detected heuristically (spaMode: "auto"); heavy custom frameworks may need explicit wait-for / wait-for-idle
Sessions are in-memory — they live with the server process and don't persist across restarts
Detects and waits correctly for React (finishes rendering, proper onChange), Vue (v-model bindings) and Angular (Zone.js stability). Use spaMode: "auto" to detect automatically. Details in docs/ADVANCED.md.
Project | Description |
🎾 ATP tennis stats since 1968 | |
🏊 Pool-party finder in France |
MIT © manganate006
Run assertions on page elements.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| type | Yes | Assertion type | |
| value | No | Expected value (for text and count assertions) | |
| session | No | Session ID | default |
| contains | No | For text assertion: check if text contains value instead of exact match | |
| selector | Yes | CSS selector to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'Run assertions on page elements' but omits crucial details: What happens on failure (error vs boolean return)? Does it wait for elements? How does it handle sessions? The schema hints at types but the description itself is silent.
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 at one sentence, which is efficient for a simple tool. It is front-loaded with the essential verb. However, it might be too brief to be maximally helpful.
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 complexity (6 parameters, assertion types) and lack of output schema, the description is incomplete. It does not explain return behavior, error handling, or session management. For a testing tool, this is insufficient.
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%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for the parameters.
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 'Run assertions' and the resource 'page elements', making the tool's general purpose clear. However, it could be more specific about what types of assertions are supported, which are detailed in the schema. It is distinct from sibling tools like spa_click or spa_fill.
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 is provided on when to use this tool versus alternatives, or any prerequisites. The agent receives no context about when assertions are appropriate or how they relate to other spa_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a chain of actions in sequence. Supports all browser actions plus chain-specific commands like wait, wait-for-idle, press, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| chain | Yes | Array of action objects to execute | |
| device | No | Device to emulate | |
| session | No | Session ID | default |
| spaMode | No | ||
| stopOnError | No | Stop chain execution on first error |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It mentions supported actions but does not disclose details about error handling, session management, or side effects beyond the parameter stopOnError.
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 concise sentence, effectively capturing the essence. Slightly more structure could improve readability, but it is not overly verbose.
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 complexity of the tool (6 parameters, nested chain array, and no output schema), the description is somewhat lacking. It does not explain the structure of the chain array or the impact of parameters like device, session, and spaMode in detail.
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 83%, so the schema already documents most parameters. The description adds little extra meaning beyond listing chain-specific commands, which are already in the schema.
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 name 'spa_chain' and description 'Execute a chain of actions in sequence' clearly state the tool's purpose. It distinguishes from sibling tools by emphasizing sequential execution of multiple actions.
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 for sequences of browser actions but does not explicitly state when to use this tool versus individual action tools like spa_click, spa_fill, etc. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element with SPA-aware waiting. Waits for DOM to stabilize after click.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| session | No | Session ID | default |
| spaMode | No | ||
| selector | Yes | CSS selector to click | |
| screenshot | No | Take screenshot after action | |
| waitForIdle | No | Wait for DOM idle after click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions 'waits for DOM to stabilize after click'. It omits details on error handling, return values, destructive nature, or auth requirements.
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?
Two sentences, no fluff, front-loaded with purpose.
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?
The description does not explain return values, the role of the 'url' parameter, or how the tool interacts with navigation siblings. Given 6 parameters and no output schema, more context is needed.
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 83%, so baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides.
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 'click' and the resource 'element', and specifies 'SPA-aware waiting', which distinguishes it from sibling tools like spa_fill and spa_type_realistic.
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 use for clicking in SPAs requiring DOM stabilization, but does not explicitly state when to use or when not to use, nor does it mention alternatives like spa_iframe_click.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drag an element and drop it on another element.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| target | Yes | CSS selector for drop target | |
| session | No | Session ID | default |
| selector | Yes | CSS selector for element to drag | |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without elaborating on side effects, failure modes (e.g., if drop invalid), or waiting behavior. This is insufficient for a complex interaction.
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 (one sentence) and front-loaded, but it is overly minimal. It could include more structured information (e.g., parameter roles) without becoming verbose.
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?
With 5 parameters, no output schema, and no annotations, the description lacks details about return values, prerequisites, or edge cases. It only covers the basic action, leaving the agent underinformed.
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 for all 5 parameters. The tool description adds no additional meaning beyond the schema, so baseline score of 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 action ('Drag an element and drop it on another element'), which is a specific verb+resource combination. It effectively distinguishes from sibling interaction tools like spa_click or spa_fill.
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 other interaction tools (e.g., spa_click or spa_fill). The description lacks context about prerequisites or scenarios where drag-and-drop is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the page context.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| script | Yes | JavaScript code to execute | |
| session | No | Session ID | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as side effects, security implications, or that the result is the script's return value.
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, efficient sentence, but it omits potentially valuable information; still, it is not overly verbose.
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?
The tool executes arbitrary JavaScript, yet the description does not mention return values, error handling, or side effects, leaving the agent with significant uncertainty about its behavior.
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% and already describes each parameter; the description adds no extra meaning beyond the schema.
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 the action ('Execute JavaScript') and the context ('in the page context'), making it distinct from sibling tools that focus on UI interactions like clicks or fills.
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 (e.g., spa_assert, spa_get_text), nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an input field with React/Vue/Angular compatibility. Properly triggers framework change events.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| value | Yes | Value to fill | |
| session | No | Session ID | default |
| spaMode | No | ||
| selector | Yes | CSS selector for input field | |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral insight (triggers framework change events) but lacks details on side effects like clearing existing values or waiting for elements.
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?
Two concise sentences, front-loaded with action and compatibility; no 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?
Adequate for a 6-parameter tool; covers the important framework-triggering behavior. Could be more complete by mentioning handling of different input types or the url navigation behavior.
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 83%, so schema already documents most parameters. The description adds no extra meaning beyond mentioning framework compatibility, which relates to spaMode but doesn't elaborate.
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 fills an input field and specifies compatibility with React, Vue, Angular, which distinguishes it from sibling tools like spa_click or spa_type_realistic.
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 explicit guidance on when to use this tool vs alternatives like spa_type_realistic or spa_click. The framework compatibility is mentioned but not as a usage criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get text content of an element.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| session | No | Session ID | default |
| selector | Yes | CSS selector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description omits behavioral details such as whether it waits for the element, returns empty string if not found, or works on hidden elements. The agent must guess behavior.
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 short sentence. While concise, it sacrifices necessary detail. It does not earn its place by providing value beyond the name.
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 output schema, and no annotations, the description should explain return value and error behavior. It fails to provide a complete picture.
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%. The description does not add meaning beyond what the schema provides (e.g., what 'selector' targets, handling multiple matches). Baseline score applies as no additional semantics are offered.
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 gets text content from an element. It uses a specific verb and resource, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like spa_assert which may also interact with text.
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 vs alternatives (e.g., spa_assert). No mention of prerequisites or when not to use it, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate back in browser history.
| Name | Required | Description | Default |
|---|---|---|---|
| session | No | Session ID | default |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects such as waiting for page load, behavior with empty history, or impact on session state.
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?
Single sentence is concise and front-loaded, no 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?
Despite low complexity, missing usage context and behavioral details for an SPA automation tool (e.g., session requirement). Not complete for effective use.
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 parameter descriptions. Description adds no additional meaning beyond the brief purpose.
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 'Navigate back in browser history' clearly states the action and resource, distinguishing it from siblings like spa_go_forward.
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 like spa_go_forward or other navigation methods. Lacks context for prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate forward in browser history.
| Name | Required | Description | Default |
|---|---|---|---|
| session | No | Session ID | default |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on prerequisites (e.g., forward history existence), side effects, or error conditions.
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?
Single clear sentence with no 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?
Simple tool with no required params or output schema; description covers core functionality adequately.
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 100%, so baseline 3 applies; description adds no parameter-specific info.
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 the verb 'navigate forward' and the resource 'browser history', distinguishing it from sibling spa_go_back.
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 explicit guidance on when to use or when not; usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP request using the browser context (includes cookies and auth).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL for HTTP request | |
| body | No | Request body (JSON string or form data) | |
| method | No | GET | |
| headers | No | Request headers | |
| session | No | Session ID | default |
| bearerToken | No | Bearer token for Authorization header |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the request includes cookies and authentication from the browser context, which is key behavioral info. Without annotations, this adds value, though it omits potential side effects like modifying server state.
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?
Single sentence that is direct and free of filler, effectively communicates the core purpose.
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?
No output schema exists, and the description does not explain what the tool returns (e.g., response status, body, headers). This is a significant gap for a request tool, reducing its usefulness for an AI agent.
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 high (83%) and parameters are well-described in the schema. The description adds no additional meaning beyond what the schema already provides.
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 makes an HTTP request using the browser context, distinguishing it from sibling tools that perform UI actions like clicks and fills.
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 requests requiring cookies/auth, but no explicit guidance on when to use this versus other tools (e.g., for non-browser requests) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element inside an iframe.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| frame | Yes | CSS selector for the iframe | |
| session | No | Session ID | default |
| selector | Yes | CSS selector for element inside iframe | |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as loading requirements, error handling, or cross-origin limitations. The description carries full burden for transparency but only states the basic 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?
A single sentence that is front-loaded and efficient. However, the brevity sacrifices necessary detail.
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?
The tool has 5 parameters and no output schema. The description is too brief for the complexity of clicking inside an iframe, failing to explain navigation, iframe readiness, or screenshot behavior.
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 100%, so parameters are already documented. The tool description adds no extra meaning beyond what the schema provides. Baseline 3 is appropriate.
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 is 'Click an element inside an iframe.' It clearly specifies the action (click) and the target resource (element inside an iframe), which distinguishes it from siblings like spa_click (click on main page) and spa_iframe_fill (fill inside iframe).
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 is provided on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or exclusion criteria. For example, it does not clarify when to use spa_iframe_click vs spa_iframe_fill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an input field inside an iframe.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| frame | Yes | CSS selector for the iframe | |
| value | Yes | Value to fill | |
| session | No | Session ID | default |
| selector | Yes | CSS selector for input inside iframe | |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states the basic action without disclosing whether it waits for iframe loading, handles framesets, or any side effects. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no waste. It could be slightly more informative, but it is concise and front-loaded.
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?
For a simple fill action with no output schema, the description is adequate but lacks details on error handling, preconditions (e.g., iframe must exist), or behavior when the input is not found. The screenshot parameter hints at output, but not explicitly.
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%, so the schema already describes all parameters. The description adds minimal value beyond clarifying 'inside an iframe'. Baseline 3 is appropriate.
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 action ('fill') and the specific resource ('input field inside an iframe'), distinguishing it from sibling tools like spa_fill (non-iframe) and spa_iframe_click.
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 explicit guidance on when to use this tool versus alternatives such as spa_fill or spa_type_realistic. The context is implied by the iframe focus, but exclusions and usage scenarios are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available actions for the chain command.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, session requirements, or side effects. It only states the basic function.
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, concise sentence with no wasted words. It is front-loaded and easy to parse.
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?
For a simple tool with no parameters and no output schema, the description adequately explains its purpose. Could be slightly more detailed about the return format, but overall complete given low 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?
The tool has no parameters, so schema coverage is 100% trivially. Baseline score of 4 applies, and the description adds no param info since none exist.
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 lists all available actions for the chain command. It uses a specific verb 'list' and resource 'actions for the chain command', distinguishing it from siblings like spa_chain.
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. It does not specify that it should be used before constructing a chain command, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available device emulation presets.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search pattern to filter devices |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure, but it only states the basic function. It does not mention whether the list is all presets or filtered, any side effects, or that it is a read-only operation.
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?
A single sentence that is perfectly concise and front-loaded, containing no extraneous information.
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 (one optional parameter, no output schema), the description is minimally complete but lacks any indication of return format or expected filter behavior, which could aid the agent.
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%, and the description adds no additional meaning beyond the parameter's own description ('Search pattern to filter devices'). Baseline 3 is appropriate as schema handles semantic load.
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 uses a specific verb+resource combination ('List available device emulation presets') that clearly distinguishes this tool from sibling tools like spa_click or spa_fill, which are actions rather than list operations.
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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context for when listing presets is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of a web page with SPA framework support. Waits for DOM to stabilize before capturing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to (optional if using existing session) | |
| device | No | Device to emulate (e.g., "iPhone 15", "Pixel 7", or shortcuts like "iphone", "pixel") | |
| session | No | Session ID for persistent browser state | default |
| spaMode | No | SPA framework mode for better stability detection | |
| fullPage | No | Capture full page screenshot | |
| selector | No | CSS selector to screenshot (element screenshot) | |
| waitForIdle | No | Wait for DOM idle time in ms before screenshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses DOM stabilization wait but omits important traits such as output format, storage location, authentication needs, or limitations (e.g., page size). This leaves significant gaps.
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?
Two concise sentences with no wasted words. Information is front-loaded and easy to parse.
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?
Despite 7 parameters, the description is minimal. It does not clarify parameter relationships (e.g., fullPage vs selector exclusivity), return format (no output schema), or session management. Incomplete for a tool with many options.
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 has 100% coverage, so all parameters are described. The description adds marginal value by explaining why DOM waits (for stability), but it does not elaborate on parameter interactions or defaults beyond what schema provides.
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 it takes a screenshot, specifies SPA framework support, and mentions waiting for DOM stability. This distinguishes it from generic screenshot tools and aligns with sibling tools focused on SPA interactions.
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 use for SPA screenshotting but does not provide explicit when-to-use or when-not-to-use guidance. Among siblings, it is the only screenshot tool, so context is implicit but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a browser session and close the browser.
| Name | Required | Description | Default |
|---|---|---|---|
| session | No | Session ID to close | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description says 'close the browser' but does not disclose side effects like unsaved state or irreversibility of the session.
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?
Very brief (6 words) but could benefit from a note about session validity or cleanup. Not excessively long but lacks informative structure.
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 and lack of output schema, the description is minimal. It could mention post-end behavior or that no further actions are possible.
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 covers 100% of parameters with description; the tool description does not add meaning beyond the schema.
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 verb 'End' and resource 'browser session' clearly state the action. Distinguished from sibling tools spa_session_start and spa_session_list.
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 vs alternatives like spa_session_start or what state must exist before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active browser sessions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description implies a read-only operation but does not explicitly disclose behavioral traits such as side effects or output format.
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?
Single, concise sentence with no unnecessary words; highly efficient.
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?
Despite having no parameters, the description lacks details on return values or output structure, which could be useful for an agent.
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?
With zero parameters and 100% schema coverage, the description adds no param info, but baseline 4 applies for tools without parameters.
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 'List all active browser sessions.' clearly specifies the verb (list) and resource (active browser sessions), differentiating it from siblings like spa_session_start or spa_session_end.
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; however, the simple nature of listing sessions makes it self-explanatory in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new persistent browser session. Use sessions to maintain state between tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | Device to emulate | |
| session | No | Session ID to create | default |
| viewport | No | ||
| userAgent | No | Custom user agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions persistence and state maintenance but omits critical traits like session lifespan, behavior if session ID already exists, resource cleanup, or side effects (e.g., setting cookies).
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?
Two sentences, no fluff, front-loaded with the action and purpose. Every word earns its place.
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 has 4 parameters (including a nested viewport) and no output schema, the description is incomplete. It does not explain the viewport/device parameters, nor what the tool returns (e.g., session ID or status).
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 75%, so baseline is 3. The description does not add any parameter information beyond the schema, so it does not improve semantics.
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 starts a new persistent browser session and explains the purpose (maintain state). It implicitly distinguishes from siblings like spa_session_end and spa_session_list, but could be more explicit about what a session entails.
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 some usage context ('Use sessions to maintain state between tool calls') but lacks explicit when-to-use, when-not-to-use, or alternatives. It does not guide when to start a session versus other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text character by character with realistic delays. Best for React controlled inputs and forms with live validation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| delay | No | Delay between keystrokes in ms | |
| value | Yes | Text to type | |
| session | No | Session ID | default |
| spaMode | No | ||
| selector | Yes | CSS selector for input field | |
| clearFirst | No | Clear the field before typing | |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes character-by-character typing with delays, providing behavioral insight. No annotations present, so burden is on description. Lacks details on event triggering, validation waits, or side effects beyond typing.
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: two sentences, no wasted words. Action verb in first sentence, front-loaded with key information.
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?
Tool has 8 parameters, no output schema, no annotations. Description is too brief given complexity. Does not cover behavior after typing, waiting for validation, or how spaMode is used. Significant gaps for a nuanced 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?
Schema description coverage is 88%, high. Description adds minimal value beyond schema; mentions 'character by character' which relates to delay but does not explain other parameters. Baseline 3 is appropriate given high coverage.
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?
Clearly states tool types text character by character with realistic delays. Identifies target use case (React controlled inputs, live validation). Distinguishes from siblings like spa_fill by implying realism, but does not explicitly contrast.
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?
Says 'Best for React controlled inputs and forms with live validation', giving a usage context. Does not explicitly state when not to use it or mention alternatives, though it implies other tools for simpler inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to a file input element.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to first (optional) | |
| file | No | Path to file to upload | |
| files | No | Multiple file paths to upload | |
| session | No | Session ID | default |
| selector | Yes | CSS selector for file input | |
| screenshot | No | Take screenshot after action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as automatic screenshots, navigation to a URL, support for multiple files, or session handling. The agent cannot infer important side effects or requirements.
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 (one sentence), but it sacrifices informativeness. While there is no wasted text, it is under-specifying for a tool with 6 parameters and no annotations.
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 (6 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values, error handling, or expected behavior, leaving significant gaps for the agent.
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?
All 6 parameters have descriptions in the schema (100% coverage), so the description adds no extra meaning. The description merely restates the action, providing no additional semantic value beyond the schema.
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 action (Upload) and the resource (file to file input element), which distinguishes it from sibling tools like spa_click and spa_fill. However, it lacks specificity about the upload process (e.g., single vs multiple files, navigation).
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 no guidance on when to use this tool versus alternatives like spa_fill or spa_click. It does not mention prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for DOM to become idle (no mutations). Useful for SPAs that update the DOM frequently.
| Name | Required | Description | Default |
|---|---|---|---|
| maxWait | No | Maximum wait time in ms | |
| session | No | Session ID | default |
| idleTime | No | Required idle time in ms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It explains the idle detection concept but omits critical details: what happens on timeout, return type, side effects on session.
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?
Two concise sentences front-loaded with action and purpose. No unnecessary 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?
Simple tool with optional parameters. Missing return value info, but no output schema required. Otherwise adequate for expected usage.
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 covers all three parameters with descriptions. Description adds no additional parameter context beyond what schema provides.
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?
Clearly states verb (wait), resource (DOM), and condition (idle, no mutations). Distinguishes from sibling tools which are interaction or navigation actions.
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?
Mentions usefulness for SPAs that update DOM frequently, implying when to use. However, no explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but spa_click/spa_iframe_click and spa_fill/spa_iframe_fill are similar except for iframe context, which is clear. spa_type_realistic is a variant of fill. Overall well-differentiated.
All tools follow a consistent 'spa_verb_noun' pattern using snake_case, making it easy to understand the action and target.
16 tools is appropriate for a comprehensive SPA testing server, covering essential operations without being overwhelming.
The tool set covers core SPA interactions (click, fill, navigate, upload, drag, assertions, sessions) and HTTP requests. Minor gaps like screenshot or network interception are missing but not critical for basic SPA testing.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/manganate006/playwright-spa-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
