Provides browser automation capabilities to GitHub Copilot agents in VS Code, enabling web interaction, screenshot capture, test code generation, web scraping, and JavaScript execution in browsers.
Supports test automation with Jest, allowing for browser testing and interaction capabilities within test suites.
Special integration with Warp, the AI terminal for developers, as highlighted in the special thanks section of the README.
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., "@Playwright MCP Server take a screenshot of the GitHub homepage"
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.
A Model Context Protocol server that provides browser automation capabilities using Playwright. This server enables LLMs to interact with web pages, take screenshots, generate test code, web scraps the page and execute JavaScript in a real browser environment.
Related MCP server: Puppeteer MCP Server
You can install the package using either npm, mcp-get, or Smithery:
Using npm:
npm install -g @executeautomation/playwright-mcp-serverUsing mcp-get:
npx @michaellatman/mcp-get@latest install @executeautomation/playwright-mcp-serverUsing Smithery
To install Playwright MCP for Claude Desktop automatically via Smithery:
npx @smithery/cli install @executeautomation/playwright-mcp-server --client claudeInstall the Playwright MCP server in VS Code using one of these buttons:
Alternatively, you can install the Playwright MCP server using the VS Code CLI:
# For VS Code
code --add-mcp '{"name":"playwright","command":"npx","args":["@executeautomation/playwright-mcp-server"]}'# For VS Code Insiders
code-insiders --add-mcp '{"name":"playwright","command":"npx","args":["@executeautomation/playwright-mcp-server"]}'After installation, the ExecuteAutomation Playwright MCP server will be available for use with your GitHub Copilot agent in VS Code.
Here's the Claude Desktop configuration to use the Playwright server:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@executeautomation/playwright-mcp-server"]
}
}
}This project uses Jest for testing. The tests are located in the src/__tests__ directory.
You can run the tests using one of the following commands:
# Run tests using the custom script (with coverage)
node run-tests.cjs
# Run tests using npm scripts
npm test # Run tests without coverage
npm run test:coverage # Run tests with coverage
npm run test:custom # Run tests with custom script (same as node run-tests.cjs)The test coverage report will be generated in the coverage directory.
The evals package loads an mcp client that then runs the index.ts file, so there is no need to rebuild between tests. You can load environment variables by prefixing the npx command. Full documentation can be found here.
OPENAI_API_KEY=your-key npx mcp-eval src/evals/evals.ts src/tools/codegen/index.tsWhen adding new tools, please be mindful of the tool name length. Some clients, like Cursor, have a 60-character limit for the combined server and tool name (server_name:tool_name).
Our server name is playwright-mcp. Please ensure your tool names are short enough to not exceed this limit.
Clear a code generation session without generating a test
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the session to clear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool clears a session but doesn't explain what 'clear' entails—whether it deletes data, resets state, or has side effects like requiring specific permissions or affecting other sessions. This lack of detail makes it hard for an agent to predict outcomes or assess risks.
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 that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly and understand the core action.
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 tool that performs a mutation (clearing a session) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, side effects, or what happens after clearing, which are critical for an agent to use it correctly and safely in context with sibling tools.
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 input schema has 100% description coverage, with the 'sessionId' parameter well-documented. The description doesn't add any extra meaning about parameters beyond what the schema provides, such as format or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear') and resource ('a code generation session'), and distinguishes it from generating tests. However, it doesn't explicitly differentiate from its sibling 'end_codegen_session', which might serve a similar purpose, leaving some ambiguity about when to use one versus the other.
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 minimal guidance by mentioning 'without generating a test', but it doesn't specify when to use this tool versus alternatives like 'end_codegen_session' or other session management tools. No explicit context or exclusions are provided, leaving the agent with little direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a code generation session and generate the test file
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the session to end |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions generating a test file, which adds context beyond the basic action, but fails to describe critical traits like whether this is a destructive operation (likely yes, as it ends a session), what permissions are needed, or what happens to the session data. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('End a code generation session') and adds the secondary outcome ('generate the test file') without unnecessary words. Every part earns its place by clarifying the tool's 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?
Given the complexity of ending a session and generating a test file, with no annotations and no output schema, the description is incomplete. It lacks details on what the tool returns (e.g., the generated test file content or confirmation), error conditions, or side effects, making it inadequate for an agent to fully understand the tool's context.
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 input schema has 100% description coverage, with the single parameter 'sessionId' well-documented in the schema. The description does not add any meaning beyond what the schema provides, such as format examples or constraints, but the high schema coverage justifies a baseline score of 3.
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 'end' and resource 'code generation session' with the additional action 'generate the test file', making the purpose specific and actionable. It distinguishes from siblings like 'clear_codegen_session' (which likely clears without generating) and 'get_codegen_session' (which retrieves without ending), though it doesn't explicitly name these alternatives.
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 like 'clear_codegen_session' or 'start_codegen_session', nor does it mention prerequisites such as requiring an active session. The description implies usage after a session but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a code generation session
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID of the session to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't specify what information is returned (e.g., session status, code generated, errors), whether it requires authentication, or any rate limits. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'information' is returned (e.g., session details, generated code, errors), which is critical for a tool with no structured output documentation. This gap reduces 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 description coverage is 100%, with the single parameter 'sessionId' clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 for adequate coverage when the schema handles the documentation.
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 ('Get') and resource ('information about a code generation session'), making the purpose understandable. It distinguishes from most sibling tools (which are Playwright actions), though it doesn't explicitly differentiate from 'clear_codegen_session' and 'end_codegen_session' which also operate on codegen sessions.
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. It doesn't mention prerequisites (e.g., needing a session ID from 'start_codegen_session'), nor does it differentiate from similar tools like 'clear_codegen_session' or 'end_codegen_session' beyond their names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for and validate a previously initiated HTTP response wait operation.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Identifier of the HTTP response initially expected using `Playwright_expect_response`. | |
| value | No | Data to expect in the body of the HTTP response. If provided, the assertion will fail if this value is not found in the response body. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions waiting and validation, which implies this is a read-only check, but doesn't disclose behavioral traits like timeout behavior, error handling, or what happens if validation fails. The description is too vague to fully inform the agent about how this tool behaves beyond its basic purpose.
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 that front-loads the core purpose without unnecessary details. It earns its place by clearly stating the tool's function, making it easy for an agent to quickly understand what the tool does.
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 validating HTTP responses, no annotations, and no output schema, the description is incomplete. It lacks details on what the tool returns (e.g., success/failure status, response data), error conditions, or dependencies on other tools like 'playwright_expect_response'. This leaves significant gaps for an agent to use the tool effectively in a testing context.
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 the schema already documents both parameters ('id' and 'value'). The description adds minimal semantic context by referencing 'previously initiated HTTP response wait operation,' which aligns with the 'id' parameter. However, it doesn't provide additional meaning beyond what the schema offers, such as examples or edge cases, meeting the baseline for high schema 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?
The description clearly states the tool's purpose: 'Wait for and validate a previously initiated HTTP response wait operation.' It specifies the action (wait and validate) and the resource (HTTP response from a wait operation). However, it doesn't explicitly distinguish this tool from its sibling 'playwright_expect_response', which likely initiates the wait operation that this tool validates.
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 by referencing 'previously initiated HTTP response wait operation' and 'initially expected using `Playwright_expect_response`' in the schema, suggesting this tool follows that sibling. However, it doesn't provide explicit guidance on when to use this versus alternatives or any exclusions, leaving some ambiguity about its specific context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'click' implies an interactive action, it doesn't describe what happens after clicking (e.g., navigation, form submission, JavaScript execution), error conditions, or performance characteristics. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the essential 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 complexity of browser automation and the lack of both annotations and output schema, the description is insufficient. It doesn't explain what the tool returns (if anything), error handling, or important behavioral details like waiting for elements to be clickable. For a tool with no structured safety or output information, this leaves too many gaps.
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 input schema has 100% description coverage, with the 'selector' parameter clearly documented as a CSS selector. The description doesn't add any meaningful semantic information beyond what the schema already provides, so it meets the baseline for high schema 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?
The description clearly states the action ('click') and target ('an element on the page'), providing a specific verb+resource combination. However, it doesn't distinguish itself from sibling tools like 'playwright_iframe_click' or 'playwright_click_and_switch_tab', which would require more specific differentiation.
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. There's no mention of prerequisites (e.g., needing a page to be loaded), when not to use it, or how it differs from similar sibling tools like 'playwright_iframe_click' or 'playwright_click_and_switch_tab'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click a link and switch to the newly opened tab
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the link to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action and outcome but lacks details on error handling (e.g., if no new tab opens), performance (e.g., waiting for tab load), or side effects (e.g., closing old tabs). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficient, with every part contributing to understanding the purpose and outcome.
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 (involving tab management and interaction) and lack of annotations and output schema, the description is insufficient. It does not cover return values, error conditions, or behavioral nuances like waiting for the new tab to load, which are critical 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?
The input schema has 100% description coverage, with the 'selector' parameter fully documented. The description does not add any semantic details beyond the schema, such as examples of valid selectors or how to handle dynamic content. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 ('click a link') and the outcome ('switch to the newly opened tab'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'playwright_click' (which clicks without tab switching) or 'playwright_navigate' (which navigates within the same tab), missing full sibling distinction.
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 when clicking a link that opens a new tab, but it does not provide explicit guidance on when to use this tool versus alternatives like 'playwright_click' (for same-tab clicks) or 'playwright_navigate' (for direct navigation). No exclusions or prerequisites are mentioned, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the browser and release all resources
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'release all resources', which hints at cleanup, but doesn't specify whether this is destructive (e.g., closes all tabs, ends sessions), irreversible, or has side effects like terminating ongoing operations. More detail on behavioral traits is needed 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, efficient sentence that front-loads the key action ('Close the browser') and adds a clarifying detail ('release all resources'). Every word earns its place with no waste.
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 (a mutation with no parameters) and lack of annotations or output schema, the description is minimally adequate. It states what the tool does but doesn't fully cover behavioral aspects like effects or prerequisites, leaving gaps in completeness for safe 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?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter explanation in the description. The baseline for this scenario is 4, as the description appropriately doesn't add unnecessary param details.
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 ('Close') and the resource ('the browser'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'end_codegen_session' or 'clear_codegen_session', which might also involve cleanup operations, so it doesn't reach the highest score.
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, such as when to close the browser versus keeping it open for other operations, or how it relates to session management tools like 'end_codegen_session'. It lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve console logs from the browser with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type of logs to retrieve (all, error, warning, log, info, debug, exception) | |
| search | No | Text to search for in logs (handles text with square brackets) | |
| limit | No | Maximum number of logs to return | |
| clear | No | Whether to clear logs after retrieval (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions 'filtering options' but doesn't disclose important behaviors like whether this requires an active Playwright session, what format the logs are returned in, if there are rate limits, or what happens when no logs exist. The 'clear' parameter description in the schema hints at side effects, but the main description doesn't highlight this.
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 that gets straight to the point. It's appropriately sized for a tool with good schema coverage. Every word earns its place, though it could be slightly more informative given the lack of 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 complexity of browser log retrieval (4 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what format the logs are returned in, whether this requires an active browser context, or what typical use cases are. For a tool with behavioral implications (the 'clear' parameter can modify state), 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 100%, so the schema already fully documents all four parameters. The description adds minimal value beyond the schema by mentioning 'filtering options' which aligns with the 'type' and 'search' parameters. No additional semantic context is provided beyond what's in the structured schema descriptions.
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 ('retrieve') and resource ('console logs from the browser'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'playwright_get_visible_html' or 'playwright_get_visible_text' which also retrieve browser content but different types.
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. The description mentions 'filtering options' but doesn't specify scenarios where this is preferable over other retrieval tools or when it should be avoided. There's no mention of prerequisites like requiring an active browser session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a custom User Agent for the browser
| Name | Required | Description | Default |
|---|---|---|---|
| userAgent | Yes | Custom User Agent for the Playwright browser instance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action without details on effects (e.g., whether it persists across sessions, impacts other tools, or requires specific permissions). It doesn't mention potential side effects like breaking website functionality or rate limits, leaving 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?
The description is a single, direct sentence with zero wasted words, front-loading the core action and resource. It efficiently conveys the essential information without unnecessary elaboration, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a tool that modifies browser behavior. It doesn't explain what happens after setting the User Agent (e.g., success confirmation, error handling, or impact on subsequent actions), leaving the agent with insufficient context for reliable 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?
The input schema has 100% description coverage, with the 'userAgent' parameter clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as examples or format constraints, so it meets the baseline for high schema coverage without enhancing parameter understanding.
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 ('Set') and the resource ('custom User Agent for the browser'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'playwright_get' or 'playwright_navigate', but the specificity of 'User Agent' distinguishes it from general browser interaction tools.
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, such as whether it's for testing specific browser versions, bypassing detection, or other scenarios. It lacks context about prerequisites (e.g., requiring an active browser session) or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an HTTP DELETE request
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to perform DELETE operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it performs an HTTP DELETE request, which implies a destructive operation, but doesn't clarify permissions needed, rate limits, error handling, or what happens upon success (e.g., deletion confirmation). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.
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 this is a destructive HTTP operation with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., response status, body), error conditions, or side effects, leaving significant gaps for an agent to use it correctly.
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 input schema has 100% description coverage, with the 'url' parameter clearly documented. The description doesn't add any meaning beyond the schema, such as URL format examples or constraints. Baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform an HTTP DELETE request' states the action (HTTP DELETE) but is generic and doesn't specify what resource it operates on or differentiate it from other HTTP method tools like playwright_post or playwright_put. It's clear but lacks specificity about what gets deleted.
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 like playwright_post or playwright_put for other HTTP methods, or versus non-HTTP tools in the sibling list. The description implies usage for DELETE requests but doesn't specify contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drag an element to a target location
| Name | Required | Description | Default |
|---|---|---|---|
| sourceSelector | Yes | CSS selector for the element to drag | |
| targetSelector | Yes | CSS selector for the target location |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'drag' implies a UI interaction that modifies element position, the description doesn't specify whether this requires the page to be in a particular state, what happens if selectors don't match, whether it waits for animations, or what visual feedback occurs. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, focused sentence that communicates the core functionality without any wasted words. It's front-loaded with the essential action and doesn't include unnecessary elaboration or repetition. Every word earns its place in conveying the tool's purpose efficiently.
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 UI interaction tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after the drag operation, whether there's visual feedback, error conditions, or what state the page should be in beforehand. Given that this is a mutation operation (dragging changes UI state) with zero structured metadata about behavior, the description should provide more contextual guidance about how and when to use it effectively.
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%, with both parameters clearly documented in the schema. The description doesn't add any additional semantic context about the parameters beyond what's already in the schema descriptions. It doesn't explain selector syntax expectations, provide examples, or clarify what constitutes a valid 'target location.' With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('drag') and resource ('an element to a target location'), making the purpose immediately understandable. It distinguishes itself from other playwright tools by focusing specifically on drag-and-drop functionality rather than clicking, filling, or navigating. However, it doesn't explicitly differentiate from potential similar drag operations that might exist in the sibling set.
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. There's no mention of prerequisites (like needing a page to be loaded), comparison with similar playwright actions, or specific scenarios where dragging is appropriate versus other interaction methods. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser console
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical details: it doesn't specify execution context (e.g., current page, frame), error handling, return values, or side effects (e.g., whether it waits for page loads). This is inadequate for a tool that executes arbitrary code in a browser environment.
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 zero wasted words. It's front-loaded with the core action and context, making it immediately understandable without unnecessary elaboration 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?
For a tool that executes JavaScript in a browser—a potentially complex operation with no annotations or output schema—the description is insufficient. It misses key details: execution scope, return behavior, error cases, and how it integrates with other Playwright tools. This leaves significant gaps for an agent to use it effectively and safely.
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 description adds no parameter-specific information beyond what the schema provides. Since schema description coverage is 100% (the 'script' parameter is fully documented), the baseline score of 3 applies. The description doesn't elaborate on script constraints, examples, or execution nuances, so it doesn't add value over the structured 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 ('Execute JavaScript') and the context ('in the browser console'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'playwright_console_logs' which might also interact with the console, leaving room for ambiguity about when to use one versus the other.
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. It doesn't mention prerequisites (e.g., needing an active browser session), exclusions, or compare it to other JavaScript execution methods in the sibling list, leaving the agent to infer usage context solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Playwright to start waiting for a HTTP response. This tool initiates the wait operation but does not wait for its completion.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique & arbitrary identifier to be used for retrieving this response later with `Playwright_assert_response`. | |
| url | Yes | URL pattern to match in the response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is non-blocking ('does not wait for its completion'), which is a key behavioral trait. However, it lacks details on error handling, timeout behavior, concurrency limits, or how it integrates with Playwright's context (e.g., page or browser scope). For a tool initiating asynchronous operations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: two sentences that directly state the purpose and key behavioral trait. Every sentence earns its place by clarifying the tool's action and its non-blocking nature, with zero wasted words or redundant 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 complexity (initiating async HTTP response waits), lack of annotations, and no output schema, the description is minimally complete. It covers the basic purpose and non-blocking behavior but omits critical context like error handling, timeout details, or integration with sibling tools (e.g., how 'id' links to 'playwright_assert_response'). For a tool with no structured safety or output info, it should do more to guide 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 description coverage is 100%, so the schema already documents both parameters ('id' and 'url') with clear descriptions. The description adds no additional meaning beyond what's in the schema, such as explaining parameter interactions or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask Playwright to start waiting for a HTTP response.' It specifies the verb ('start waiting') and resource ('HTTP response'), distinguishing it from sibling tools like 'playwright_assert_response' which retrieves the response. However, it doesn't explicitly differentiate from other waiting or monitoring tools in the sibling list, such as those handling navigation or events.
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 by stating it 'initiates the wait operation but does not wait for its completion,' suggesting it's used to set up a response expectation without blocking. It hints at an alternative ('playwright_assert_response' for retrieval) but doesn't explicitly state when to use this tool vs. others (e.g., for async monitoring vs. immediate actions). No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fill out an input field
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for input field | |
| value | Yes | Value to fill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'fill out an input field' implies a write operation but doesn't specify whether it requires the field to be visible/interactable, if it triggers events, or what happens on failure. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('fill out an input field') that directly conveys the core function without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances (e.g., waiting for the field to be ready). Given the complexity of browser automation, more context is needed 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?
The input schema has 100% description coverage, with clear documentation for both parameters ('selector' and 'value'). The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'fill out an input field' clearly states the action (fill) and target (input field), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'playwright_iframe_fill', which appears to serve a similar purpose for iframes, so it doesn't reach the highest score for sibling differentiation.
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 'playwright_iframe_fill' or other input-related tools. It lacks context about prerequisites (e.g., needing an active page) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an HTTP GET request
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to perform GET operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Perform an HTTP GET request' gives minimal information - it doesn't describe what happens (does it follow redirects? handle cookies? return headers?), error behavior, timeout settings, or any side effects. This is inadequate for a tool that makes network requests.
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 maximally concise - a single clear sentence that states exactly what the tool does. There's zero waste or unnecessary elaboration.
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 network request tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (response body, status code, headers), error conditions, or behavioral characteristics. Given the complexity of HTTP requests and lack of structured metadata, 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 100% with the single 'url' parameter well-documented in the schema. The description doesn't add any parameter information beyond what the schema provides (no format requirements, validation rules, or examples). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform an HTTP GET request') which is a specific verb+resource combination. It distinguishes from siblings like playwright_post, playwright_put, playwright_delete by specifying the HTTP method, though it doesn't explicitly mention these alternatives in the description itself.
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. It doesn't mention when to choose GET over other HTTP methods available in sibling tools (post, put, delete, patch) or when to use playwright_navigate for navigation versus playwright_get for HTTP requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the HTML content of the current page. By default, all tags are removed from the output unless removeScripts is explicitly set to false.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No | CSS selector to limit the HTML to a specific container | |
| removeScripts | No | Remove all script tags from the HTML (default: true) | |
| removeComments | No | Remove all HTML comments (default: false) | |
| removeStyles | No | Remove all style tags from the HTML (default: false) | |
| removeMeta | No | Remove all meta tags from the HTML (default: false) | |
| cleanHtml | No | Perform comprehensive HTML cleaning (default: false) | |
| minify | No | Minify the HTML output (default: false) | |
| maxLength | No | Maximum number of characters to return (default: 20000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: script tags are removed by default unless overridden. However, it doesn't mention other important behaviors like whether it returns only visible HTML (implied by the name), error conditions, performance implications, or output format details. The description adds some value but leaves 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?
The description is extremely concise—two sentences that directly state the tool's purpose and a key default behavior. Every word earns its place with no fluff or redundancy. It's front-loaded with the core functionality.
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 tool with 8 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose and one default behavior but lacks context about when to use it, what 'visible' means operationally, or how the output is structured. Given the complexity and lack of annotations, it should provide more guidance.
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 the schema fully documents all 8 parameters. The description adds minimal value beyond the schema by mentioning the default behavior for removeScripts. It doesn't explain parameter interactions (e.g., how cleanHtml relates to other options) or provide usage examples. Baseline 3 is appropriate given high schema 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?
The description clearly states the tool's purpose: 'Get the HTML content of the current page.' It specifies the verb ('Get') and resource ('HTML content'), but doesn't explicitly differentiate from sibling tools like playwright_get_visible_text, which might return text instead of HTML. The mention of script tag removal adds specificity but not sibling distinction.
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. It doesn't mention sibling tools like playwright_get_visible_text for text extraction or playwright_screenshot for visual capture, nor does it specify prerequisites (e.g., requiring a page to be loaded). Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the visible text content of the current page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't mention performance aspects, error handling, or that it might return only visible text (excluding hidden elements), leaving gaps in understanding how it behaves in practice.
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, direct sentence that efficiently conveys the core functionality without any fluff. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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 (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on output format, error cases, or integration with sibling tools, which could help in more complex scenarios.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't add unnecessary param details, but since there are no parameters, it doesn't provide any semantic value beyond the baseline, which is a 4 for zero 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 action ('Get') and target ('visible text content of the current page'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'playwright_get_visible_html', which retrieves HTML rather than text, so it misses the highest score.
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, such as 'playwright_get_visible_html' for HTML content or other text-extraction methods. It lacks context about prerequisites, like needing an active page session, which is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate back in browser history
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Navigate back' implies a navigation action, it doesn't specify whether this requires an existing browser context, what happens if there's no history to go back to, or any error conditions. This leaves significant behavioral gaps for a tool that likely interacts with browser 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?
The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It's perfectly front-loaded and wastes no space, making it ideal for quick comprehension.
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 likely complexity (browser navigation with potential state dependencies), the description is insufficient. With no annotations, no output schema, and minimal behavioral context, it doesn't provide enough information for reliable use. A better description would explain prerequisites, failure conditions, or relationship to other navigation tools.
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 zero parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't add parameter information beyond what's already covered, earning a baseline score of 4 for this dimension.
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 verb ('Navigate back') and resource ('browser history'), making the purpose immediately understandable. However, it doesn't explicitly distinguish itself from its sibling 'playwright_go_forward', which would have earned a perfect score.
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 'playwright_navigate' or 'playwright_go_forward'. It lacks any context about prerequisites (e.g., requiring an active browser session) or typical use cases, leaving the agent with minimal usage direction.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits like what happens if no forward history exists (e.g., error, no-op), whether it waits for page load, or if it's synchronous/asynchronous. For a navigation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Navigate forward in browser history') with zero waste. It's appropriately sized and front-loaded, conveying the core purpose immediately without unnecessary elaboration.
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 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. However, as a navigation tool with no annotations, it lacks details on behavior (e.g., error handling, page load waits) that would help an agent use it correctly. It's complete for basic understanding but has clear gaps.
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 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional value is required or provided.
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 forward in browser history' clearly states the verb ('Navigate forward') and resource ('browser history'), distinguishing it from siblings like 'playwright_go_back' (backward navigation) and 'playwright_navigate' (new URL navigation). It's specific and unambiguous.
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 context (browser navigation) but doesn't explicitly state when to use this vs. alternatives like 'playwright_go_back' or 'playwright_navigate'. It's clear from the name and purpose, but lacks explicit guidance on prerequisites (e.g., requires forward history to exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to hover |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('hover') but doesn't explain what happens during hovering (e.g., whether it triggers events, waits for animations, or handles errors). This leaves gaps in understanding the tool's behavior beyond 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?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, earning full marks for brevity and clarity.
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 lack of annotations and output schema, the description is incomplete for a tool that performs an interactive action. It doesn't cover behavioral aspects like error handling, return values, or side effects (e.g., page state changes), which are crucial for an AI agent to use it effectively in automation scenarios.
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 input schema has 100% description coverage, with the 'selector' parameter fully documented. The description adds no additional meaning beyond what the schema provides, such as examples or constraints on selectors. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
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 ('hover') and resource ('an element on the page'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'playwright_click' or 'playwright_press_key', which would require more specific context about hover interactions versus other 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?
No guidance is provided on when to use this tool versus alternatives such as 'playwright_click' or 'playwright_press_key'. The description lacks context about hover-specific scenarios, like triggering dropdowns or tooltips, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element in an iframe on the page
| Name | Required | Description | Default |
|---|---|---|---|
| iframeSelector | Yes | CSS selector for the iframe containing the element to click | |
| selector | Yes | CSS selector for the element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Click') but doesn't describe what happens after clicking (e.g., page navigation, element state changes), error conditions (e.g., if selectors are invalid), or performance implications (e.g., waiting for iframe load). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and target, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return value (e.g., success/failure status), error handling, or side effects like page changes. Given the complexity of interacting with iframes, more context is needed 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 description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any additional meaning beyond implying that 'iframeSelector' targets an iframe and 'selector' targets an element within it, which is already evident from the schema. This meets the baseline for high schema 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?
The description clearly states the action ('Click') and target ('an element in an iframe on the page'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'playwright_click' (which clicks elements outside iframes) or 'playwright_iframe_fill' (which fills iframe elements), missing full sibling differentiation.
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. It doesn't mention that 'playwright_click' should be used for non-iframe elements or 'playwright_iframe_fill' for filling iframe inputs, nor does it specify prerequisites like requiring the page to be loaded with the iframe present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an element in an iframe on the page
| Name | Required | Description | Default |
|---|---|---|---|
| iframeSelector | Yes | CSS selector for the iframe containing the element to fill | |
| selector | Yes | CSS selector for the element to fill | |
| value | Yes | Value to fill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action ('fill') but doesn't disclose behavioral traits such as whether this is a mutation (likely yes), error handling (e.g., if selectors fail), side effects, or response format. This leaves significant gaps for a tool with potential UI interactions.
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 that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, with zero waste.
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 annotations, no output schema, and a tool that likely performs UI mutations (filling elements), the description is incomplete. It lacks details on behavior, error cases, or return values, making it inadequate for safe and effective use by an AI agent in a complex context like Playwright automation.
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%, with clear descriptions for all three parameters (iframeSelector, selector, value). The description adds no additional meaning beyond the schema, such as examples or constraints, but the schema provides adequate baseline documentation.
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 target ('an element in an iframe on the page'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'playwright_fill' (which fills elements not in iframes) or 'playwright_iframe_click' (which clicks rather than fills), missing full sibling distinction.
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 'playwright_fill' for non-iframe elements or other iframe-related tools. There's no mention of prerequisites (e.g., needing an iframe context) or exclusions, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an HTTP PATCH request
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to perform PUT operation | |
| value | Yes | Data to PATCH in the body |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Perform an HTTP PATCH request' which implies a network operation with potential side effects, but doesn't disclose traits like error handling, authentication needs, rate limits, or what happens on success/failure. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Perform an HTTP PATCH request' is front-loaded and appropriately sized for its purpose. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an HTTP PATCH tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error cases, or usage context. While the schema covers parameters, the overall tool understanding is inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'url' and 'value' parameters clearly documented. The description adds no additional meaning beyond what the schema provides (e.g., no details on URL format or data encoding). With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform an HTTP PATCH request' clearly states the action (PATCH) but is generic and doesn't specify what resource or context it operates on. It distinguishes from siblings like playwright_post or playwright_put by mentioning PATCH, but lacks specificity about the target (e.g., web pages, APIs). This is vague but not tautological.
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 playwright_put or playwright_post, nor does it mention prerequisites or context. It implies usage for HTTP PATCH requests but offers no explicit when/when-not rules or sibling comparisons, leaving the agent to infer based on general HTTP knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an HTTP POST request
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to perform POST operation | |
| value | Yes | Data to post in the body | |
| token | No | Bearer token for authorization | |
| headers | No | Additional headers to include in the request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states the action but doesn't describe what happens on failure, timeout behavior, retry logic, response handling, or any side effects. For a tool that performs network operations, this leaves significant behavioral questions unanswered.
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 with just four words that directly convey the core function. There's zero wasted language or unnecessary elaboration, making it immediately scannable and understandable. The structure is front-loaded with the essential 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?
For a tool performing HTTP POST operations with 4 parameters and no output schema, the description is insufficient. It doesn't explain what the tool returns, how errors are handled, or provide context about the playwright automation environment. Given the complexity of HTTP operations and lack of annotations/output schema, more completeness 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 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide extra value like examples, constraints, or usage patterns.
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 'Perform an HTTP POST request' clearly states the action (POST) and resource (HTTP request), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling POST-related tools like playwright_patch or playwright_put, which would require more specific differentiation.
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. With multiple HTTP method tools available (POST, PATCH, PUT, DELETE, GET), there's no indication of when POST is appropriate versus other methods or how this tool relates to other playwright tools for web automation tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a keyboard key
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to press (e.g. 'Enter', 'ArrowDown', 'a') | |
| selector | No | Optional CSS selector to focus before pressing key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Press a keyboard key' implies a write/mutation operation but doesn't specify whether this requires a focused element, what happens if no selector is provided, or if there are any side effects like page navigation. It lacks context about permissions, rate limits, 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?
The description is extremely concise with just three words, front-loading the core action. Every word earns its place with zero waste, making it easy to parse quickly.
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 annotations, no output schema, and a mutation tool with behavioral implications, the description is incomplete. It doesn't explain what the tool returns, error conditions, or important usage constraints, leaving significant gaps for an AI agent to understand proper invocation.
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%, with both parameters ('key' and 'selector') well-documented in the schema. The description doesn't add any additional meaning beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.
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 'Press a keyboard key' clearly states the action (press) and resource (keyboard key), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like playwright_click or playwright_fill, which are also input actions but for different types of 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 provides no guidance on when to use this tool versus alternatives. With many sibling tools for different input actions (click, fill, select, etc.), there's no indication of whether this is for general keyboard input, navigation, or specific contexts like form submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform an HTTP PUT request
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to perform PUT operation | |
| value | Yes | Data to PUT in the body |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't describe what happens during execution—such as error handling, response expectations, or side effects. For a mutation tool (PUT implies writing data) with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, avoiding unnecessary elaboration while stating the core action clearly.
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 this is a mutation tool (PUT) with no annotations, no output schema, and minimal description, the description is incomplete. It doesn't explain what the tool returns, error conditions, or how it integrates with the Playwright context (e.g., browser session). For a tool that modifies data, more context is needed to ensure safe and correct 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 description coverage is 100%, with both parameters ('url' and 'value') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format details or examples. Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is added.
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 'Perform an HTTP PUT request' clearly states the action (perform) and resource (HTTP PUT request), but it's generic and doesn't distinguish this tool from its sibling 'playwright_patch' or 'playwright_post' which are also HTTP methods. It lacks specificity about what makes PUT unique compared to other HTTP verbs in this context.
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 'playwright_post' or 'playwright_patch'. It doesn't mention typical use cases for PUT (e.g., updating resources idempotently) or prerequisites, leaving the agent to infer usage from general HTTP knowledge without tool-specific context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current page as a PDF file
| Name | Required | Description | Default |
|---|---|---|---|
| outputPath | Yes | Directory path where PDF will be saved | |
| filename | No | Name of the PDF file (default: page.pdf) | |
| format | No | Page format (e.g. 'A4', 'Letter') | |
| printBackground | No | Whether to print background graphics | |
| margin | No | Page margins |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions saving a PDF but doesn't describe important behaviors: whether this requires a page to be loaded first, if it works on all page states, what happens on failure, or if it modifies browser state. For a tool with potential side effects, this is insufficient.
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 that immediately communicates the core function. There's no wasted verbiage or unnecessary elaboration. It's appropriately sized for a straightforward tool with well-documented parameters.
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 tool with 5 parameters (including a nested object) and no annotations or output schema, the description is inadequate. It doesn't explain what 'current page' means contextually, doesn't mention prerequisites, and provides no information about return values or error conditions. The combination of complexity and lack of structured documentation requires more descriptive content.
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 well-documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. This meets the baseline for high schema coverage but doesn't provide extra context about parameter interactions or usage patterns.
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 ('Save') and resource ('current page as a PDF file'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'playwright_screenshot', which also captures page content but in image format rather than PDF.
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. For example, it doesn't mention when to choose PDF over screenshot formats or how it relates to other Playwright tools for page capture. The description only states what it does, not when it's 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 the current page or a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the screenshot | |
| selector | No | CSS selector for element to screenshot | |
| width | No | Width in pixels (default: 800) | |
| height | No | Height in pixels (default: 600) | |
| storeBase64 | No | Store screenshot in base64 format (default: true) | |
| fullPage | No | Store screenshot of the entire page (default: false) | |
| savePng | No | Save screenshot as PNG file (default: false) | |
| downloadsDir | No | Custom downloads directory path (default: user's Downloads folder) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It mentions what the tool does but doesn't describe important behavioral aspects like whether it requires an active browser session, what happens if the selector doesn't exist, how errors are handled, or what the output format looks like (beyond the parameter hints).
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 perfectly concise - a single sentence that immediately communicates the core functionality without any wasted words. It's front-loaded with the essential action and resource, making it highly efficient for quick comprehension.
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 tool with 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the relationship between parameters (e.g., how 'fullPage' interacts with 'selector'), what the tool returns, error conditions, or dependencies on other tools like 'playwright_get' to establish a page context first.
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 description mentions 'current page or a specific element' which hints at the 'selector' parameter's purpose, but adds little beyond what the comprehensive schema already provides. With 100% schema description coverage, the baseline is 3, and the description doesn't significantly enhance understanding of parameter interactions or edge cases.
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 with a specific verb ('Take a screenshot') and resource ('current page or a specific element'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'playwright_save_as_pdf' or explain when to choose screenshot vs PDF capture, which prevents a perfect score.
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. With sibling tools like 'playwright_save_as_pdf' available, there's no indication of when screenshot capture is preferable to PDF generation, nor any mention of prerequisites or typical use cases for this specific screenshot functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an element on the page with Select tag
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to select | |
| value | Yes | Value to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Select') but doesn't clarify if this is a read-only or mutating operation, what happens on success/failure (e.g., error handling), or any side effects (e.g., page state changes). This is inadequate for a tool that likely modifies page elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple tool, with every part contributing to understanding.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'Select' entails (e.g., dropdown interaction, visual feedback), return values, or error conditions. For a tool with 2 parameters and likely mutating behavior, more context is needed to guide 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 description coverage is 100%, so the schema already documents both parameters (selector and value) with clear descriptions. The description adds no additional meaning beyond implying these parameters are used together to select an element, which aligns with but doesn't enhance the schema information.
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 ('Select') and target ('element on the page with Select tag'), which is specific enough to understand the tool's function. However, it doesn't explicitly differentiate from sibling tools like playwright_click or playwright_fill, which might also interact with page elements but serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring an active page context), exclusions, or compare it to similar sibling tools like playwright_click for general interactions or playwright_fill for input fields, leaving the agent to infer usage context.
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 an input[type='file'] element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the file input element | |
| filePath | Yes | Absolute path to the file to upload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether this requires the page to be in a specific state, if it waits for upload completion, error handling for invalid selectors or file paths, or any side effects like page navigation. For a mutation tool with zero annotation coverage, this is insufficient.
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 with zero wasted words. It is front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after upload (e.g., success/failure indicators, return values, or page changes). Given the complexity of file upload interactions and lack of structured data, more context is needed for effective agent 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 description coverage is 100%, so the schema already documents both parameters (selector and filePath) adequately. The description adds no additional meaning beyond what the schema provides, such as examples of valid selectors or file path formats. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('upload a file') and target resource ('to an input[type='file'] element on the page'), distinguishing it from sibling tools like playwright_fill or playwright_post which handle different interactions. The verb+resource combination is precise and unambiguous.
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 playwright_fill (for text inputs) or playwright_post (for HTTP file uploads). It lacks context about prerequisites (e.g., needing a file input element visible on the page) or exclusions (e.g., not working for non-file inputs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new code generation session to record Playwright actions
| Name | Required | Description | Default |
|---|---|---|---|
| options | Yes | Code generation options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool starts a session to record actions, implying a stateful, write-like operation, but doesn't cover critical aspects like whether this requires specific permissions, if it's idempotent, what happens on conflicts, or the session's lifecycle. For a tool that likely mutates state, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It uses clear language and avoids redundancy, making it easy to parse quickly. Every word earns its place by conveying essential 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 complexity (starting a stateful session for code generation), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what a 'session' entails, how recording works, what the expected outcomes are, or error conditions. For a tool that likely involves significant behavioral nuances, this leaves too many gaps for effective agent 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?
The schema description coverage is 100%, so the schema fully documents the single parameter 'options' and its nested properties. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain how 'outputPath' relates to session persistence or default behaviors). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'start' and resource 'code generation session' with the purpose 'to record Playwright actions'. It distinguishes from siblings like 'end_codegen_session' and 'clear_codegen_session' by indicating it initiates a session rather than terminating or resetting one. However, it doesn't explicitly differentiate from 'get_codegen_session', which might retrieve session details.
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. It doesn't mention prerequisites (e.g., whether a session must be active or inactive), when to choose this over other session tools, or typical workflows. This leaves the agent without context for decision-making.
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.
clear_codegen_sessionend_codegen_sessionget_codegen_sessionplaywright_assert_responseplaywright_clickplaywright_click_and_switch_tabplaywright_closeplaywright_console_logsplaywright_custom_user_agentplaywright_deleteplaywright_dragplaywright_evaluateplaywright_expect_responseplaywright_fillplaywright_getplaywright_get_visible_htmlplaywright_get_visible_textplaywright_go_backplaywright_go_forwardplaywright_hoverplaywright_iframe_clickplaywright_iframe_fillplaywright_navigateplaywright_patchplaywright_postplaywright_press_keyplaywright_putplaywright_save_as_pdfplaywright_screenshotplaywright_selectplaywright_upload_filestart_codegen_sessionMost tools have distinct purposes, with clear separation between browser actions (click, fill, navigate), HTTP methods (get, post, put), and code generation operations. However, some overlap exists between playwright_click and playwright_iframe_click, and between playwright_fill and playwright_iframe_fill, which could cause confusion about when to use the iframe variants.
Excellent naming consistency throughout. All tools follow a clear snake_case pattern with descriptive verb_noun combinations. The three code generation tools use consistent 'codegen_session' terminology, while all Playwright tools use the 'playwright_' prefix followed by specific actions.
32 tools is borderline heavy for a Playwright automation server. While Playwright has many capabilities, this feels like it could be consolidated (e.g., HTTP methods could be a single tool with a method parameter). The count suggests potential for tool bloat rather than focused, essential operations.
The tool surface provides comprehensive coverage for browser automation and testing. It includes navigation, interaction (click, fill, hover), HTTP operations, iframe handling, debugging (logs, screenshots), PDF generation, and code generation sessions. No obvious gaps exist for typical Playwright workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
A Model Context Protocol server for Wix AI tools
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devskido/customed-playwright'
If you have feedback or need assistance with the MCP directory API, please join our Discord server