Playwright MCP
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Each tool targets a specific browser interaction (click, navigate, screenshot, etc.) or management task (install, close, resize), and descriptions clarify any potential overlaps (e.g., browser_snapshot vs. browser_take_screenshot).
Naming Consistency5/5Tool names follow a highly consistent 'browser_verb_noun' pattern throughout (e.g., browser_click, browser_navigate, browser_tab_list). All tools use snake_case with 'browser_' prefix, making them predictable and readable.
Tool Count4/5With 24 tools, the count is slightly high but reasonable for a comprehensive web automation server. It covers a wide range of interactions (navigation, input, tabs, debugging) without obvious bloat, though it borders on the upper limit of typical scoping.
Completeness5/5The toolset provides complete coverage for web automation and testing. It includes core navigation, user interactions (click, type, drag), tab management, debugging (console, network), media capture (screenshot, snapshot), and utilities (wait, install), leaving no obvious gaps for the domain.
Average 3.5/5 across 24 of 24 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
This server has been verified by its author.
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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true (implying state changes) and readOnlyHint=false (confirming it's not read-only), which the description doesn't contradict. However, the description adds minimal behavioral context beyond annotations—it doesn't specify what 'handle' entails (e.g., accepting/dismissing dialogs, potential side effects like page navigation). With annotations covering safety aspects, the description provides some value but lacks detail on operational 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 extremely concise at two words, with no wasted language. It's front-loaded but under-specified—while brevity is achieved, it sacrifices clarity. In this case, conciseness is maximized, though it doesn't serve the tool's informational needs effectively.
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 with destructive annotations, two parameters, and no output schema, the description is incomplete. It doesn't explain what dialogs are, return values, error conditions, or how it interacts with browser state. Given the complexity implied by parameters and annotations, more context is needed to guide an agent adequately.
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 clear parameter documentation: 'accept' (boolean for dialog acceptance) and 'promptText' (string for prompt dialogs). The description adds no parameter semantics beyond the schema, failing to explain relationships (e.g., promptText is only for prompt-type dialogs) or usage examples. Given high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' is a tautology that restates the tool name without adding specificity. It doesn't clarify what type of dialog is being handled (e.g., browser alert, confirm, prompt) or what 'handle' means in this context. While sibling tools like browser_click or browser_type have clear actions, this description lacks the verb+resource clarity needed for distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It doesn't mention prerequisites (e.g., that a dialog must be present), exclusions, or related tools like browser_console_messages for monitoring. Without any usage context, an agent cannot determine appropriate invocation scenarios.
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 indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by implying a click performs an action. The description adds minimal behavioral context beyond annotations, but it doesn't contradict them. It could enhance transparency by noting potential side effects like navigation or form submissions.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
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?
Given the tool's moderate complexity (4 parameters, destructive operation) and no output schema, the description is minimal but not inadequate. Annotations cover key behavioral traits, but the description could better address context like error handling or typical use cases. It meets a basic threshold but lacks depth.
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 parameters are fully documented in the schema. The description adds no additional meaning about parameters like 'element' or 'ref', nor does it explain their interplay. Baseline score of 3 is appropriate as the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform click on a web page' clearly states the action (click) and target (web page), but it's vague about what exactly gets clicked and doesn't differentiate from siblings like browser_hover, browser_drag, or browser_press_key. It lacks specificity about interacting with page elements versus general clicking.
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 doesn't mention prerequisites (e.g., needing a page snapshot from browser_snapshot), exclusions, or comparisons to siblings like browser_hover for hovering or browser_press_key for keyboard interactions. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, indicating this is a potentially unsafe write operation. The description adds minimal context about evaluating JavaScript but doesn't elaborate on risks (e.g., side effects, permissions needed for element interaction) or behavioral traits like execution scope. It doesn't contradict annotations, but adds limited value beyond them.
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, efficient sentence that immediately conveys the core functionality without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool (per annotations) with no output schema, the description is insufficient. It doesn't explain what 'Evaluate' entails (e.g., returns a value, executes code), potential errors, or safety considerations. Given the complexity and lack of output details, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for all three parameters. The description mentions 'page or element' which loosely relates to the element/ref parameters but adds no specific semantics beyond what the schema provides. With high schema coverage, the baseline 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 ('Evaluate') and target ('JavaScript expression on page or element'), distinguishing it from siblings like browser_click or browser_type that perform different browser interactions. However, it doesn't explicitly differentiate from potential JavaScript-related siblings (none exist in the provided list), so it's not a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a page loaded), exclusions, or comparisons to other tools like browser_console_messages for JavaScript output. Usage is implied but not articulated.
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 provide readOnlyHint=false, openWorldHint=true, and destructiveHint=true, indicating this is a mutable, potentially destructive action with open-world effects. The description adds minimal behavioral context beyond this, not explaining what 'destructive' means in practice (e.g., might trigger page navigation or data loss) or how it interacts with browser state. It doesn't contradict annotations, but offers little extra insight into behavior like rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words—'Press a key on the keyboard' directly conveys the core action. It's front-loaded and efficiently structured, making it easy for an agent to parse quickly. Every word earns its place, with no redundancy or unnecessary elaboration.
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 tool's complexity (a destructive action with open-world effects) and lack of output schema, the description is incomplete. It doesn't cover what happens after pressing a key (e.g., expected outcomes, error handling), nor does it address context like browser focus requirements. With annotations providing some safety cues but no output details, the description should do more to guide usage in this interactive environment.
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 the 'key' parameter fully documented in the schema (e.g., 'Name of the key to press or a character to generate'). The description adds no additional parameter semantics beyond what's in the schema, such as examples of special keys or formatting requirements. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't enhance understanding.
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 ('Press') and resource ('a key on the keyboard'), making the purpose immediately understandable. It distinguishes from siblings like browser_type (which types text) and browser_click (which clicks mouse buttons), though it doesn't explicitly mention these distinctions. The description is specific but could be more precise about the keyboard context versus other input methods.
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 like browser_type (for text input) or browser_click (for mouse actions). There's no mention of prerequisites (e.g., needing a focused browser element) or typical use cases (e.g., simulating keyboard shortcuts). Without this context, an agent might misuse it when other tools are more appropriate.
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 provide readOnlyHint=false, destructiveHint=true, and openWorldHint=true, indicating this is a destructive, non-read-only operation with open-world behavior. The description doesn't contradict these but adds minimal context beyond the obvious 'close' action. It doesn't elaborate on effects like tab removal or potential browser state changes, but annotations cover key safety aspects.
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?
Extremely concise with 'Close a tab'—a single, front-loaded sentence that directly states the purpose without any fluff. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and rich annotations (destructiveHint, openWorldHint), the description is minimally adequate. However, it lacks details on output (no schema provided) and doesn't explain behavioral nuances like what happens after closing (e.g., focus shift), leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'index' fully documented in the schema. The description adds no parameter information beyond what's in the schema, so it meets the baseline of 3 for high coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close a tab' clearly states the action (close) and resource (tab), but it's vague about scope and doesn't distinguish from sibling tools like browser_close (which likely closes the entire browser). It doesn't specify whether it closes the current tab or a specific one, though the schema clarifies this.
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 on when to use this tool versus alternatives like browser_close or browser_tab_select. The description lacks context about prerequisites (e.g., needing an open tab) or exclusions, leaving the agent to infer usage from the schema and annotations 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 already provide key behavioral traits: readOnlyHint=false (implies mutation), destructiveHint=true (implies changes state), and openWorldHint=true (implies dynamic environment). The description adds the specific action of drag-and-drop, which is useful context beyond annotations. However, it doesn't disclose additional behavioral details like what gets destroyed, potential side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the core action.
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?
Given the tool's complexity (destructive browser interaction with 4 required parameters) and rich annotations, the description is minimally adequate. However, with no output schema and incomplete behavioral context (e.g., no mention of what happens after drag-and-drop or error handling), it leaves gaps that could hinder effective tool selection and 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 description coverage is 100%, with clear documentation for all 4 parameters (startElement, startRef, endElement, endRef). The description doesn't add any meaningful parameter semantics beyond what the schema already provides, such as explaining the relationship between 'element' and 'ref' parameters or usage examples.
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') and the target ('between two elements'), which is a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like browser_click or browser_hover, which are also interaction tools but for different 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a page snapshot), when not to use it, or how it differs from other browser interaction tools like browser_click or browser_hover for similar UI tasks.
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 provide readOnlyHint=false, openWorldHint=true, and destructiveHint=true, indicating it's a mutable, open-ended, and potentially destructive operation. The description adds minimal behavioral context beyond this, such as not specifying what 'upload' entails (e.g., to a server, local storage) or any rate limits. It doesn't contradict annotations, but offers little extra insight.
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 extremely concise with a single sentence 'Upload one or multiple files', which is front-loaded and wastes no words. Every part of the sentence directly contributes to understanding the tool's purpose without 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?
Given the tool's moderate complexity (file upload with destructive potential), annotations cover safety aspects, but the description lacks details on output (no schema provided), error handling, or environmental needs (e.g., browser context). It's minimally adequate but leaves gaps for an agent to infer usage.
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, with the 'paths' parameter fully documented in the schema. The description adds no additional semantic meaning beyond implying file uploads, which is already clear from the tool name and schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 action (upload) and resource (files), with specificity about quantity (one or multiple). It distinguishes from sibling tools like browser_navigate or browser_click by focusing on file uploads, though it doesn't explicitly differentiate from all siblings (e.g., browser_drag could involve files).
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 lacks context about prerequisites (e.g., needing an open browser session), exclusions (e.g., not for network requests), or comparisons to other file-related tools (none in siblings, but general alternatives aren't 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation. The description adds minimal behavioral context beyond this, as 'hover' implies a transient interaction without permanent changes. It doesn't specify effects like triggering UI elements or timeouts, but annotations cover the safety profile adequately.
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, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, which is ideal for a straightforward tool like this.
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?
Given the tool's low complexity (simple hover action), 100% schema coverage, and annotations covering safety, the description is minimally adequate. However, it lacks output details (no schema provided) and doesn't explain potential side effects like UI changes, leaving some gaps in completeness for an interactive 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?
Schema description coverage is 100%, with clear descriptions for both parameters: 'element' as a human-readable description for permission and 'ref' as an exact target reference. The description adds no additional parameter semantics beyond what the schema provides, such as examples or interaction details. Baseline 3 is appropriate given the comprehensive schema.
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 'Hover over element on page' clearly states the action (hover) and target (element on page), making the purpose immediately understandable. It distinguishes from siblings like browser_click or browser_type by specifying a hover interaction rather than click or typing. However, it doesn't explicitly mention the mouse or cursor aspect, which the annotation title 'Hover mouse' covers.
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. It doesn't explain scenarios where hovering is appropriate (e.g., to trigger tooltips or dropdowns) or when to prefer other interactions like browser_click. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description doesn't add behavioral details beyond what annotations provide. Annotations indicate destructiveHint=true and readOnlyHint=false, implying this is a write operation that changes browser state, which aligns with 'navigate'. However, the description lacks context like potential side effects (e.g., page reload, navigation blocking) or rate limits. No contradiction with annotations exists.
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, efficient sentence with zero wasted words. It's front-loaded and directly conveys the core action without unnecessary elaboration, making it highly concise and well-structured for quick understanding.
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?
Given the tool's moderate complexity (navigation with destructive potential) and rich annotations (destructiveHint, openWorldHint), the description is minimally adequate. However, with no output schema and the description lacking details on return values or error conditions, there are gaps in completeness for effective agent use.
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, with the 'url' parameter fully documented. The description adds no additional meaning beyond the schema, such as URL format requirements or validation rules. Baseline score of 3 is appropriate since the schema carries the full burden of parameter documentation.
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' clearly states the verb ('navigate') and resource ('URL'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like browser_navigate_back or browser_navigate_forward, which are related navigation actions but with different specific behaviors.
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. It doesn't mention sibling tools like browser_navigate_back for backward navigation or browser_tab_new for opening new tabs, nor does it specify prerequisites such as needing an active browser session. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, and destructiveHint=false, indicating it's a safe, non-destructive operation. The description adds no behavioral context beyond this, such as whether it affects the current tab or all tabs, or if there are constraints like minimum/maximum dimensions. It doesn't contradict annotations, but offers minimal extra value.
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, direct sentence with zero wasted words. It's front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, 100% schema coverage, no output schema) and annotations covering safety, the description is minimally adequate. However, it lacks context on integration with sibling tools or operational details, which could help in more complex scenarios. It meets basic needs but doesn't fully leverage the opportunity for completeness.
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 clear descriptions for width and height parameters. The description doesn't add any semantic details beyond the schema, such as unit explanations (e.g., pixels) or practical constraints. Baseline 3 is appropriate since the schema fully documents the 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 'Resize the browser window' clearly states the action (resize) and resource (browser window), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like browser_tab_new or browser_tab_select, which also involve browser window management but for 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/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. It doesn't mention prerequisites (e.g., needing an active browser session), exclusions, or related tools for similar tasks, leaving the agent to 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive (destructiveHint: true), non-read-only (readOnlyHint: false) operation with open-world implications (openWorldHint: true). The description adds minimal behavioral context beyond this—it doesn't explain what 'destructive' means in practice (e.g., modifies page state), rate limits, or authentication needs. However, it doesn't contradict annotations, so it meets the lower bar with annotations 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
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?
Given the tool's complexity (interactive, destructive), rich annotations, and 100% schema coverage, the description is minimally adequate. However, it lacks details on output (no schema), error handling, or practical examples, leaving gaps for an agent to understand full usage. With annotations covering safety, a 3 reflects basic completeness.
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 the schema fully documents all three parameters (element, ref, values). The description adds no additional meaning about parameters beyond what's in the schema, such as examples of 'values' or how 'ref' relates to snapshots. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 target ('in a dropdown'), providing a specific verb+resource combination. It distinguishes this from siblings like browser_click or browser_type by focusing on dropdown interaction, though it doesn't explicitly contrast with all possible alternatives.
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 like browser_click for general clicking or browser_type for text input. There's no mention of prerequisites (e.g., needing a page snapshot), context for dropdowns, or exclusions for other element types.
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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation with potential side effects. The description adds minimal behavioral context beyond this—it implies opening a tab but doesn't specify what happens if the URL is invalid, if the browser isn't open, or if tab limits are reached. With annotations covering safety, a baseline 3 is appropriate as the description adds little extra value.
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 extremely concise at three words, front-loaded with the core action, and wastes no space. Every word earns its place by directly stating the tool's function without redundancy or fluff, making it easy to parse quickly.
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?
Given the tool's low complexity (one optional parameter) and rich annotations (readOnlyHint, destructiveHint, openWorldHint), the description is minimally complete. However, it lacks output information (no schema provided) and doesn't address edge cases like error handling or browser state. For a simple tool with good annotations, it's adequate but leaves gaps in behavioral 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%, with the 'url' parameter fully documented in the schema as optional for navigating or leaving blank. The description doesn't add any parameter semantics beyond what the schema provides—it mentions opening a tab but not the URL behavior. With high schema coverage, the baseline is 3, and the description doesn't compensate or add extra meaning.
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 'Open a new tab' clearly states the verb ('Open') and resource ('a new tab'), making the purpose immediately understandable. It distinguishes from siblings like browser_tab_close (closing) and browser_tab_list (listing), though it doesn't explicitly differentiate from browser_navigate (which navigates current tab) or mention the optional URL parameter. This is clear but lacks explicit 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose browser_tab_new over browser_navigate (for new vs. current tab), browser_tab_select (for switching tabs), or other navigation tools. There's no context about prerequisites, timing, or exclusions, leaving usage entirely implicit.
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 indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe, non-destructive operation. The description adds minimal behavioral context beyond this—it doesn't explain what 'select' does (e.g., brings tab to focus, changes active view) or any constraints like index validity. No contradiction with annotations, but the description adds little value given 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Select a tab by index.' It's front-loaded with the core action and resource, with no wasted words. This is appropriately concise for a simple tool, making it easy for an AI agent to parse quickly.
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?
Given the tool's low complexity (one parameter, simple operation), annotations cover safety (read-only, non-destructive), and no output schema, the description is minimally adequate. However, it lacks details on behavioral outcomes (e.g., what happens after selection) and usage context, which could help an agent use it correctly in workflows with sibling tools.
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 the parameter 'index' fully documented in the schema. The description mentions 'by index' but adds no extra meaning beyond what the schema provides (e.g., index range, zero-based vs. one-based, or relation to tab list). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 a tab by index' clearly states the action (select) and resource (tab), with the method (by index) specified. It distinguishes from siblings like 'browser_tab_list' (list tabs) and 'browser_tab_close' (close tab), though it doesn't explicitly contrast them. The purpose is specific but could be slightly more detailed about what 'select' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing an open browser or tab list), exclusions, or comparisons to siblings like 'browser_tab_new' (create new tab) or 'browser_navigate' (change URL). Usage is implied by the name but not explicitly stated, leaving gaps for an AI 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?
Annotations indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and openness. The description adds that it waits for text appearance/disappearance or time passage, which provides behavioral context beyond annotations, but doesn't detail timeouts, polling behavior, or error handling. No contradiction with annotations exists.
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, efficient sentence that front-loads the core functionality without unnecessary words. It directly states the tool's purpose, making it easy to parse and understand quickly.
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?
Given the tool's moderate complexity (3 parameters, no output schema) and rich annotations, the description is minimally adequate. It covers what the tool does but lacks details on return values, error conditions, or integration with sibling tools, leaving gaps for an agent to infer behavior.
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 clear descriptions for each parameter (time, text, textGone). The description mentions these three conditions but doesn't add meaning beyond the schema, such as how parameters interact or default behaviors. 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 clearly states the action ('Wait for') and the three possible conditions (text appear, text disappear, time pass), which is specific about what the tool does. However, it doesn't explicitly differentiate from sibling tools like browser_handle_dialog or browser_network_requests that might also involve waiting, though the 'browser_' prefix provides some context.
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. It doesn't mention scenarios where waiting is preferred over other actions, prerequisites, or exclusions, leaving the agent to infer usage from the tool name and parameters 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 indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true, which already inform the agent that this is a safe, non-destructive operation with open-world assumptions. The description adds minimal behavioral context beyond this, but it doesn't contradict annotations, and the low parameter count reduces the need for extensive disclosure.
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 extremely concise with 'Close the page', a single sentence that directly states the action. It's front-loaded and wastes no words, making it efficient for an agent to parse, though it may be overly brief for clarity.
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?
Given 0 parameters, no output schema, and annotations covering safety and world assumptions, the description is minimally adequate. However, it lacks details on scope (e.g., current page vs. all pages) and doesn't differentiate from siblings, leaving gaps in contextual understanding for effective tool selection.
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 input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is acceptable here, but it could have clarified implicit aspects like which page is closed, though the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the page' states a clear action (close) and resource (page), but it's vague about scope—it doesn't specify whether it closes the current page, a specific page, or the entire browser. It also doesn't distinguish from sibling tools like 'browser_tab_close', which suggests potential overlap without clarification.
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. With siblings like 'browser_tab_close' and 'browser_navigate_back', the description lacks context on appropriate use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names 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 provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, read-only operation with potentially unbounded data. The description adds value by specifying 'all console messages', hinting at comprehensiveness, though it doesn't detail format, pagination, or rate limits. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Returns all console messages' is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a simple tool with no parameters.
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?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations (read-only, non-destructive, open-world), the description is adequate but lacks details on output format, timing, or context. It's complete enough for basic use but could benefit from more behavioral context.
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?
With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any, earning a baseline score for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns all console messages' clearly states the verb ('returns') and resource ('console messages'), but it's vague about scope and doesn't distinguish from siblings like 'browser_evaluate' or 'browser_network_requests'. It doesn't specify what type of console messages (e.g., browser console logs) or from what context.
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. The description doesn't mention prerequisites (e.g., needing an active browser session) or compare it to siblings like 'browser_network_requests' for different debugging purposes. Usage is implied but not explicitly stated.
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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds minimal behavioral context by specifying 'since loading the page,' which clarifies temporal scope. However, it doesn't detail return format, pagination, or potential limitations, leaving gaps despite 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a tool with no parameters, making it highly efficient.
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?
Given the tool's low complexity (0 parameters, no output schema) and rich annotations, the description is adequate but minimal. It covers the basic action but lacks details on output format or usage context, which could be helpful despite annotations. It meets minimum viability but doesn't fully leverage the opportunity for completeness.
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?
With 0 parameters and 100% schema description coverage, the baseline is high. The description doesn't need to explain parameters, as there are none. It efficiently focuses on the tool's function without redundancy, earning a score above the minimum viable level.
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 verb ('returns') and resource ('all network requests since loading the page'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'browser_console_messages' or 'browser_snapshot' that might also capture network-related data, though the distinction is somewhat implied by the specific focus on network requests.
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. It doesn't mention prerequisites (e.g., needing a loaded page), exclusions, or compare it to siblings like 'browser_console_messages' for other browser data. The context is implied but not explicitly stated.
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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the agent knows this is a safe, read-only operation that may return variable data. The description adds no behavioral context beyond what annotations provide (e.g., it doesn't specify what information is listed, format, or any limitations). There's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loaded with the core action, and wastes no space. Every word ('List browser tabs') directly contributes to understanding the tool's purpose without redundancy or fluff.
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?
Given the tool's low complexity (0 parameters, read-only), annotations cover safety, and no output schema exists, the description is minimally adequate. However, it lacks details on return values (e.g., tab titles, URLs, counts) or usage context, leaving gaps for an agent to fully understand how to interpret results.
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?
With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to compensate, and a baseline of 4 is appropriate since no parameter information is required. The description implicitly confirms no parameters are needed by not mentioning any.
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 'List browser tabs' clearly states the verb ('List') and resource ('browser tabs'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'browser_tab_select' or 'browser_tab_close', which would require mentioning it's specifically for listing/retrieving tab information rather than manipulating tabs.
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. It doesn't mention use cases like inventorying open tabs, checking tab status, or when to choose this over other browser tools. Without any context about timing or prerequisites, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true (mutation) and openWorldHint=true (unpredictable environment), but the description adds valuable context: it specifies this is for 'editable element' interaction, implying text fields or areas where user input is expected. This clarifies the scope beyond what annotations provide, though it doesn't mention potential side effects like form submission triggers.
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, focused sentence with zero wasted words. It's front-loaded with the core action ('Type text') and immediately specifies the target ('into editable element'), making it highly efficient and scannable.
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 destructive tool (per annotations) with 5 parameters and no output schema, the description is minimally adequate. It identifies the action and target but lacks details about error conditions, what constitutes an 'editable element', or the visual/state changes expected after typing. The annotations help, but more behavioral context would improve completeness.
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?
With 100% schema description coverage, all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond the schema's details about element, ref, text, submit, and slowly. The baseline of 3 is appropriate since the schema carries the full parameter documentation burden.
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 'Type text into editable element' clearly states the verb ('Type') and target ('editable element'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like browser_press_key or browser_select_option, which also involve text input interactions in different contexts.
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. It doesn't mention when browser_type is appropriate compared to browser_press_key (for single keys/commands) or browser_select_option (for dropdown selections), nor does it specify prerequisites like needing a page snapshot or element reference from browser_snapshot.
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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation with open-world semantics. The description adds context by specifying it captures an 'accessibility snapshot' and compares it to a screenshot, but doesn't detail what an accessibility snapshot entails (e.g., format, content) or any behavioral traits like rate limits or performance impact.
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, efficient sentence that directly states the tool's purpose and key differentiator ('better than screenshot'). It is front-loaded with the core action and wastes no words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, rich annotations (readOnlyHint, destructiveHint, openWorldHint), and no output schema, the description is adequate but incomplete. It explains what the tool does and hints at its advantage over a sibling, but lacks details on what an 'accessibility snapshot' returns (e.g., structured data vs. image) or any operational constraints, which could be important for an AI agent to use it effectively.
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?
With 0 parameters and 100% schema description coverage, the schema fully documents the lack of inputs. The description doesn't need to add parameter information, so a baseline of 4 is appropriate as it doesn't introduce confusion or redundancy regarding 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 verb ('capture') and resource ('accessibility snapshot of the current page'), making the purpose specific and understandable. It distinguishes from the sibling 'browser_take_screenshot' by mentioning it's 'better than screenshot', though it doesn't explicitly name that sibling tool.
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 contrasting with 'screenshot' (likely referring to 'browser_take_screenshot'), suggesting this tool is preferred for accessibility purposes. However, it lacks explicit guidance on when to use this tool versus alternatives or any prerequisites, leaving usage context somewhat vague.
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 provide readOnlyHint=true, destructiveHint=false, and openWorldHint=true, indicating a safe, non-destructive operation. The description adds context by specifying 'to the next page,' which clarifies the scope of navigation. However, it does not detail behavioral aspects like what happens if no forward history exists or if it's idempotent.
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, efficient sentence that directly states the tool's function without any unnecessary words. It is front-loaded and perfectly sized for its purpose, earning its place with zero waste.
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?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is mostly complete. It specifies the navigation direction, but could improve by mentioning constraints (e.g., requires forward history) or response behavior, though annotations cover safety aspects well.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. A baseline of 4 is applied as it adequately handles the lack of parameters without redundancy.
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 'Go forward to the next page' clearly states the action (go forward) and the resource (next page) with a specific verb. It distinguishes itself from sibling tools like 'browser_navigate_back' by specifying the forward direction, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in a browser navigation context but does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites (e.g., requiring a forward history) or exclusions, leaving usage context inferred rather than clearly defined.
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 description adds valuable context beyond annotations by specifying the trigger condition ('if you get an error about the browser not being installed'). Annotations already indicate this is a destructive, non-read-only operation with open-world implications, but the description provides practical usage context that helps the agent understand when this tool is needed.
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 consists of two concise sentences that each serve a clear purpose: the first states what the tool does, the second provides usage guidance. There's no wasted verbiage or unnecessary 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 zero-parameter tool with comprehensive annotations (readOnlyHint, destructiveHint, openWorldHint), the description provides adequate context about when to use it. The lack of output schema isn't problematic here since the tool's purpose is installation rather than data retrieval. The description could potentially mention what happens after installation completes.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage context.
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 ('Install') and resource ('the browser specified in the config'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like browser_click or browser_navigate, but the installation function is distinct enough from typical browser interaction tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this if you get an error about the browser not being installed.' This gives clear context for when to invoke this tool versus alternatives, though it doesn't name specific sibling alternatives.
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, destructiveHint=false, and openWorldHint=true, covering safety and scope. The description adds behavioral context by specifying 'previous page', which implies reliance on browser history state—a useful detail beyond annotations. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and appropriately sized for a simple tool with no parameters.
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?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is complete enough for basic use. However, it could mention potential limitations (e.g., no history available) or return values, though not strictly required.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters, and it appropriately omits any parameter details, focusing solely on the tool's action.
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 'Go back to the previous page' clearly states the action (go back) and target (previous page) with a specific verb+resource. It distinguishes from siblings like 'browser_navigate_forward' by specifying directionality, 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 implies usage context (navigation history) but doesn't explicitly state when to use this vs. alternatives like 'browser_navigate' or 'browser_navigate_forward'. It provides clear context for browser navigation but lacks explicit exclusions or named alternatives.
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, establishing this as a safe read operation. The description adds valuable context about the limitation that screenshots can't be used for actions, which goes beyond what annotations convey. However, it doesn't mention potential limitations like size constraints or performance implications.
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 consists of just two sentences that are perfectly front-loaded: the first states the core purpose, the second provides critical usage guidance. Every word serves a purpose with zero redundancy or unnecessary elaboration.
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 read-only operation with comprehensive parameter documentation in the schema, the description provides sufficient context about purpose and limitations. The main gap is the lack of output schema, but the description adequately covers the tool's scope given its annotations and sibling context. It could benefit from mentioning return format or typical use cases.
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?
With 100% schema description coverage, the input schema comprehensively documents all 5 parameters. The description doesn't add any parameter-specific information beyond what's already in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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 specific action ('take a screenshot') and resource ('current page'), distinguishing it from sibling tools like browser_snapshot which is mentioned for actions. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 provides when-not-to-use guidance: 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This gives clear alternative usage and distinguishes between screenshot capture (this tool) and interactive snapshots (sibling tool).
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/maywzh/playwright-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server