This server, VUDA (Visual UI Debug Agent), provides a suite of MCP tools for visual UI debugging and testing of web applications using Playwright across local, Browserbase, Anchor, or CDP browsers. Key capabilities include:
Screenshots & Visual Capture: Capture URLs, full pages, viewports, elements, local files, and batch screenshots for side-by-side comparison; run visual comparisons with pixel-level diff highlighting.
Page Analysis & DOM Inspection: All-in-one page analyzer (screenshot, console logs, interactive element mapping, performance metrics); DOM inspector for element properties, children, and computed CSS; extract visible text or full HTML.
Workflow & Navigation Automation: Execute and validate multi-step user workflows with assertions; test navigation flows across pages; directly control the browser via navigate, click, iframe click, fill, select, hover, press key, drag, go back/forward, and evaluate JavaScript.
Console & Performance Monitoring: Capture and filter console logs; collect page load, network idle, and other performance metrics over multiple iterations.
API & Site Testing: Exercise multiple HTTP endpoints with various methods and auth support; recursively crawl sitemaps to discover pages, detect broken links, and extract content.
Session & State Management: Save and retrieve debugging notes; set up Cloudflare tunnels or store/retrieve tunnel URLs; import cookies or storage state for authenticated sessions.
Device Emulation: Emulate devices such as iPhone 13 or Pixel 5 via an optional device parameter.
Multiple Browser Providers: Support local, Browserbase, Anchor, or CDP browser environments.
Provides guidance and management for setting up Cloudflare tunnels to enable remote debugging of web applications.
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., "@visual-ui-debug-agent-mcp screenshot https://example.com in mobile view"
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.
VUDA (Visual UI Debug Agent) is a Model Context Protocol server for inspecting and testing web interfaces with Playwright. The MCP server runs locally over standard input/output; its browser can run locally, on Browserbase, on Anchor Browser, or at an existing CDP endpoint. Every tool uses the same selected browser runtime.
Capture full-page, viewport, element, local-file, and batch screenshots.
Map interactive elements and inspect rendered DOM and computed styles.
Execute multi-step UI workflows while preserving browser state.
Monitor console output and analyze page performance.
Compare two rendered states and return a visual diff.
Crawl sitemaps and exercise API endpoints.
Emulate supported Playwright devices.
Related MCP server: PixelCheck
npx -y visual-ui-debug-agent-mcpThe default local mode needs a Chromium-compatible browser. If one is not already available, install the matching browser once:
npx playwright install chromium{
"mcpServers": {
"vuda": {
"command": "npx",
"args": ["-y", "visual-ui-debug-agent-mcp"]
}
}
}Restart the client after changing its MCP configuration. The server writes protocol messages to stdout and diagnostics to its temporary log file.
No provider account is required for local mode.
Docker users can use the same stdio transport:
{
"mcpServers": {
"vuda": {
"command": "docker",
"args": ["run", "--interactive", "--rm", "ghcr.io/samihalawa/visual-ui-debug-agent-mcp:latest"]
}
}
}To use provider credentials from a file with Docker, add "--env-file", "/absolute/path/to/.env" immediately after "run" in the args array.
Ask your client to:
Use VUDA to inspect https://example.com, capture a screenshot, list the
interactive elements, and report console errors and obvious layout issues.Tool | Purpose |
| Screenshot, console, performance, and interactive-element analysis |
| Capture a URL, viewport, full page, or selected element |
| Capture multiple URLs for side-by-side review |
| Render and capture local HTML files |
| Return element properties, children, and computed styles |
| Compare two rendered pages or elements |
Tool | Purpose |
| Execute and verify a described user journey |
| Validate a sequence of browser actions |
| Capture browser console messages over a time window |
| Collect navigation and page performance metrics |
| Exercise multiple HTTP endpoints |
| Discover and inspect pages from a sitemap |
| Store or retrieve a remote tunnel URL and setup guidance |
| Keep small debugging notes during one server session |
playwright_navigate, playwright_click, playwright_iframe_click, playwright_fill, playwright_select, playwright_hover, playwright_evaluate, playwright_console_logs, playwright_get_visible_text, playwright_get_visible_html, playwright_go_back, playwright_go_forward, playwright_press_key, playwright_drag, and playwright_screenshot.
VUDA reads environment variables normally and automatically loads .env from its working directory. Copy .env.example when running from a source checkout. For an npx installation, either put .env in the MCP process working directory, pass variables in the client configuration, or set DOTENV_CONFIG_PATH to an absolute .env path.
Mode | Required configuration | Account state |
Local (default) |
|
|
Browserbase |
| Reuse |
Anchor Browser |
| Use an Anchor profile in |
Existing browser |
| Uses that browser context; cookie injection is optional |
Browserbase example:
VUDA_BROWSER_PROVIDER=browserbase
BROWSERBASE_API_KEY=your_api_key
BROWSERBASE_PROJECT_ID=your_project_id
BROWSERBASE_CONTEXT_ID=your_saved_context_idAnchor Browser example with a persistent authenticated profile:
VUDA_BROWSER_PROVIDER=anchor
ANCHOR_API_KEY=your_api_key
VUDA_ANCHOR_SESSION_JSON={"browser":{"profile":{"name":"vuda","persist":true}}}All 29 tools keep their existing names and inputs in every mode. Read the MCP resource browser://status to confirm the selected provider, current connection state, session ID, and whether a live view is available. CDP and live-view URLs are never returned.
Cookie injection works with every provider. Supply a Playwright cookie array inline or by file:
VUDA_COOKIES_FILE=/absolute/path/to/cookies.json
# VUDA_COOKIES_JSON=[{"name":"session","value":"...","domain":"example.com","path":"/"}]For local mode, VUDA_STORAGE_STATE_PATH loads a Playwright storage-state file. Set VUDA_PERSIST_STORAGE_STATE=true to write the updated state back when VUDA exits cleanly. Browserbase Contexts and Anchor profiles are the provider-native choices for state that must survive multiple cloud sessions.
Provider-specific session options remain available without another wrapper or SDK:
VUDA_BROWSERBASE_SESSION_JSON is merged into Browserbase's create-session request.
VUDA_ANCHOR_SESSION_JSON is sent as Anchor's create-session request.
All timeout settings are optional:
Variable | Default | Purpose |
|
| General Playwright timeout in milliseconds |
|
| Navigation timeout |
|
| Selector wait timeout |
|
| Delay after navigation before capture |
|
| Delay for short UI updates |
|
| Slow-page threshold |
|
| Delay between direct interactions |
Example:
{
"mcpServers": {
"vuda": {
"command": "npx",
"args": ["-y", "visual-ui-debug-agent-mcp"],
"env": {
"VUDA_NAVIGATION_TIMEOUT": "30000",
"VUDA_STABILITY_WAIT": "2000"
}
}
}
}git clone https://github.com/samihalawa/visual-ui-debug-agent-mcp.git
cd visual-ui-debug-agent-mcp
npm ci
npm testnpm test builds the TypeScript server, starts it through the MCP stdio transport, verifies the exact 29-tool inventory, reads a bundled resource, exercises a stateful tool call, and captures a real browser screenshot.
It also validates Browserbase and Anchor session request/cleanup shapes, CDP selection, cookie loading, and the crawler's browser initialization. Provider calls use deterministic mocks in CI; use your own .env for a live cloud session.
Before opening a pull request, also run:
npm audit
npm pack --dry-runVUDA keeps one Playwright control plane across all providers. Local mode creates isolated contexts for page-level analyses; remote modes reuse the provider context so authenticated state survives across tools. VUDA returns screenshots as MCP image content and exposes generated screenshots, browser status, and debugging prompts as MCP resources.
Issues and focused pull requests are welcome. See CONTRIBUTING.md for the development workflow and review checklist. Release history is recorded in CHANGELOG.md.
ISC © 2023–2026 Sami Halawa and contributors.
Test multiple API endpoints and verify responses
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Base URL of the API (e.g., http://localhost:5000/api) | |
| endpoints | Yes | List of endpoints to test | |
| authToken | No | Optional auth token to include in all requests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. However, it only describes testing and verification without explaining what 'verify' entails, how responses are handled, error behavior, auth requirements, or rate limits. This vagueness leaves critical behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with no extraneous information. However, it is somewhat under-specified; while concise, it could be slightly more structured without losing efficiency. Nonetheless, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is insufficient. It omits return value format, error handling, verification criteria, and practical usage context. The description is too sparse to fully equip an agent for 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 coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides. It remains generic about testing endpoints without elaborating on parameter usage or constraints.
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 'Test multiple API endpoints and verify responses' clearly states the tool's purpose with a specific verb ('Test') and resource ('API endpoints'). It implies functionality to test multiple endpoints and verify responses, which differentiates it from sibling tools that are browser-centric.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites, limitations, or scenarios where this tool is preferred. This is a significant gap given the absence of explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take screenshots of multiple URLs and display them in a grid
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Array of URLs to capture screenshots of | |
| paths | No | Optional array of paths to label the screenshots with | |
| fullPage | No | Whether to capture full page or just viewport. Default: false | |
| waitTime | No | Time to wait in milliseconds before taking each screenshot. Default: 5000 (configurable via VUDA_STABILITY_WAIT) | |
| gridSize | No | Size of grid (2 for 2x2, 4 for 4x4). Default: 2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose important behaviors: error handling for failed URLs, concurrency, JavaScript requirements, or rate limits. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 5 parameters and no output schema, the description does not explain return format, error handling, or prerequisites. It lacks completeness for a tool of this complexity, especially given no annotations to supplement.
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 all parameters. The description adds no additional meaning to parameters; it does not explain how parameters like 'gridSize' or 'waitTime' affect behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('take screenshots'), the resource ('multiple URLs'), and the output format ('display them in a grid'). It distinguishes from sibling tools like 'screenshot_url' (single URL) and 'screenshot_local_files' (local files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (multiple URLs in a grid) but lacks explicit guidance on when not to use or alternatives. No mention of 'screenshot_url' for single URLs or 'visual_comparison' for comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor console logs on a page
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to monitor console logs from | |
| filterTypes | No | Types of console messages to capture | |
| duration | No | How long to monitor in milliseconds. Default: 5000 (configurable via VUDA_STABILITY_WAIT) | |
| interactionSelector | No | Optional element to click before monitoring |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects (e.g., clicks via interactionSelector), return values, or permissions. The behavior after monitoring duration ends is unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. However, it could be slightly more informative without significant bloat. Still, efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is defined, and the description does not explain what the tool returns (e.g., list of log entries). The optional interactionSelector implies a behavioral effect, but details are missing. Incomplete for practical 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 clear descriptions for each parameter. The tool description adds no additional meaning beyond what the schema already provides, meeting the baseline.
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 'Monitor console logs on a page' clearly states the verb 'monitor' and resource 'console logs'. However, it does not differentiate from sibling tool 'playwright_console_logs', which likely performs a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling list includes 'playwright_console_logs' which may overlap, but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save and retrieve debugging context including .env variables, selectors, and issues
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Memory action to perform | |
| key | No | Memory key for save/retrieve operations | |
| value | No | Value to save (for save action) | |
| category | No | Category of memory item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It omits details about the effects of actions like 'clear' (destructive?) and whether 'save' overwrites existing keys. Persistence and side effects are not mentioned, leaving significant transparency 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 single sentence is front-loaded, concise, and contains no extraneous words. It efficiently communicates the core purpose and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, 2 enums, multiple actions, and no output schema, the description is too brief. It fails to explain return values for retrieve/list, the role of key/category, or the effect of each action. Critical context for a multi-action memory tool is missing.
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 baseline is 3. The description adds value by listing example categories (env variables, selectors, issues) that map to the category enum, but does not explain parameter relationships (e.g., key required for save/retrieve but not list/clear). This provides marginal improvement over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves and retrieves debugging context, with explicit examples like .env variables, selectors, and issues. It distinguishes from sibling tools which are focused on testing, navigation, and screenshots, making the purpose 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?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The sibling list includes no other memory tools, so it is unique, but the description does not help with situational decisions (e.g., when to use save vs list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect DOM elements and their properties
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to inspect | |
| selector | Yes | CSS selector to inspect | |
| includeChildren | No | Whether to include children elements. Default: false | |
| includeStyles | No | Whether to include computed styles. Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Inspect DOM elements and their properties', failing to disclose whether the tool is read-only, any side effects, or limitations. This is insufficient for safe agent use.
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 (6 words), but this brevity sacrifices necessary detail. While not verbose, it earns a 3 because it is too limited to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is notably incomplete. It does not explain the return format, behavior when the element is not found, or any error conditions, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; all four parameters have descriptions in the schema. The tool description adds no additional meaning beyond what the schema already provides, so 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 uses a specific verb 'Inspect' and resource 'DOM elements and their properties', clearly matching the tool name. However, it does not distinguish itself from sibling tools like playwright_get_visible_html or playwright_evaluate, which also inspect DOM elements.
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. Among sibling tools, there are many inspection-related tools, but no context is given for preferring dom_inspector.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a page with screenshots, console logs, interactive element mapping, and performance metrics
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyze (e.g., http://localhost:4999, https://example.com) | |
| includeConsole | No | Whether to include console logs. Default: true | |
| mapElements | No | Whether to map interactive elements. Default: true | |
| fullPage | No | Whether to capture full page or just viewport. Default: false | |
| waitForSelector | No | Optional CSS selector to wait for before analysis | |
| device | No | Optional device to emulate (e.g., "iPhone 13", "Pixel 5") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states what the tool does but not how (e.g., destructive potential, speed, permission requirements). The lack of detail leaves the agent uninformed about side effects or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the tool's capabilities. However, it could be more structured (e.g., bullet points) to improve readability. No waste, but also no front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description is too brief. It does not describe the return format or how results are delivered. For a tool that produces multiple outputs (screenshots, logs, metrics), this omission is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds no extra meaning beyond the schema. Baseline of 3 is appropriate since the description does not clarify parameter interactions or optimization hints.
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 lists actions (screenshots, console logs, mapping, performance metrics) but does not clarify what makes this tool 'enhanced' compared to using individual sibling tools like playwright_screenshot, console_monitor, or performance_analysis. The purpose is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention that it combines multiple analyses or any prerequisites. Implicitly a general analysis tool but no clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze page performance metrics
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyze performance for | |
| iterations | No | Number of test iterations to run. Default: 1 | |
| waitForNetworkIdle | No | Whether to wait for network to be idle. Default: true | |
| device | No | Optional device to emulate (e.g., "iPhone 13", "Pixel 5") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it opens a browser, runs tests, or has side effects. The schema coverage is 100%, but behavioral transparency beyond input schema is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but lacks structure and front-loads minimal information. It could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, how iterations affect analysis, or what happens with the device parameter.
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 baseline is 3. The description adds no additional semantic context for parameters beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze page performance metrics' clearly states the verb (analyze) and resource (page performance metrics). It distinguishes from sibling tools which are more specific (e.g., playwright_navigate, screenshot_url). However, it lacks specificity on what metrics are analyzed.
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 guidelines on when to use this tool vs alternatives. The description provides no context about prerequisites, when not to use, or comparisons with related tools like enhanced_page_analyzer.
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, the description must disclose behavioral traits but only states the action. It does not mention whether the tool waits for the element, scrolls into view, or what happens on errors (e.g., timeout, element not found). This leaves critical behavioral details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified and lacks detail. Conciseness is not achieved at the expense of informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only one parameter, the description is incomplete. It does not explain return value, side effects, or behavior in edge cases, which is important for a simple action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with a single required parameter 'selector' well-described in the schema. The description adds no additional meaning beyond the schema, meeting the baseline expectation for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Click an element on the page' clearly states the action and resource, but it is essentially a restatement of the tool name 'playwright_click' and does not differentiate from sibling tools like playwright_hover or playwright_fill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as requiring the page to be loaded or the element to be visible, which could be inferred but is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve console logs captured so far
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | Whether to clear logs after retrieval | |
| limit | No | Maximum number of logs to return | |
| type | No | Type of logs to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only discloses that logs are retrieved, but does not explain side effects, whether logs are cleared by default, or what happens when no logs exist. With no annotations provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence without extraneous words. It is front-loaded and efficiently communicates 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?
Given the presence of 3 optional parameters, no output schema, and no annotations, the description lacks completeness. It does not explain the log format, return behavior, or how this tool relates to siblings like 'console_monitor'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters are described in the input schema. The description adds no additional meaning beyond what the schema provides, so a 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 uses a specific verb 'retrieve' and identifies the resource 'console logs' with scope 'captured so far', clearly stating the tool's function. However, it does not explicitly distinguish it from sibling tools like 'console_monitor', which may have overlapping purpose.
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, nor are there any exclusions or prerequisites mentioned. The description simply states what the tool does without context for appropriate usage.
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 present, the description carries the full burden of disclosing behavioral traits. It only says 'Drag an element to a target location' without mentioning how the drag is performed (e.g., mouse events, scrolling, waiting), potential side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and efficient for a simple tool, though additional context would be beneficial.
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 (2 parameters, no output schema, no annotations), the description is minimal. It does not explain the return value (likely void), any prerequisites (e.g., element visibility), or behaviors like scrolling or waiting, leaving gaps 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?
Both parameters have descriptions in the schema (coverage 100%), so the schema already defines them. The description adds no extra meaning beyond that. Baseline 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 the target ('element to a target location'). It distinguishes from sibling tools like playwright_click and playwright_hover, though it could specify that it simulates drag-and-drop 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_hover. There are no prerequisites, exclusions, or contextual hints about appropriate use cases.
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 context
| 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, the description should disclose behavioral traits like return values, error handling, or destructive potential. It merely states execution context without any such details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, but could be slightly expanded to include key behavior without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is minimally adequate but lacks information on return values, side effects, or prerequisites, making it incomplete for optimal 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 coverage is 100% with clear parameter description ('JavaScript code to execute'), so the description adds no extra meaning beyond the schema, earning a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Execute'), resource ('JavaScript'), and context ('browser console'), clearly distinguishing this tool from siblings like console_monitor or dom_inspector.
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 (e.g., using the console directly or other Playwright tools), nor any warnings about potential side effects.
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?
No annotations provided, and the description fails to disclose behavioral details such as whether the tool clears existing text, waits for element, or handles non-text inputs. This is a significant gap for a browser automation 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, concise sentence with no wasted words. It could be slightly more informative without losing conciseness, but it is appropriately sized for a simple tool.
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?
Without an output schema, the description should explain return behavior (e.g., success indicator, errors). It also lacks context about edge cases (e.g., field hidden, non-input selectors). The combination of missing annotations and sparse description leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (selector and value) with descriptions, achieving 100% coverage. The description adds no additional semantic beyond the schema, resulting in 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 tool fills an input field, distinguishing it from sibling tools like playwright_click or playwright_hover. However, 'fill out' is slightly vague and could be more specific (e.g., 'set value of text input').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool. No mention of prerequisites (e.g., field must be visible, enabled) or alternatives. The description provides no usage context.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not clarify what 'visible' means (e.g., excludes hidden elements), nor does it mention performance impact, return format, or whether it blocks on page load.
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, front-loaded sentence that efficiently conveys the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description is minimally complete. However, it lacks details about the return value (e.g., string of HTML, what 'visible' excludes) and any edge cases, which would help the agent 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?
There are no parameters, so the input schema is empty. The description adds minimal meaning beyond that, simply stating the action. Per rubric, with 100% schema coverage and 0 parameters, a baseline 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 verb 'Get', the resource 'HTML content', and the scope 'current page'. It effectively distinguishes from sibling tools like playwright_get_visible_text which retrieves text content.
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 usage guidelines are provided. There is no guidance on when to use this tool versus alternatives like playwright_get_visible_text or dom_inspector. The agent is left to infer context from the name alone.
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?
No annotations exist, and the description is minimal. It does not disclose behavioral traits such as whether it returns plain text stripped of formatting, scripts, or images, nor any limitations or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous information, front-loading 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 parameterless tool, the description is minimally complete. However, it lacks information on return format, potential errors, or behavior on empty pages, which would be helpful given the context of many 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?
With no parameters and 100% schema coverage, the description adds no additional meaning beyond the schema. 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 tool gets the visible text content of the current page, using specific verb and resource. It naturally distinguishes from sibling tools like playwright_get_visible_html which returns HTML.
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 usage guidelines provided. The description does not indicate when to use this tool versus alternatives (e.g., playwright_get_visible_html or page analysis tools).
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?
No annotations are provided, so the description must carry the full burden. It only states the basic action without disclosing preconditions (e.g., requires history), error behavior, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only four words, no waste. However, it could be slightly more structured by including a note about precondition, but for a simple tool it is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema. The description adequately conveys the primary action but lacks context about prerequisites or limitations, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The baseline of 4 is appropriate since the description does not need to add parameter semantics for a parameterless tool.
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 ('navigate back') and the resource ('browser history'). It is unambiguous and distinguishes itself from sibling tools like 'playwright_go_forward' and 'playwright_navigate'.
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 does not mention that it only works if there is a previous page, nor does it compare to 'playwright_go_forward' or 'playwright_navigate'.
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 provided, so the description carries full burden. It only restates the tool's name and lacks disclosure about edge cases (e.g., behavior when at the latest page or if history is empty).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is highly concise and front-loaded with the core action. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with no parameters or output schema, the description captures the essential purpose. However, it lacks details about edge cases (e.g., if no forward history exists), slightly reducing completeness.
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?
No parameters are defined, and schema coverage is 100%. The description adds no parameter information, but that is acceptable given zero parameters; baseline 4 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 verb 'navigate' and the resource 'forward in browser history', making the tool's purpose immediately understandable. It distinguishes itself from siblings like 'playwright_go_back'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., navigating via URL or clicking a link). Usage is implied as a standard browser history forward action, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over 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, the description bears full burden. It doesn't disclose whether the tool waits for the element, triggers events, or modifies page 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?
Extremely concise at one sentence. Could be expanded slightly without losing conciseness, but as-is it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required param, the description is partially complete but lacks context on element existence, waiting behavior, or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds no additional meaning beyond what the schema's 'description' field provides, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Hover' and resource 'element on the page', clearly distinguishing it from sibling tools like click or drag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., for triggering hover effects). Lacks context like prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element 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 within the iframe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks details on behavior such as waiting, error handling, or whether it works only with same-origin iframes. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action, containing no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-param tool with no output schema, the description is minimally adequate but lacks completeness on error states and specific behaviors, which would help for a web automation 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 coverage is 100% with adequate descriptions for both parameters. The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline 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 'Click an element in an iframe on the page' uses a specific verb and resource, clearly distinguishing it from sibling tools like playwright_click which target elements outside iframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for iframe elements but does not explicitly state when to use this tool versus alternatives like playwright_click, nor does it mention prerequisites or conditions.
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 (optionally focusing an element first)
| 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 the full burden. It does not disclose behavioral details such as whether the key is single-press, if modifiers are supported, or error handling. The description is too terse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that directly describes the action. No wasted words, perfectly sized for the tool's simplicity.
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 simplicity of the tool (two params, no output schema), the description is adequate but lacks detail on return values or special cases. It minimally covers the 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 baseline is 3. The description adds context about optional focusing, but does not provide additional parameter semantics beyond what the schema already offers.
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 'Press a keyboard key' with a specific verb and resource. It also mentions optional focusing, but does not explicitly differentiate from sibling tools like playwright_click or playwright_fill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage with 'optionally focusing an element first' but provides no explicit guidance on when to use this tool vs alternatives or when not to use it.
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 resource (will be used in the URI) | |
| selector | No | Optional CSS selector for element to screenshot | |
| fullPage | No | Store screenshot of the entire page (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as side effects, failure modes (e.g., no page loaded), or how the screenshot is stored.
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?
One sentence of 12 words, concise and front-loaded, but could be slightly more informative without adding length.
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 simplicity of the tool and 3 well-described parameters, the description is adequate but lacks details on return value or how it differs from 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?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the 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 action (take a screenshot) and the resource (current page or specific element), distinguishing it from URL-based screenshot tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like screenshot_url or batch_screenshot_urls, nor prerequisite that a browser must be navigated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option in a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the select element | |
| value | Yes | Value or label of the option to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose behaviors like change event triggering, acceptance of value vs label, or error conditions for non-select 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 with no wasted words. It is appropriately sized but could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with complete schema coverage and no output schema, the description is minimally adequate. It lacks contextual details like element type or event behavior, but is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the parameters. The description adds no additional meaning beyond what is in the schema, yielding 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 'Select an option in a dropdown' clearly states the action (select), resource (option in a dropdown), and distinguishes from sibling tools like playwright_click and playwright_fill. It is 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?
No guidance is provided on when to use this tool versus alternatives, no conditions, prerequisites, or exclusions. The agent must infer context from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take screenshots of local HTML files in a directory
| Name | Required | Description | Default |
|---|---|---|---|
| directory | No | Directory containing HTML files to screenshot (defaults to current directory) | |
| pattern | No | Glob pattern to match HTML files (default: "*.html") | |
| fullPage | No | Whether to capture full page or just viewport. Default: false | |
| gridSize | No | Size of grid (2 for 2x2, 4 for 4x4). Default: 2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full disclosure burden. It states the tool takes screenshots but omits any behavioral details such as whether a browser is launched, if files are modified, or what happens with defaults. Side effects are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. No redundancy. While slightly minimal, it is efficient for a simple task.
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 four parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain how the directory is used, the meaning of gridSize, or what pattern does. The schema descriptions partially compensate but the overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides. No parameter details are mentioned in the description.
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 takes screenshots of local HTML files within a directory, using specific verbs and resource. It distinguishes from sibling tools like batch_screenshot_urls and playwright_screenshot which target URLs or current pages.
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 does not mention preconditions, exclusions, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of a URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to capture a screenshot of | |
| fullPage | No | Whether to capture full page or just viewport. Default: false | |
| selector | No | Optional CSS selector to screenshot only that element | |
| waitForSelector | No | Optional CSS selector to wait for before taking screenshot | |
| device | No | Optional device to emulate (e.g., "iPhone 13", "Pixel 5") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as output format (e.g., returns image data or file path), prerequisites, or side effects. The tool's behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is too terse and lacks structure such as separating purpose from usage details. While not wasteful, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain return values, error conditions, or prerequisites, leaving the agent without critical 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 coverage is 100%, so the schema already documents parameters. The description adds no additional semantics beyond what the schema provides, meeting the baseline but not exceeding it.
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 states the verb 'Take a screenshot' and resource 'URL', but it does not distinguish this tool from sibling tools like 'playwright_screenshot' or 'batch_screenshot_urls', making it vague in the context of similar 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?
No guidance is provided on when to use this tool versus alternatives. With many screenshot-related siblings, the agent lacks decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl a website recursively to generate a comprehensive sitemap with all endpoints, links, and visible text content. Perfect for detecting inconsistent content, broken links, and navigation issues.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting URL to crawl (e.g., http://localhost:3000, https://example.com) | |
| maxDepth | No | Maximum depth to crawl (default: 3) | |
| includeText | No | Include visible text content from each page (default: true) | |
| sameDomainOnly | No | Only crawl links from the same domain (default: true) | |
| outputFormat | No | Output format for the sitemap (default: markdown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose potential resource consumption, rate limits, or permissions needed for recursive crawling. The description only states the action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states verb and output, second sentence gives use cases. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so description should explain the returned sitemap format. It only mentions 'comprehensive sitemap' without details on structure or content. Crawl constraints (e.g., depth, domain limits) are also not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds minor context (e.g., 'visible text content' aligns with includeText) but does not explain parameter behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it crawls a website to generate a sitemap with endpoints, links, and text. It distinguishes from siblings by focusing on sitemap generation, though it shares use cases with navigation_flow_validator.
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 mentions use cases ('Perfect for detecting...') but does not explicitly state when to use vs alternatives, nor when not to use. Usage is implied but not differentiated from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guide user to expose local ports via Cloudflare tunnel or manage tunnel URLs
| Name | Required | Description | Default |
|---|---|---|---|
| localPort | Yes | Local port number to expose (e.g., 3000, 8080) | |
| action | Yes | Action: guide (show instructions), store (save tunnel URL), retrieve (get saved URL) | |
| tunnelUrl | No | Tunnel URL to store (only for store action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, authentication needs, rate limits, or what the tool returns for each action (e.g., instructions text).
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 conveys the tool's purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, an enum, and no output schema, the description is adequate but does not explain return values or behavior for each action, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for every parameter, so baseline is 3. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool guides users to expose local ports via Cloudflare tunnel or manage tunnel URLs, using specific verbs ('guide', 'manage') and resources, and is distinct from sibling tools which are mostly browser automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tunneling and tunnel URL management, but provides no explicit guidance on when to use it versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute and validate a sequence of UI interactions simulating a user workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| startUrl | Yes | Initial URL for the workflow | |
| taskDescription | Yes | High-level description of the user task being simulated | |
| steps | Yes | Sequence of steps representing the user workflow (minimum 1 step) | |
| captureScreenshots | No | When to capture screenshots (default: failure) | |
| device | No | Optional device to emulate (e.g., 'iPhone 13', 'Pixel 5') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose key behavioral traits like browser lifecycle, error handling, or destructive actions. Only states the high-level 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?
Single sentence with no extraneous words. Front-loaded purpose. Efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having many parameters and no output schema, the description provides no context about return values, validation outcomes, or how errors are reported. Incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter meaning; it merely restates the concept of simulating a user workflow. Adequate but not improved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool executes and validates a sequence of UI interactions. It distinguishes from siblings like 'playwright_navigate' and 'navigation_flow_validator' by focusing on general workflow validation, but could explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. No exclusions or alternatives mentioned. The user is left to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two URLs visually and highlight differences
| Name | Required | Description | Default |
|---|---|---|---|
| url1 | Yes | First URL to compare | |
| url2 | Yes | Second URL to compare | |
| threshold | No | Difference threshold (0.0-1.0). Default: 0.1 | |
| fullPage | No | Whether to capture full page. Default: false | |
| selector | No | Optional CSS selector to limit comparison |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits but only gives a high-level purpose. Does not mention if it opens browsers, network dependencies, output format, or destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste. Could be slightly more informative without losing conciseness, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 5 parameters and no output schema, description provides only 8 words. Lacks details on return value, side effects, or behavioral constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'compare' and resource 'two URLs' with clear outcome 'highlight differences'. It distinguishes from sibling tools like screenshot_url which capture single pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like ui_workflow_validator or navigation_flow_validator. Does not mention prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.2api_endpoint_testerbatch_screenshot_urlsconsole_monitordebug_memorydom_inspectorenhanced_page_analyzernavigation_flow_validatorperformance_analysisplaywright_clickplaywright_console_logsplaywright_dragplaywright_evaluateplaywright_fillplaywright_get_visible_htmlplaywright_get_visible_textplaywright_go_backplaywright_go_forwardplaywright_hoverplaywright_iframe_clickplaywright_navigateplaywright_press_keyplaywright_screenshotplaywright_selectscreenshot_local_filesscreenshot_urlsitemap_crawlertunnel_helperui_workflow_validatorvisual_comparisonMany tools overlap in functionality, such as multiple screenshot tools (batch_screenshot_urls, playwright_screenshot, screenshot_local_files, screenshot_url) and analysis tools (enhanced_page_analyzer, performance_analysis, visual_comparison, dom_inspector). The distinction between low-level Playwright commands and high-level compound tools is unclear, causing potential misselection.
Naming conventions vary: some tools use snake_case (api_endpoint_tester), others use 'playwright_' prefix for low-level actions, and some are standalone (visual_comparison, sitemap_crawler). This inconsistency makes it hard to predict tool names.
With 29 tools, the set is overly large for a UI debugging agent. Many tools are redundant or could be merged, such as the various screenshot and analysis tools. A more streamlined set would be more manageable.
The tool set covers basic browser automation, screenshot, DOM inspection, performance, and workflow validation. However, there are gaps like network monitoring, accessibility checks, and event listeners. Some tools (debug_memory) seem peripheral, reducing overall coverage for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Screenshot, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Live browser debugging for AI assistants — DOM, console, network via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/samihalawa/visual-ui-debug-agent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
