playwright-parallel-mcp
Server Quality Checklist
Latest release: v0.3.0
- Disambiguation5/5
Each tool targets a distinct operation in browser automation: navigation, clicking, typing, selecting, dragging, dropping, uploading, snapshotting, network inspection, and console messages. Even similar tools like browser_evaluate and browser_run_code_unsafe are clearly differentiated by their execution context (page vs server).
Naming Consistency3/5Most tools follow a 'browser_' prefix, but the suffix is inconsistent: some use verbs (navigate, click, hover) while others use nouns (snapshot, screenshot, console_messages). Session management tools (create_session, list_sessions, close_session) deviate entirely from the prefix pattern, creating a mixed convention.
Tool Count3/5With 27 tools, the server is on the heavier side, but the breadth covers a full browser automation workflow including interactions, network, console, dialogs, and session management. The count is justified by the domain, though it exceeds the typical well-scoped range.
Completeness4/5The tool set covers the core browser automation lifecycle: navigation, interactions, snapshots, waiting, tabs, file uploads, and network inspection. Minor gaps like forward navigation or explicit scrolling can be worked around via browser_evaluate or browser_navigate, so there are no dead ends.
Average 3.3/5 across 27 of 27 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to disclose what happens when a dialog is accepted vs. dismissed, whether promptText is required, whether the dialog blocks, or any side effects. This is a critical omission for a mutating interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While brief, the description is severely under-specified rather than concise. It lacks any structural elements that aid understanding, such as scenario examples or a clear statement of functionality. It is a fragment that does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, the description is grossly incomplete. It does not explain dialog types, the meaning of accept, the role of promptText, or the expected behavior, making it impossible for an agent to use the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for all three parameters (accept, sessionId, promptText). The description adds no additional meaning, but the baseline of 3 is appropriate given the schema's thoroughness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' is a near-restatement of the tool name, offering only a generic verb and resource. It does not specify what kind of dialog (alert, confirm, prompt) or what 'handle' entails (accept/dismiss), and it fails to distinguish this from sibling browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what triggers a dialog, or how it relates to alternative browser actions. There is no mention of prerequisites or exclusions, so the agent is left without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Type text into editable element' without mentioning whether text is appended or replaced, whether key events are triggered, if focus is required, or any side effects. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified for the tool's complexity. It lacks any structural guidance or additional context beyond the basic action. It may be front-loaded, but it is not appropriately sized for a tool with six parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a minimal description, the tool is severely under-contextualized. The description does not explain what happens after typing, how the element is selected, or how it relates to sibling actions. The rich schema information is not leveraged in the description, leaving the overall context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all six parameters are fully described in the schema. The description adds no extra meaning about parameter selection or relationships. Per the rubric, the baseline is 3 when schema coverage is high, and the description does not exceed that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'type' and a specific resource 'editable element', making the core purpose understandable. However, it does not distinguish this from sibling tools like browser_fill_form or browser_press_key, which could also involve typing text. The lack of differentiation prevents a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_fill_form or browser_press_key. It gives no context about typical scenarios, prerequisites (e.g., element focus), or exclusions. This leaves the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The single sentence offers no insight into how the click is executed, whether it waits for navigation, how targets are resolved, or what side effects occur. This is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is highly concise and front-loaded. However, the extreme brevity undermines its utility, making it an efficient but under-specified statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 6 parameters, no output schema, and no annotations. The description provides almost no context for behavior, return values, or failure modes. For a tool of this complexity, the description is severely inadequate for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and every parameter has a descriptive text within the input schema. The tool description itself adds no parameter semantics, but the baseline of 3 applies because the schema thoroughly documents all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (perform click) and resource (web page), making the core purpose understandable. However, it does not differentiate from sibling interaction tools like browser_hover or browser_type, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, browser_press_key, or browser_type. There is no mention of exclusions, prerequisites, or preferred contexts, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only restates the tool's name ('Press a key') without detailing side effects, such as whether a keydown/keyup event is dispatched, whether it requires focus on a specific element, or what the return value is. This is essentially a tautology with no added information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and easy to read, but it does not earn its place because it essentially repeats the tool name without adding useful context. It is not overly verbose, but it is under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, leaving the description as the sole source of context. It fails to explain what happens after pressing a key, the return value, or any prerequisites (e.g., active session). For a simple action tool, this is insufficient to guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (`key` and `sessionId`), so schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema already states, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a key on the keyboard' clearly identifies the action (pressing a key) and the resource (keyboard). However, it does not explicitly distinguish itself from sibling tools like `browser_type` or `browser_click`, which also involve keyboard input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as `browser_type` or `browser_click`. The description offers no context, exclusions, or alternative tool references.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that files are uploaded, with no mention of side effects, cancellation behavior, permissions, or reversibility. The schema adds some detail (e.g., omitting paths cancels the chooser), but the tool description itself is nearly tautological with the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than appropriately concise. It repeats the tool name's intent without adding valuable information, so it does not earn its place as a meaningful contribution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description alone is insufficient to fully understand the tool's behavior. It does not explain when to use it, what happens after upload, or any limitations. The schema covers parameters but not the operational context, leaving the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no additional parameter meaning beyond what the schema already provides, so it neither improves nor degrades the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Upload') and resource ('files'), and clarifies it handles 'one or multiple files'. The tool name 'browser_file_upload' reinforces the browser context, making the purpose clear. However, it does not differentiate from siblings because no sibling upload tool exists, so it loses the fifth point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., needing an active session), or when not to use it. The description only states the action, leaving the agent without contextual decision-making information.
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?
No annotations are provided, so the description carries the full burden. 'Close the page' gives no indication of side effects (e.g., whether the session is invalidated, whether the operation is destructive, or if it can be undone). For a mutating action, this lacks essential behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is appropriately sized for a simple tool. It is front-loaded and contains no wasted words. However, it is slightly too minimal, providing no context beyond the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description 'Close the page' is too incomplete. It fails to explain what occurs to the session, whether the session remains open, or any prerequisites. For a tool with a required sessionId, more context is needed for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter, sessionId, is documented with a description). The tool description adds no additional meaning beyond the schema. Per the rubric, a high schema coverage yields a baseline of 3, and no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the page' uses a specific verb and resource, clearly indicating the action of closing the browser page. It is distinct from siblings like close_session which likely closes the session, though it doesn't explicitly differentiate. The purpose is clear enough for a simple 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as close_session, browser_navigate, or browser_navigate_back. It provides no context or exclusions, so the agent is left without direction on choosing this tool.
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?
With no annotations, the description must disclose behavioral traits, but it only says 'Returns all console messages.' It fails to mention the default behavior (messages since last navigation), the level filtering hierarchy, or the optional file save behavior. The description is misleading by saying 'all' when the 'all' parameter defaults to false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is front-loaded and efficient. However, it is so terse that it omits critical context, preventing a higher score for conciseness that balances completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations, yet the description provides almost no contextual information. It does not explain the 'all' parameter's effect, the level hierarchy, or the filename option. An agent would have to rely entirely on the schema, leaving significant gaps for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for all four parameters, resulting in 100% coverage. The tool description adds no additional parameter information, so it does not go beyond the schema. A baseline of 3 is appropriate because the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns console messages, using a specific verb and resource. It distinguishes the general function from sibling tools like browser_network_requests, but it does not explicitly differentiate from alternatives or mention filtering capabilities, which would justify 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/5Does 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_network_requests or browser_evaluate. There is no mention of prerequisites, scenarios, or exclusions. The only implied context is browser console messages, which is insufficient.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It merely says 'Evaluate JavaScript expression' without mentioning potential side effects, safety implications, or whether the page can be modified. The wording 'evaluate' sounds read-only, but arbitrary JS execution can have side effects, and the description does not clarify this risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action. However, it is so brief that it omits important context that would be relevant for a code execution tool, though that omission is more a completeness issue than a conciseness problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary JavaScript, the description is severely under-specified. With no annotations and no output schema, it should explain security considerations, return format, and when to use it versus browser_run_code_unsafe. None of this is present, making the tool difficult to invoke safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter description coverage, so the schema already documents each parameter. The description adds minimal value by mentioning 'on page or element', which hints at the optional target/element parameters, but does not elaborate on syntax or expected behavior beyond what the schema already states. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Evaluate JavaScript expression on page or element' uses a clear verb and resource, indicating the tool executes JS in the browser context. It is not a tautology and gives basic scope, but it does not differentiate from the sibling tool 'browser_run_code_unsafe', which also executes code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_run_code_unsafe or other interaction tools. The description lacks context on appropriate scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name and schema alone.
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?
There are no annotations, so the description must convey behavioral traits. It only states 'Fill multiple form fields' with no mention of event triggering, value overwriting, hidden fields, or return behavior. The tool modifies form state, but the description does not disclose potential side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no filler, earning a high score for brevity. However, it is under-specified, which slightly reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse. It does not explain how to construct the 'fields' array, what each field entry requires, or what the tool returns. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (sessionId and fields) at 100% coverage. The description adds no extra meaning beyond that, leaving the structure of each item in the 'fields' array undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' clearly identifies the verb (fill) and resource (form fields), distinguishing it from sibling tools like browser_type or browser_click which handle single fields. However, it lacks specificity about the mechanism or scope beyond 'multiple'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool over alternatives. Sibling tools such as browser_type and browser_select_option exist, but the description does not explain when bulk filling is preferred or any prerequisites like focusing on the form.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior, but it only restates the tool's name. It does not mention whether the element must be visible, whether hover triggers events or UI changes, how permissions are handled, or what the return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the core action. No words are wasted, and it is appropriately sized for a simple tool, even though it lacks supplemental context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain when to use hover vs. other interactions, nor does it clarify expected outcomes. Given the tool has no output schema and no annotations, the description should offer more context, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (target, element, sessionId) with 100% coverage. The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over element on page' uses a specific verb (hover) and identifies the target resource (element on page), clearly distinguishing it from sibling tools like browser_click or browser_drag. It is concise 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 Guidelines2/5Does 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 compared to alternatives, nor does it mention scenarios like triggering hover effects or needing a static snapshot. Without any context or exclusions, an 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.
- Behavior2/5
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. 'Navigate to a URL' does not mention effects on the current page, page load waiting, error handling, or how it interacts with sessions beyond the sessionId parameter. Important behavioral details are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero waste. It is front-loaded and easy to parse, though it is minimal to the point of being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a potentially impactful action on a browser session, the description lacks essential context such as whether the navigation waits for page load, what happens if the URL is invalid, or whether previous page state is lost. Without annotations or an output schema, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both 'url' and 'sessionId' described. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 and resource, making it obvious what the tool does. It is distinct from sibling 'browser_navigate_back' which implies backward navigation, but it does not explicitly contrast itself with any other navigation-like tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'browser_navigate_back' or other browser actions. The description gives no context about use cases, prerequisites, or situations where a different 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of disclosing behavioral traits. It fails to mention that the resize affects the current session's viewport, whether it is reversible, or any side effects on layout. In fact, it provides no information beyond the tool's name, leaving the agent completely uninformed about operational semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise, containing a single straightforward sentence. It is front-loaded and efficient, though it borders on under-specification due to the lack of any additional context. Still, for a simple tool, the brevity is not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (three scalar parameters, no output schema), the description might seem sufficient, but the absence of annotations and any contextual details (e.g., how sessionId is used, whether the resize is sticky across navigations) leaves it incomplete for an agent to invoke correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions that align with the schema. The description does not add any meaning beyond the schema, so a baseline score of 3 is appropriate. It neither clarifies the sessionId parameter nor explains how width and height are applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resize the browser window' uses a specific verb ('resize') and resource ('browser window'), making the tool's purpose unambiguous. It clearly distinguishes itself from sibling tools that handle navigation, clicking, or other browser actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, when not to use it, or any prerequisites. The description simply states the action without contextual hints about appropriate use cases or limitations.
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?
There are no annotations, so the description carries the full disclosure burden. It merely restates the action without detailing side effects, multi-select behavior, or any required conditions. This is no more informative than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it highly concise and easy to parse. It earns a high score for brevity, though it sacrifices substance for compactness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description provides almost no context about expected return values or side effects. The tool has four parameters and operates in a browser context, yet the description fails to explain any behavioral nuances or prerequisites, leaving it incomplete for an autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameter descriptions, so the description need not elaborate. The description adds no extra meaning beyond what the schema fields already define, meeting the baseline for schema-heavy tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select an option in a dropdown' clearly identifies the verb (select) and resource (option in a dropdown), making the tool's purpose unambiguous. However, it does not distinguish this from sibling tools like browser_fill_form or browser_type, so it lacks 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 Guidelines2/5Does 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 prerequisites, context (e.g., page snapshot required), or exclusions. This leaves the agent without decision support for tool selection.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Perform drag and drop' without explaining side effects, whether the action is reversible, or if it requires specific permissions or element visibility. The description is too terse to disclose meaningful behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently communicates the core action without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description is minimal. While the schema covers parameters well, the description does not provide enough context about expected results, edge cases, or interaction requirements. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions in the schema adequately explain the meaning of 'startTarget', 'endTarget', and optional fields. The tool description adds no parameter-level insight, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Perform drag and drop between two elements' with a specific verb and resource. It clearly indicates the tool's purpose but does not differentiate it from the sibling tool 'browser_drop', which could also imply similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_click' or 'browser_drop'. There is no mention of prerequisites, scenarios, or exclusions.
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?
With no annotations provided, the description carries the full burden of explaining behavioral traits, but it is extremely sparse. It does not describe what an accessibility snapshot contains, whether it is read-only, how results are returned, or any side effects. The claim 'better than screenshot' is subjective and vague, adding no concrete behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the primary action and includes a relevant comparison. This is appropriately concise for a simple read-only snapshot tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and no output schema, so the description must provide enough context for an agent to understand the tool's overall behavior and return value. However, it only mentions the primary action and a screenshot comparison. It does not explain the shape of the snapshot, how filename or target affect behavior, or what output to expect, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all five parameters, each with clear descriptions (e.g., boxes, depth, target, filename, sessionId). The tool description itself adds no additional parameter context, but the schema already documents what each parameter does, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 of the current page, with a specific verb ('Capture'), resource ('accessibility snapshot'), and scope ('current page'). It also explicitly distinguishes itself from the sibling screenshot tool by claiming it is 'better than screenshot', which helps select it over that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'this is better than screenshot' provides some context for when to choose this tool over a screenshot, but it does not explain when to use it vs other DOM inspection tools like browser_find or browser_evaluate, nor does it mention any exclusions. It offers only a single implicit comparison, not comprehensive guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists the operations without explaining side effects such as whether creating a tab navigates immediately, whether closing the current tab without an index behaves differently, or what 'select' does in terms of focus. It also does not mention any return values, permissions, or impact on the session. The description is a bare enumeration, not a transparent explanation of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the core purpose and lists all actions concisely. There is no redundancy, fluff, or unnecessary detail. Every word earns its place, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and multiple actions, but no output schema and no annotations. The description does not explain what 'list' returns, how indices are interpreted (beyond schema notes), or what happens when closing without an index. While the schema covers parameter syntax, the description lacks behavioral and output context, making it incomplete for an agent to fully understand the tool's effects and return values. A more complete description would mention return format and action-specific behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (url, index, action, sessionId) is already documented in the input schema. The tool description adds no parameter-level information. Per the baseline rule, when schema coverage is high, a score of 3 is appropriate—the schema does the heavy lifting, and the description provides no additional value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's scope with the verb 'List, create, close, or select' and explicitly names the resource ('browser tab'). It also enumerates the distinct actions, which distinguishes it from sibling tools like browser_navigate or browser_click that focus on page-level operations. This is a specific and unambiguous purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the available actions (list, create, close, select), suggesting when to use the tool for tab management. However, it does not explicitly state when to prefer this tool over alternatives (e.g., when to use browser_navigate for navigation vs. browser_tabs for tab selection) or provide any contextual rules or exclusions. Usage is only implied through the action list, not explicitly guided.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what 'active' means, any side effects, or output specifics. This lack of detail leaves behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 without unnecessary words. It is concise yet clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For such a simple tool, the description gives the core purpose, but it omits details like what constitutes an 'active' session, the output format, and whether the current session is included. Since there is no output schema, the description could have been more informative to make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The description adds no parameter information, but according to the baseline for 0-param tools, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all active browser sessions.' It uses a specific verb (List) and resource (active browser sessions), and it is distinct from sibling tools that deal with tabs, navigation, or session creation/closure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 create_session, close_session, or browser_tabs. There is no mention of prerequisites, exclusions, or suitable contexts. Only the tool's basic function 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the three waiting modes but does not explain how modes are selected (e.g., interaction of parameters), timeout behavior, error handling, or return value. This leaves significant gaps for an agent deciding whether to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 13 words, front-loaded with the verb and covering all primary behaviors. Every word contributes meaning with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, no output schema, no annotations), the description is too sparse. It does not explain optional parameter behavior, default wait times, mode conflict resolution, or what happens if no condition is met. This leaves substantial ambiguity for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description adds value by linking parameters to modes: text for appearance, textGone for disappearance, time for time-based wait. This clarifies the intended semantics beyond individual parameter descriptions and helps infer parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Wait for' and clearly states the resource and three modes: text appearance, text disappearance, and time passage. It distinguishes itself from sibling browser tools by describing a unique waiting functionality not covered by others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios (when you need to wait for text or time), but provides no explicit guidance on alternatives or exclusions. Since it's the only wait-related tool among siblings, the implied usage is somewhat clear, but there is no direct comparison or 'when not to use' guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal a significant side effect (terminating the backend process), which adds transparency. However, it does not mention irreversibility, resource cleanup, or potential failure modes, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that front-loads the primary action. Every word earns its place, with no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is largely complete. It explains the core purpose and the key side effect. It does not elaborate on prerequisites or return behavior, but these are not critical for a straightforward close operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter 'sessionId' with 100% coverage. The description adds no additional meaning or context about this parameter, so it does not exceed the baseline provided by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: closing a browser session and terminating its backend process. It uses a specific verb ('close') and resource ('browser session'), and the addition of 'terminate its backend process' distinguishes it from related sibling tools like 'browser_close'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as 'browser_close' or 'list_sessions'. It merely states what the tool does, leaving the usage context implied rather than explicitly directing the agent.
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?
No annotations are provided, so the description carries the full burden. It clearly states the navigation effect, but does not disclose potential error conditions (e.g., no history), return value, or impact on current page state. This is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that precisely states the action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and one parameter, the description explains the primary function. However, it omits information about return values, error behavior, and edge cases, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, sessionId, is fully described in the schema. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Go back') and the resource ('previous page in the history'), effectively distinguishing it from browser_navigate which navigates to a new URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied through the verb 'go back' but no explicit guidance is given about when to use this versus alternatives like browser_navigate or browser_tabs. No exclusions or alternative tools 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?
With no annotations, the description must disclose behavior itself. It adds valuable context about isolation and independent MCP backend processes, but omits expected outcomes (e.g., return value, session handle), resource implications, and error conditions. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each conveying essential information: the action and the isolation/independence trait. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter create tool, the description is adequate but incomplete. It fails to mention what the tool returns (a session identifier) or how the created session is referenced by sibling browser tools, which an agent needs to invoke subsequent operations correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a clear description of the `backend` parameter including options. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('new isolated browser session'), clearly distinguishing from sibling lifecycle tools like close_session and list_sessions. It also adds context about independent backend processes, reinforcing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for establishing a new session before browser operations, but does not explicitly state when to choose this over alternatives or note prerequisites. Because sibling tools include session management tools, the context suggests lifecycle usage, but the description itself lacks explicit guidance.
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?
With no annotations, the description carries the full burden. It explicitly discloses the tool is RCE-equivalent and executes code in the server process, which are critical behavioral traits. It does not mention additional traits like session impact or error behavior, but the RCE disclosure is a strong, central warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core action and a critical safety warning. Every word earns its place: no redundancy, front-loaded with purpose and risk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a dangerous code-execution tool, the description gives the essential risk warning and execution context, but it lacks guidance on appropriate use cases (e.g., fallback when other tools are insufficient) and potential side effects. The schema covers parameter details, but the description is minimal for such a powerful tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all three parameters, including the relationship between 'code' and 'filename'. The tool description adds no extra parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a Playwright code snippet, identifying the action (run) and resource (code snippet). It further specifies it executes arbitrary JavaScript in the Playwright server process, which distinguishes it from sibling tools like browser_evaluate (likely page-context evaluation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is an advanced catch-all tool for running raw Playwright code, but it does not explicitly state when to use it versus alternatives. The warning 'Unsafe' is a cautionary note, not usage guidance; it lacks direct comparison to sibling tools like browser_evaluate.
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?
No annotations are provided, so the description carries the full burden. It only states what is returned, without disclosing whether the operation is read-only, any side effects (e.g., writing to a file when `filename` is set), or session requirements. The `filename` parameter implies a potential file write that is not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and efficiently covers the main functionality and the optional `part` variant. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 4 parameters and no output schema. The description explains what is returned (headers and body) and how to select a request. It does not mention file-saving behavior or prerequisites like an active session, but given the simplicity and sibling context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that `index` is the number from `browser_network_requests` and that `part` can filter to a single part of the request, which goes beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 single network request, or a specific part if `part` is set. It distinguishes itself from the sibling tool `browser_network_requests` (which lists requests) by focusing on a single request and referencing the index from that list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage guideline: 'Use the number from browser_network_requests.' This indicates the prerequisite step to obtain the index. It does not explicitly mention when not to use the tool, but the workflow context is clear enough for selecting the tool.
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?
With no annotations, the description carries the full burden. It states the primary behavior (numbered list since page load) but does not disclose potential side effects, failure behavior, or details about filters and file saving. The return format and the time scope are mentioned, giving a basic understanding, but additional context would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The main purpose is front-loaded, and the sibling reference is placed at the end, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the essential behavior and the relationship to the sibling tool. It does not explain the filter and static parameters, but those are fully documented in the schema. It lacks discussion of error conditions or when the list resets, but the 'since loading the page' scope provides necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description does not add any parameter-specific meaning, which is acceptable given the schema's thoroughness. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a numbered list of network requests since page load, using a specific verb and resource. It also distinguishes itself from the sibling browser_network_request by indicating that the sibling provides full details for a numbered item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the user to use browser_network_request for full details, which provides an alternative for the next step. However, it does not mention when to use this tool over other network-related tools or state any exclusions, so it falls 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. It discloses an important constraint ('At least one of paths or data must be provided') and clarifies the external-drop nature, but it does not mention potential side effects, permission requirements, or the dispatched events (drop, dragenter, etc.). This is some but not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, starts with the action, and includes only essential information. Every word earns its place; there is no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description gives the core purpose and a key logical constraint, but omits usage guidance and deeper behavioral context (e.g., events, prerequisites). The schema covers parameter specifics, so the description is not wholly inadequate, but it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 a valuable constraint that is not enforced by the schema's required fields: at least one of 'paths' or 'data' must be supplied. This gives meaningful guidance about parameter relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drop'), the resource ('onto an element'), and the data being dropped ('files or MIME-typed data'). It also distinguishes from siblings like browser_drag or browser_file_upload by specifying 'as if dragged from outside the page', making the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: you drop files or MIME data onto an element, simulating an external drag-and-drop. However, it does not explicitly mention alternatives or when NOT to use this tool (e.g., for in-page drags use browser_drag, for file inputs use browser_file_upload), so it lacks explicit exclusion guidance.
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?
Without annotations, the description carries the burden of disclosing behavioral traits. It adds a key limitation (screenshots are not actionable) and points to an alternative, which is valuable. It does not mention other behaviors like file storage or permissions, but these are either implied by the tool's name or covered by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately state the purpose and include a useful warning. There is no redundant or extraneous content; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema covers all parameters and behaviors like fullPage and element screenshots. The description adds the critical distinction from browser_snapshot and notes the non-actionable nature of screenshots. While return formatting isn't described, it's straightforward for a screenshot tool, making the overall definition complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for all parameters, including enums and defaults. The tool description itself does not add parameter-specific details, so a baseline score of 3 is appropriate given the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function ('Take a screenshot of the current page') with a specific verb and resource. It also distinguishes itself from the sibling tool browser_snapshot by noting screenshots cannot be used for actions, which clarifies its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when not to use this tool ('You can't perform actions based on the screenshot') and directs to the appropriate alternative ('use browser_snapshot for actions'). This provides clear contextual guidance for tool selection.
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?
With no annotations, the description carries the full burden. It discloses that the search operates on the accessibility snapshot (not the live DOM), returns matching nodes with surrounding context, displays them under a path from the root, and notes the performance benefit. It does not mention edge cases like no matches, but it provides solid behavioral context for a basic search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the action, target, return format, and a cost comparison. Every clause adds value, and it is front-loaded with the core purpose. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does, when to use it, what it returns (nodes with surrounding context, shown under paths), and why it is beneficial (cheaper than full snapshot). Since there is no output schema, the return shape is described well. It is complete for a search tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and the schema already explains each parameter (text is a case-insensitive substring match; regex supports flags; sessionId described). The description's phrase 'text or a regular expression' adds no extra meaning beyond what the property descriptions already provide, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb, 'Search', and clearly identifies the resource: 'the accessibility snapshot of the current page' for 'text or a regular expression'. This distinguishes it from siblings like browser_snapshot (which captures the whole snapshot) and browser_click (which performs an action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: 'when you only need to locate an element and its ref'. It also implies the alternative of 'capturing the whole snapshot' and notes that this method is 'cheaper'. This provides clear context and suggests a preferred use case.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/sumyapp/playwright-parallel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server