Playwright MCP

Server Quality Checklist

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

Latest release: v0.0.79
Disambiguation5/5
Each tool has a clearly distinct purpose, covering actions like navigation, clicking, typing, screenshots, network requests, file upload, and dialog handling. Even similar tools like browser_snapshot and browser_take_screenshot are differentiated by their intended use (actions vs. visual capture).
Naming Consistency4/5
All tools share the 'browser_' prefix, and most follow a verb_noun or verb pattern (e.g., browser_click, browser_fill_form). However, a few are noun-based (e.g., browser_network_requests, browser_tabs) which breaks the verb-first convention slightly, but the overall pattern remains predictable.
Tool Count4/5
With 24 tools, the set is extensive but well-scoped for a full browser automation server. Each tool addresses a specific operation, and the count is appropriate for the domain, though it borders on the heavier side.
Completeness4/5
The toolset covers core browser automation workflows: navigation, clicks, forms, network, screenshots, accessibility, dialogs, file upload, and tabs. Minor gaps exist (e.g., no direct tool for scrolling or getting current URL), but these do not significantly hinder common agent tasks.
Average 3.4/5 across 24 of 24 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds no behavioral details. It does not explain the side effects of accepting vs. dismissing, the role of promptText, or how the tool interacts with the browser state. Annotations carry the burden, but the description contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words, which is under-specified rather than concise. It lacks front-loaded structure and does not earn its place because it adds no value beyond the tool name. A useful description would at minimum clarify the dialog type and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no param enums), the description is far from complete. It omits return value, behavioral nuances, and usage context. Even a simple tool requires explaining what 'handle' means. The description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters clearly. The description adds no additional semantic context (e.g., when promptText is needed, what 'accept' does). Baseline 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' is essentially a tautology of the tool name and annotation title. It does not specify the type of dialog (alert, confirm, prompt) or what 'handling' entails (accepting, dismissing), making it vague and indistinguishable from a generic label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus any of the 23 sibling tools (e.g., browser_click, browser_type). It fails to mention prerequisites (e.g., a dialog must exist) or contexts where alternative tools 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no further behavioral context (e.g., that fields must match snapshot elements, that filling checkboxes uses true/false, or that the tool may fail if elements are stale). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only four words, the description is under-specified. While front-loaded, it does not earn its place—it fails to convey essential context about the nested parameters or behavior, sacrificing utility for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested array of field objects with multiple types) and no output schema, the description is inadequate. It does not explain how fields should be structured, what happens on error, or how it interacts with a page snapshot. Sibling tools with similar scope (e.g., browser_type) would benefit from more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all properties described), so the baseline is 3. The description adds no additional meaning beyond what the schema provides (e.g., no typical usage patterns or format examples).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' clearly states the tool's action (fill) and resource (form fields). It is specific enough to distinguish from sibling tools like browser_type (single field) or browser_select_option, though it could explicitly contrast with these for full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as browser_type or browser_select_option. It does not mention prerequisites (e.g., a snapshot required), nor does it explain 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond the fact that it performs a drag and drop. Annotations already indicate destructiveHint=true, so the agent knows it modifies state, but the description does not explain potential side effects (e.g., triggering events, layout changes) or how the tool interacts with the page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), which is good for front-loading, but it lacks important details about element selection and permissions. It earns its place, but more context could be included without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of drag-and-drop interactions and the presence of four parameters (including startElement/endElement for human-readable descriptions), the description fails to explain how to properly use these parameters or that the tool relies on page snapshot references. No output schema exists, but the description does not clarify return behavior or error conditions. The description is insufficient for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters already have descriptions in the schema. The tool description does not add any additional meaning or constraints to the parameters beyond what the schema provides. Baseline 3 is appropriate as the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a drag and drop between two elements, which is a specific verb-resource combination. Among siblings like browser_drop and browser_click, it distinguishes itself by explicitly naming the drag-and-drop action. However, it doesn't fully disambiguate from browser_drop, which might be related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_click, browser_hover, or browser_drop. There is no mention of prerequisites (e.g., needing a page snapshot) or conditions under which drag-and-drop is appropriate or should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, which the description aligns with. However, the description adds no new behavioral details beyond stating the action. It does not mention side effects like triggering layout recalculation, affecting screenshots, or the fact that the current browser tab's viewport changes. With annotations carrying the main transparency burden, the description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it very concise. However, it is so minimal that it borders on underspecification. There is room to add meaningful context (e.g., 'Changes the viewport width and height to the specified pixel values') without losing conciseness. It earns its place by not being verbose, but doesn't maximize the space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and a simple interface, the description should clarify the scope (current window/tab), the unit (pixels), and the impact on other tools (e.g., screenshots). It fails to mention that resize affects the active browser window only, or that dimensions are in CSS pixels. The absence of output schema means the description should explain that the tool returns nothing or confirms success. The description is incomplete given the tool's role in a sequence of browser interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – both width and height have inline descriptions. The tool description repeats no parameter info. Per guidelines, baseline is 3. The description does not add context like units (pixels), allowed ranges, or validation rules, which would be useful but not required given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'resize' and the resource 'browser window'. It is immediately understandable. However, it does not differentiate from sibling tools like browser_navigate or browser_snapshot, but the action is sufficiently distinct that no confusion arises. A more precise term like 'viewport' or 'dimensions' would improve specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when or why to use this tool over others. There is no mention of prerequisites (e.g., browser must be open), expected scenarios (e.g., responsive testing, adjusting before screenshot), or alternatives. The agent is left to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context. It fails to disclose that the filename parameter saves snapshot to file (side effect), nor does it explain what the snapshot contains or requires beyond the current page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it omits important details such as return format, side effects of filename, and how to use target or depth. Conciseness trades off against completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and many sibling tools, the description is incomplete. It doesn't explain what an accessibility snapshot looks like, what the target parameter references, or that filename persists output to a file. The agent lacks critical context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The tool description adds no additional meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures an accessibility snapshot, distinguishing it from visual screenshots. However, it doesn't specify what 'accessibility' entails (e.g., accessibility tree), which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description briefly claims this is 'better than screenshot' but offers no explicit guidance on when to use it versus alternatives like browser_evaluate or browser_run_code_unsafe. No when-not-to-use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true, so the description need not repeat those. However, it adds no extra behavioral context—such as the scope of execution, potential side effects on page state, or security implications—beyond stating 'on page or element'. The description simply restates the action without revealing operational boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It efficiently conveys the core action, though it sacrifices depth for brevity. Front-loaded with the action, but could be more informative in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 annotations that suggest destructiveness, the description is incomplete. It does not explain what happens when no target or element is provided, how the function parameter is structured beyond the inline comment, or what the return format is (text vs. file). A richer description is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full (100%) coverage with clear parameter descriptions. The tool description adds little beyond the schema, merely hinting at the function parameter format. Since schema coverage is high, a baseline of 3 is appropriate; the description does not enhance understanding of the target/element distinction or filename behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Evaluate' and the resource 'JavaScript expression on page or element', which distinguishes it from tools like browser_navigate or browser_click. However, it does not explicitly differentiate from the sibling tool browser_run_code_unsafe, which also executes JavaScript, limiting clarity in choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as browser_run_code_unsafe, browser_type, or browser_fill_form. There is no mention of prerequisites, limitations, or the recommended use cases, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true (file upload can overwrite or cause side effects), readOnlyHint=false, and openWorldHint=true (may affect external state). The description 'upload' adds minimal behavioral context beyond annotations—no mention of file type/size limits or what happens on cancellation. However, no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is front-loaded with the action and resource. No wasted words, though it could be slightly more specific (e.g., mention file input context).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that uploads files with no output schema and only one parameter, the description lacks context on expected file types, size limits, and typical usage (e.g., must be called after focusing a file input element). It is barebones and assumes agent knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'paths' property explains absolute paths and the omission cancels). The description adds no new parameter meaning beyond 'paths'—it just restates 'files'. The cancellation behavior is in the schema, not the description, so no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Upload one or multiple files' clearly states the verb ('upload') and resource ('files'), and the input schema confirms it handles files via paths. It distinguishes from sibling browser tools (e.g., browser_drop, browser_click) which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like browser_drop for file interactions. No mention of prerequisites (e.g., a file input element must be focused) or when to cancel (omit paths). The context is implied but lacks actionable direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, warning that navigation could change page state (e.g., unload current page, lose form data). The description does not elaborate on this—no mention of page load wait, cancelation, or side effects. Without annotations, this would be very opaque; with them, the description adds no value beyond the hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It efficiently communicates the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, no output schema) and sibling variety, the description is minimally complete for navigation but lacks context about page-load behavior, timeout, or error handling. For a destructive operation, more guidance (e.g., 'Waits for page to load') would improve completeness without overloading the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (url). The description doesn't add meaning beyond the schema's 'The URL to navigate to'. Since the schema is complete and simple, a baseline of 3 is appropriate; no extra semantic richness is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate to a URL' uses a clear verb ('Navigate') and resource ('URL'). It distinguishes this tool from siblings like browser_navigate_back and browser_tabs by implying forward navigation. However, it lacks specificity about URL types (e.g., http, file) or behavior (e.g., same tab vs new tab), keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_navigate_back or browser_click. It does not mention when not to use it, prerequisites (e.g., browser must be open), or order of operations. The agent receives no help in making this decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not contradict the 'destructiveHint: true' annotation, which implies clicking may cause navigation or state changes. However, it does not elaborate on what makes a click destructive (e.g., navigating away, opening dialogs, submitting forms). With annotations already covering 'readOnlyHint: false', the description adds minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At 5 words, the description is very concise. However, it could be front-loaded better with a brief usage hint (e.g., 'Click on the specified element to trigger navigation or interaction'). Every word is necessary but the sentence is underinformative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters including a required target, optional modifiers, doubleClick, button, and element), and the absence of an output schema, the description should explain return behavior (e.g., whether navigation is waited for, if errors like missing element are returned). With 100% schema coverage and destructiveHint annotation, the description is too sparse for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 5 parameters (100% coverage) with detailed descriptions for each. The tool description adds value by implying the workflow context (preceding 'browser_snapshot'), but the schema already explains 'target', 'button', 'modifiers', 'doubleClick', and 'element' well. The description could mention the relationship between 'target' and 'element' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'click' and the resource 'web page', and distinguishes itself from siblings like 'browser_hover', 'browser_type', 'browser_press_key', and 'browser_drop'. It could be more specific by mentioning that clicking triggers navigation or UI interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'browser_hover' (for hovering) or 'browser_fill_form' (for form submission). It does not mention prerequisites like needing a page snapshot or that clicks may fail if the element is not visible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint true and openWorldHint true, indicating state changes and external effects. However, the description does not add any behavioral context beyond this, such as triggering hover events, potential side effects, or requirements like element visibility. The description fails to supplement the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key action. It is concise with no wasted words. However, it is extremely terse and could benefit from slightly more context without losing brevity, thus not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of a hover action, the description is minimally adequate. It lacks information about return values (no output schema), prerequisites, and when hovering is appropriate. The absence of these details reduces completeness, though the annotations provide some safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both parameters have descriptions in the schema. The tool description does not add any meaning beyond what the schema already provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over element on page' clearly states the action (hover) and the target (element on page). It is distinct from sibling tools like browser_click, browser_find, and browser_type, making it easy for an agent to identify when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use hover over alternatives (e.g., to trigger tooltips, reveal dropdowns) or when not to use it. No prerequisites or context about the need for element visibility or interaction chains are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, indicating mutation. The description adds no further behavioral detail (e.g., event triggering, focus dependency, release behavior). It is consistent but does not go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource. It is efficient and avoids wordiness, but it could include a brief usage hint (e.g., 'such as ArrowLeft or a') without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, good annotations), the description is minimally adequate. However, it omits context like whether the key is pressed on the currently focused element or globally, and whether modifier keys (Ctrl, Shift) are supported as single key presses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's parameter description ('Name of the key to press or a character to generate, such as ArrowLeft or a') is already rich. The tool description adds no additional parameter information, so it does not improve on the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a key on the keyboard' clearly states the action (press) and the target (a key). It is specific enough to distinguish from mouse actions like browser_click or text entry like browser_type, though it could explicitly contrast with siblings (e.g., browser_type) for added clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_type (for typing strings) or browser_click (for clicking). There is no mention of prerequisites (e.g., focus requirement) or context (e.g., pressing Enter to submit forms). The agent must infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint:true and destructiveHint:false, so the agent knows it's a safe read operation. The description does not add behavioral detail beyond that, such as whether messages persist across navigations or if the tool returns messages from subframes. Since annotations already handle the safety profile, the description does not need to repeat that, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded and contains no superfluous words. It earns its place by being direct. However, it could benefit from additional context (e.g., about filtering or persistence) without becoming overly verbose, so it's not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (one required), 100% schema coverage, and no output schema, the description is minimally adequate. It tells the agent what the tool does, but does not explain nuances like the 'all' parameter (return all messages since session start vs. since last navigation) or the 'filename' parameter (write to file vs. return as text). These are covered in the schema, so the description doesn't need to repeat them, but it could offer a brief usage context. It's sufficient for a straightforward read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the parameters are well-documented in the schema itself. The description merely says 'Returns all console messages,' which does not add additional meaning beyond what the schema provides. However, because schema coverage is high, the baseline is 3, and the description adds no further semantics. Given the schema carries the burden, a 4 reflects that the description doesn't detract but doesn't enhance either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns all console messages' uses a specific verb ('Returns') and identifies the resource ('console messages'). It clearly states what the tool does, although it lacks differentiation from sibling tools like 'browser_network_requests' or 'browser_network_request' which also retrieve data. The purpose is effectively communicated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that console messages are browser-specific, or suggest when to use filtering parameters like 'level' or 'filename'. In a browser context, it might be useful to contrast with 'browser_network_requests' for debugging, but nothing is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false. The description lists both read-only (list, select) and destructive (create, close) actions, which is consistent but adds little beyond the annotations. It does not disclose important behavioral details such as that closing a tab may lose state, that creating a tab opens a default page, or that selecting a tab focuses it. The description carries minimal additional transparency given the annotation cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently enumerates the tool's capabilities. It is front-loaded with the operative verbs. While concise, it could be slightly improved by providing a brief example or clarifying purpose in a natural way. Still, it earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters including an enum and no output schema, the description is insufficiently complete. It does not explain what 'list' returns (e.g., an array of tab objects), what 'select' does (focus the tab), or what happens when closing without index. These are essential for an agent to invoke the tool correctly. The schema partially compensates, but the description should fill gaps that the schema does not cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage: action with enum descriptions, url for 'new', index for 'close/select' with a note on default close behavior. The tool description merely repeats the action list without adding any new meaning or clarifying parameter semantics (e.g., format of url, bounds of index). Since the schema does the heavy lifting, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists the four operations (list, create, close, select) on the specific resource 'browser tab'. This clearly distinguishes it from all sibling tools, which cover other browser actions like navigation, clicking, and form filling. 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for managing tabs—listing, creating, closing, or selecting them—but it does not explicitly state when to prefer this over other tools. For example, it doesn't mention that closing a tab differs from closing the entire browser (browser_close) or that selecting a tab is not the same as navigating. There is no when-not-to-use guidance or comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true, so the description needs only minor behavioral context. It adds nothing beyond the brief action description, missing details like page state changes or permission requirements. With annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is efficient and to the point. It could include a tiny bit more context without losing conciseness, but currently it's not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description is minimally adequate. However, it lacks guidance on behavior when values don't match options, multi-select handling, or any edge cases, leaving the agent to rely solely on parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond what the schema provides for individual parameters. It mentions 'dropdown' in the tool description but not per parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Select an option') and the resource ('in a dropdown'), using a specific verb and resource. This distinguishes it from sibling browser tools like browser_click or browser_fill_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., browser_type for input fields, browser_click for links). No mention of prerequisites like having a page snapshot. The description lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent knows it is destructive. The description adds that it closes the page, but does not elaborate on side effects (e.g., unsaved changes, dialog triggers). It adds minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loading the core action. Every word is necessary and informationally dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimally complete. However, it lacks precision about closing the current page vs. the entire browser, and does not mention potential unsaved state or dialog handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 3. The description does not add any parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the page' clearly states the verb (close) and resource (page), distinguishing it from all sibling browser tools that perform other actions like navigation, clicking, or file upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as browser_navigate_back or browser_tabs to switch. There is no mention of prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide `destructiveHint: true` indicating mutation. The description adds value by naming the resource type ('editable element') and, via schema, mentions 'slowly' for triggering key handlers, but does not broaden behavioral disclosure beyond what is in the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's core purpose. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, but annotations set a clear safety profile. The description, combined with exhaustive schema, covers basic usage. However, it does not explain how the element parameter differs from target or what happens when an element is non-editable, leaving moderate gaps for a parameter-rich tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds meaning by narrowing the context to 'editable element' (helpful for target/element), but doesn't explain parameter interplay (e.g., effect of slowly + submit or target vs element disambiguation). Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Type text into editable element' uses a specific verb ('Type') and resource ('editable element'), directly stating the tool's action. It's clear on its own and distinguishes well from siblings like browser_press_key (which presses a single key) and browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description itself provides no guidance on when to use this vs. alternatives like browser_press_key or browser_find. The sibling names and schema give some context, but the description does not explicitly state when typing versus pressing a key or filling a form is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructiveHint: true and readOnlyHint: false, indicating state-changing behavior. The description confirms it navigates back, but adds no further details about potential side effects (e.g., losing form input, triggering page reloads, or breaking out of iframes). For a simple action, the description is adequate but does not enrich the behavioral picture beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that conveys the tool's action without any fluff. Every word earns its place. The length is perfectly matched to the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and a straightforward action, the description is mostly complete. It tells the agent what happens without leaving critical gaps. A small deduction because it omits any mention of the return value (likely none) and does not clarify edge cases like attempting to go back when there is no history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description does not need to elaborate on parameters. The baseline score of 4 fits because there is no missing parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource structure: 'Go back to the previous page in the history'. It effectively distinguishes this tool from sibling tools like browser_navigate (which goes to a specific URL) and browser_click (which interacts with elements). The purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it's implicitly the correct choice for returning to the previous page, there is no mention of prerequisites (e.g., must have browsed forward first), exclusions, or comparisons with siblings like browser_tabs or browser_navigate. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe, non-mutating behavior. The description adds the three specific waiting modes (text presence, absence, timeout) which are not captured by annotations alone. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core functionality. It is concise but could be slightly more structured (e.g., listing the three options explicitly). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters and no output schema. The description covers the three waiting modes adequately. However, it does not explain what happens when no parameters are provided (e.g., likely no wait), or what the return value indicates (e.g., did the condition succeed?). Slightly incomplete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The description groups the three parameters into 'text to appear or disappear or a specified time to pass', linking them to the three modes. This adds value beyond the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for text to appear, disappear, or a specified time to pass. The verb 'wait for' and the resource/conditions are explicit, distinguishing it from other browser tools like click or navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., browser_snapshot for checking content, or explicit sleep). There are no when-to-use or when-not-to-use instructions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and readOnlyHint: false, indicating mutation. The description adds that the drop simulates a drag-from-outside interaction, which is useful. However, it does not disclose effects on page state, potential side effects like triggering uploads or navigation, or permission implications. Since the destructive hint is present, the bar is lower, but the description could add more context about what might happen on drop (e.g., triggering file handlers).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and key constraint. Every word earns its place; no fluff or redundancy. It effectively communicates the essential information without over-explaining.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 params, nested object for data), the description covers the essential constraint and behavior. The annotations cover safety profile (destructiveHint, readOnlyHint). No output schema means agents cannot know return value, but the description could mention what happens on success/failure (e.g., returns nothing or error). However, the schema provides enough for parameter usage, and the description adds the key constraint, making it reasonably complete for a simulation action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (4 of 4 parameters have descriptions), so baseline is 3. The description adds value by explicitly stating the condition that at least one of paths or data must be provided, which is not in the schema. This clarifies the relationship between parameters. The schema already explains MIME-type mapping and absolute paths, so there is minimal extra need beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drop files or MIME-typed data onto an element') and the context ('as if dragged from outside the page'). It distinguishes from siblings like browser_file_upload (upload vs drop) and browser_drag (internal drag and drop vs external drop). The requirement that at least one of paths or data must be provided is a key differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for simulating external drag-and-drop operations, but it does not explicitly state when to use this over browser_file_upload or browser_drag. No explicit when-not-to-use or alternatives are mentioned, though the 'as if dragged from outside the page' phrasing provides some context. It could benefit from clarifying that it is not for internal drag-and-drop (use browser_drag) or for file selection dialogs (use browser_file_upload).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by specifying that it returns 'full details (headers and body)' or a single part, which informs the agent about the response structure. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the core purpose, and contains zero wasted words. Every sentence provides actionable information (what it returns, how to specify the request, the optional part filter).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, all with descriptions, 100% coverage, no nested schemas, no output schema), the description is reasonably complete. It covers the main use cases (full details or a single part) and ties into the sibling tool for input. The only minor gap is that the agent might benefit from knowing what happens if `index` is out of range, but that is a judgment call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal additional meaning—it mentions the `part` parameter and the `index` parameter implicitly via `browser_network_requests`—but does not go beyond what the schema states. Baseline 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full details (headers and body) of a network request, optionally a single part via the `part` parameter. It distinguishes itself from the sibling `browser_network_requests` by explicitly referencing its output ("the number from browser_network_requests"), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to use the number from `browser_network_requests` to select the request, which provides clear context for usage. It does not explicitly exclude scenarios or list alternatives beyond the sibling reference, but the connection is explicit enough for an agent to know when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds crucial context beyond annotations: it specifies that the tool is RCE-equivalent and executes in the Playwright server process, not the browser page. This helps an agent understand the security implications and that it can access server resources. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only two sentences. The first sentence clearly states the purpose. The second sentence immediately adds critical safety context. There is no fluff or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and 2 parameters both well-described in the schema, the description is complete enough. It explains what the tool does, its safety implications, and how the code is executed. A user might still wonder about return values, but the schema provides the code parameter description that shows the function returns a value, so it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional param-specific context beyond what the schema provides. Therefore, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a Playwright code snippet', which is a specific verb+resource combination. It distinguishes itself from siblings like 'browser_evaluate' by emphasizing that this tool executes arbitrary JavaScript in the Playwright server process (RCE-equivalent), whereas evaluate typically runs code in the browser page context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns about the unsafe nature ('Unsafe: executes arbitrary JavaScript...RCE-equivalent'), which implies it should only be used when full server-side code execution is needed. However, it does not explicitly state alternatives (like browser_evaluate for page-scoped code) or when not to use it, though the warning strongly implies caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds transparency by stating that actions cannot be performed from the screenshot, reinforcing the read-only nature. It does not contradict annotations and provides behavioral context beyond what the structured data conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, with the core purpose in the first sentence and critical usage guidance in the second. It is front-loaded and contains no extraneous words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters with full schema coverage and annotations providing safety hints, the description adds the key constraint about not being usable for actions and points to a sibling. It covers the most essential contextual information for an agent to decide when to use the tool, though it omits explicit mention of extra features like element or full-page screenshots (which are in the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on any parameter beyond the schema's own descriptions (e.g., type, scale, target, element, filename, fullPage). No additional meaning is added, so the score remains at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Take' and the resource 'screenshot of the current page', establishing the core function directly. It also explicitly distinguishes from the sibling tool 'browser_snapshot' by noting that this tool cannot be used for actions, which satisfies the requirement 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when NOT to use this tool ('You can't perform actions based on the screenshot') and recommends the alternative 'browser_snapshot' for actions. This is clear context with exclusions, though it could additionally state use cases like visual debugging or archiving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it searches the accessibility snapshot (not DOM), returns snippets with paths, and is cheaper than a full snapshot. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with purpose and key return details, and contains no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains what is returned (matching nodes with context and paths). Parameters are fully covered in schema, annotations are present, and the usage advantage is highlighted. The description is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already have detailed descriptions. The tool description does not add new semantic information beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the accessibility snapshot for text or regex and returns matching nodes with context. It distinguishes itself from sibling tool browser_snapshot by noting it is cheaper and returns only matching nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells the agent to use this tool instead of browser_snapshot when only locating elements is needed by stating it is 'cheaper than capturing the whole snapshot'. However, it does not explicitly list when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true (safe read) and destructiveHint=false, so the safety profile is clear. The description adds value by specifying the behavior: 'since loading the page' (explaining the scope/timebound) and 'numbered list' (indicating the output structure requires the partner tool for details). This goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence states what the tool does. The second provides immediate usage guidance for the sibling tool. Every word serves a purpose. No fluff, no repetition of what's in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description could have explained the return format (e.g., structure of the numbered list). But it's clear enough for an agent to understand: it returns a list of requests, each with a number, and the partner tool gets detail by number. The input schema is well-documented. This is adequate for the tool's functionality and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a bit of context by implying the 'filter' and 'static' parameters affect the list, and the 'filename' parameter changes the output format (save vs. return text). However, it doesn't elaborate on the regex usage or the exact effect of including static resources, so it mostly relies on the schema which is already complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and the resource 'numbered list of network requests' with a clear scope ('since loading the page'). It also differentiates from its sibling 'browser_network_request' by noting the partner tool is for getting full details of a specific request. This makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool first to get the list, then 'browser_network_request with the number to get full details'. This establishes a clear workflow. However, it doesn't mention when NOT to use it (e.g., if you already know the request number, or if you need details from a specific filter upfront), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP_DOCS MCP server](https://glama.ai/mcp/servers/DavidG-BLW/MCP_DOCS/badges/card.svg)](https://glama.ai/mcp/servers/DavidG-BLW/MCP_DOCS)

Score Badge

Copy to your README.md:

[![MCP_DOCS MCP server](https://glama.ai/mcp/servers/DavidG-BLW/MCP_DOCS/badges/score.svg)](https://glama.ai/mcp/servers/DavidG-BLW/MCP_DOCS)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DavidG-BLW/MCP_DOCS'

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