Puppeteer MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as navigation (navigate, go_back), interaction (click, fill, hover), and waiting (wait, wait_for_selector). However, some overlap exists between mouse actions: 'mouse' (perform actions at coordinates) and 'click' (click an element) could be confused for similar tasks, though descriptions clarify their differences.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun or verb_preposition_noun structures, such as 'click', 'close_tab', 'get_content', and 'wait_for_selector'. There are no deviations in naming conventions, making the set predictable and readable.
Tool Count3/5
With 27 tools, the count is borderline high for a Puppeteer server, as it includes many specific actions like 'hover' and 'keyboard' that might be consolidated. While comprehensive, it risks feeling heavy compared to typical well-scoped sets of 3-15 tools, but it's reasonable for browser automation.
Completeness5/5
The tool set provides complete coverage for browser automation, including navigation, interaction, content retrieval, tab management, cookies, and waiting mechanisms. There are no obvious gaps; agents can perform full CRUD-like operations (e.g., get/set cookies, open/close tabs) and handle common workflows without dead ends.
Average 3.1/5 across 27 of 27 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Generate a PDF') but doesn't describe what 'current page' means, whether this requires specific page states, what happens if generation fails, or any performance characteristics. The description provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the core functionality without unnecessary words. It's perfectly front-loaded with the essential information. Every word earns its place, making this an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'current page' means in context of browser automation, doesn't describe the PDF generation process or output format, and provides no guidance on parameter usage. The description leaves too many open questions for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 20% schema description coverage (only 'tabId' has a description), the description provides no information about any parameters. It doesn't mention format options, layout settings, or margin configurations that the schema reveals. The description fails to compensate for the low schema coverage, leaving most parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and resource ('PDF of the current page'), making the purpose immediately understandable. It distinguishes from sibling tools like 'screenshot' by specifying PDF generation rather than image capture. However, it doesn't explicitly differentiate from all possible document generation tools, keeping it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'screenshot' for visual captures or other document generation methods. It doesn't mention prerequisites (e.g., requires an active page/tab) or contextual constraints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention potential side effects (e.g., page navigation, form submissions), error conditions (e.g., if selector fails), or performance considerations (e.g., waiting for element). This leaves significant gaps for a tool that interacts with dynamic web content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after clicking (e.g., returns success/failure, triggers events), error handling, or interaction with page state. Given the complexity of web automation, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying a 'selector' parameter, which is already covered. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Click an element on the page' clearly states the action (click) and target (element on page), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'mouse' or 'hover' that also interact with page elements, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'mouse' (which might offer more granular control) or 'hover' (for non-click interactions). The description lacks context about prerequisites (e.g., needing an element to be visible) or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Delete') which implies mutation, but doesn't describe side effects (e.g., whether deletion is permanent, if it affects browser state), authentication needs, rate limits, or error conditions. For a destructive operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and immediately communicates the essential functionality. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion (success/failure indicators), whether multiple cookies can be deleted atomically, or how it interacts with browser state. The agent lacks critical context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('names' and 'tabId') clearly documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema (e.g., format of cookie names, what happens if tabId is invalid). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('cookies by name'), making the purpose immediately understandable. It distinguishes from sibling tools like 'set_cookies' and 'get_cookies' by specifying deletion rather than creation or retrieval. However, it doesn't explicitly mention the browser context or differentiate from other deletion tools, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser session), when not to use it, or how it relates to sibling tools like 'set_cookies' or 'get_cookies'. The agent must 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?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether it waits for the element to be visible, handles errors if the selector fails, or interacts with page state. This leaves significant gaps for a tool that modifies web page content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. Every word earns its place with no redundancy or fluff, making it easy to parse quickly while conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error conditions, or interaction with page state, leaving the agent with incomplete context for safe and effective use in a browser automation scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional meaning beyond implying 'value' is for text input, which is already clear from schema descriptions. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fill') and target ('text input or textarea'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'select' or 'keyboard' that might also input text, but it's specific enough to convey the core function without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'keyboard' for typing or 'select' for dropdowns. The description only states what it does, not when it's appropriate, leaving the agent to infer usage from context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'focus an element' implies a non-destructive UI interaction, it doesn't disclose behavioral traits like what happens if the element isn't focusable, whether it waits for the element to appear, what visual feedback occurs, or error conditions. The description is too minimal for a tool that interacts with browser elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and target. Every word earns its place, making it highly efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser automation (interacting with dynamic pages) and lack of annotations or output schema, the description is insufficient. It doesn't explain what 'focus' means in this context (e.g., UI focus vs. programmatic focus), what happens on success/failure, or how it relates to other browser tools. For a tool with 3 parameters and no structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters (selector, timeout, tabId). The description adds no additional parameter semantics beyond what's in the schema. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate or provide extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('focus') and target ('an element on the page'), making the purpose immediately understandable. It distinguishes itself from siblings like 'click' or 'hover' by specifying a different interaction type. However, it doesn't explicitly differentiate from similar tools like 'select' or 'query_selector' which might also involve element targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'click', 'hover', 'select'), there's no indication of when focusing an element is appropriate versus other interactions. No prerequisites, exclusions, or complementary tools are mentioned.
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 mentions what the tool does but lacks behavioral details such as permissions needed, rate limits, error handling, or what happens if the selector doesn't exist. This is inadequate for a tool that interacts with web content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with web content, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like return format, error cases, or dependencies on other tools (e.g., requiring a page to be loaded), leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters well. The description adds minimal value by implying the tool can retrieve full page content or specific elements, but doesn't provide additional semantics beyond what the schema specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'HTML or text content of the page or a specific element', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'query_selector' or 'evaluate', which might also retrieve content, so it lacks 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'query_selector' and 'evaluate' that might overlap in functionality, there's no explicit context or exclusions mentioned, leaving usage unclear.
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 states what the tool does but lacks details on permissions needed, rate limits, whether it returns all cookies or specific types, or how errors are handled. This is insufficient for a tool that interacts with browser data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and scope without any unnecessary words. It's front-loaded and appropriately sized for its function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser cookie retrieval, no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., cookie objects with attributes), potential security considerations, or error cases, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('urls' and 'tabId') with their purposes and default behaviors. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('cookies'), specifying it can target the current page or specified URLs. However, it doesn't explicitly differentiate from sibling tools like 'delete_cookies' or 'set_cookies' beyond the verb difference, which is why it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning the default behavior (current page if no URLs specified), but it doesn't explain when to use this tool versus alternatives like 'delete_cookies' or 'set_cookies', nor does it outline any prerequisites or exclusions for usage.
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 mentions the action but lacks details on side effects (e.g., if it triggers events), error handling, or performance implications. This is a significant gap for a tool that interacts with web elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, making it highly efficient and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interacting with web elements) and lack of annotations and output schema, the description is incomplete. It doesn't cover what happens on hover (e.g., tooltips, state changes), success/failure indicators, or integration with sibling tools, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as examples or edge cases, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('hover over') and target ('an element on the page'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'mouse' or 'click', which might have overlapping functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like 'mouse' or 'click' from the sibling list, nor does it mention any prerequisites or exclusions. It's a basic statement of function without contextual usage advice.
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 full burden for behavioral disclosure. It states what the tool does ('Press') but doesn't describe important behavioral aspects: whether this simulates physical key presses, how it interacts with browser focus, what happens if the target isn't keyboard-focusable, or any side effects. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single, clear sentence that communicates the core functionality without any wasted words. It's front-loaded with the essential action and doesn't include unnecessary elaboration or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'pressing' means in this context (simulation vs. actual input), what happens after key press, error conditions, or typical use cases. The description leaves too many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, with no additional value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Press') and target ('a key or key combination'), making the purpose immediately understandable. It distinguishes from siblings like 'click' or 'mouse' by focusing on keyboard input rather than mouse actions. However, it doesn't explicitly differentiate from all possible keyboard-related tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when keyboard input is preferred over other input methods (like 'fill' for text entry or 'click' for button activation), nor does it specify prerequisites or context for effective use.
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. While 'Perform mouse actions' implies interaction with the UI, it doesn't specify whether this requires focus on a specific window/tab, potential side effects (e.g., triggering events), or error conditions. The description is too vague for a tool that manipulates user interface elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mouse interaction tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, coordinate systems, or how it integrates with sibling tools (e.g., 'click' vs. 'mouse' with action='click'), leaving critical gaps 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, providing a solid baseline. The description adds minimal value beyond the schema—it mentions 'specific coordinates' (implied by x and y parameters) and 'mouse actions' (implied by the action parameter), but doesn't clarify coordinate systems (e.g., screen vs. viewport), action sequences, or tab context. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Perform mouse actions at specific coordinates' clearly states the verb ('perform mouse actions') and resource ('at specific coordinates'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'click' or 'hover', which also involve mouse interactions, leaving some ambiguity about its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'click' or 'hover'. It lacks context about scenarios where this tool is preferred, 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.
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. 'Navigate to a URL in the browser' implies a navigation action but doesn't describe what happens after navigation (does it wait for page load?), whether it opens new tabs, what happens on errors, or any side effects. This leaves significant behavioral gaps for a navigation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a navigation tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after navigation completes, what the tool returns, error conditions, or how it interacts with the browser context. Given the complexity and lack of structured metadata, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Navigate to') and resource ('a URL in the browser'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'reload', 'go_back', or 'go_forward' which are also navigation-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'reload', 'go_back', 'go_forward', and 'wait_for_navigation', there's no indication of when navigation is preferred over these other options or what the prerequisites might be.
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 mentions 'Get information' but does not specify what type of information (e.g., text, attributes, position), whether it's read-only, potential errors (e.g., if selector not found), or interaction effects. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded and appropriately sized, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with web elements, the lack of annotations and output schema means the description should do more to explain behavior, return values, and error handling. It fails to provide sufficient context for effective use, especially compared to sibling tools in a browser automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('selector' and 'tabId') well-documented in the schema. The description adds no additional meaning beyond the schema, such as examples or constraints, so it meets the baseline for adequate but not enhanced parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get information') and resource ('an element matching a CSS selector'), making it easy to understand what the tool does. However, it does not explicitly differentiate from sibling tools like 'get_content' or 'select', which might have overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_content' for broader content retrieval or 'select' for element interaction. It lacks context about prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving usage unclear.
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. 'Reload' implies a page refresh, but it doesn't disclose behavioral traits like whether it waits for page load, handles authentication persistence, affects browser state, or has side effects. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple action, avoiding unnecessary elaboration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'reload' entails operationally, success/failure conditions, or interaction with browser state. For a tool with parameters and no structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds no parameter semantics beyond the schema. With moderate coverage, the baseline is 3, as the schema documents 'waitUntil' enum values, 'timeout' range/meaning, and 'tabId' default behavior, but the description doesn't enhance this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reload the current page' clearly states the action (reload) and target (current page) with a specific verb+resource. It distinguishes from siblings like 'navigate' (loads a new URL) or 'go_back' (navigates back), but doesn't explicitly contrast with them. The purpose is unambiguous but could be more differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like refreshing content after dynamic updates, handling stale pages, or when to prefer 'navigate' to the same URL. With many browser interaction siblings, explicit usage context is missing.
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 states what the tool does but doesn't describe important behavioral aspects like whether scrolling is immediate or animated, what happens if the selector doesn't exist, whether it waits for page load, or what the return value is. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loaded with the core functionality. Every word serves a purpose: 'scroll' defines the action, 'the page or a specific element' defines the scope. There's zero wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the tool's behavior in different scenarios, error conditions, or what constitutes successful execution. The minimal description leaves too many operational questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions scrolling 'the page or a specific element' which hints at the 'selector' parameter's purpose, but doesn't add meaningful semantics beyond what the 80% schema coverage already provides. The schema descriptions adequately explain each parameter's function, so the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scroll') and specifies what can be scrolled ('the page or a specific element'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'navigate' or 'go_back' which involve page movement but not scrolling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when scrolling is appropriate compared to navigation tools, nor does it specify prerequisites like needing an active page or tab context.
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 full burden but offers minimal behavioral insight. It mentions the action but doesn't disclose whether this requires the element to be in a particular state (visible, enabled), what happens with invalid selectors/values, or if it waits for page updates. This leaves significant gaps for a mutation tool interacting with web elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward tool and front-loads the essential information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or behavioral nuances (like multi-select support implied by 'option(s)'). Given the complexity of web automation and lack of structured data, more context is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description adds no additional parameter semantics beyond what's in the schema (e.g., explaining what 'values' represents or selector syntax). This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Select option(s)') and target ('from a dropdown/select element'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar siblings like 'click' or 'fill' that might also interact with form elements, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'click' for buttons or 'fill' for text inputs. It doesn't mention prerequisites (e.g., needing the element to be visible) or exclusions (e.g., not working on non-select elements), leaving the agent with minimal context 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?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states the action is 'set' (implying mutation) but doesn't cover permission requirements, side effects (e.g., whether cookies persist across sessions), error conditions, or what happens if cookies already exist. This leaves significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is 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 with the core action and resource, making it immediately scannable. Every word earns its place by conveying essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and moderate schema coverage, the description is inadequate. It doesn't address behavioral aspects like side effects, error handling, or success indicators. Given the complexity of cookie management (multiple attributes, browser context), more context is needed to help an agent use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'expires' and 'tabId' have descriptions). The description adds no parameter-specific information beyond implying cookies are set. It doesn't explain the structure of the cookies array, required vs optional fields, or the meaning of cookie attributes like 'sameSite' or 'httpOnly'. The baseline 3 reflects that schema coverage is moderate but description adds little compensatory value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set cookies in the browser' clearly states the action (set) and target resource (cookies in browser), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'delete_cookies' beyond the verb, missing explicit contrast between setting and deleting operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an active browser session), contrast with 'get_cookies' for reading cookies, or specify scenarios where setting cookies is appropriate versus other browser automation tools.
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 mentions waiting for navigation but does not disclose behavioral traits such as what happens on timeout (e.g., error thrown), whether it blocks until navigation completes, or if it works with page loads versus single-page app transitions. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is 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 unnecessary words. It is front-loaded and efficient, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and incomplete parameter coverage (67%), the description is inadequate. It lacks details on return values, error handling, and behavioral nuances, making it insufficient for an agent to fully understand how to invoke and interpret results from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 out of 3 parameters have descriptions), and the description adds no additional parameter semantics beyond what the schema provides. It does not explain the meaning of 'waitUntil' options or when to use 'tabId', so it meets the baseline for moderate schema coverage without compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wait for the page to navigate') and the target ('to a new URL'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'wait' or 'wait_for_selector', which handle different waiting scenarios, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios like after clicking a link or submitting a form, nor does it reference sibling tools such as 'wait' (general wait) or 'wait_for_selector' (wait for an element), leaving the agent without context for 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?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't mention what happens on timeout, whether it blocks execution, error conditions, or interaction with page state. This is inadequate for a tool that likely involves asynchronous operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently communicates the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error behavior, or interaction with other tools like 'query_selector'. The agent lacks context about what 'appear in the page' means operationally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional semantic context beyond implying the tool operates on a page, which is minimal value. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('wait for') and resource ('element matching the selector'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'wait' or 'wait_for_navigation', which could cause confusion about when to choose this specific waiting tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'wait' or 'wait_for_navigation'. The description only states what it does without context about appropriate scenarios or prerequisites, leaving the agent to infer usage.
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 states the tool changes the active tab but does not disclose behavioral traits such as whether it requires specific permissions, if it affects browser state irreversibly, potential errors (e.g., invalid tab ID), or side effects. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action and outcome. Every word earns its place, with no redundant or vague phrasing, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral transparency, usage guidelines, and error handling, which are crucial for an agent to invoke it correctly in a browser automation context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'tabId' parameter. The description does not add any meaning beyond what the schema provides (e.g., format examples, source of tab IDs, or constraints), resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Switch to a different tab') and the resource ('tab'), distinguishing it from siblings like 'list_tabs' (which lists tabs) and 'new_tab' (which creates tabs). It also specifies the outcome ('making it the active tab for subsequent operations'), which adds clarity beyond just the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing tab ID from 'list_tabs'), exclusions, or comparisons to similar tools like 'focus' or 'navigate', leaving usage context unclear.
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 mentions execution in the browser context and returning a result, but lacks details on error handling, execution timeouts, security implications, or whether it requires specific browser permissions. This is a significant gap for a tool that executes arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Execute JavaScript code') and includes essential context and outcome. There is no wasted verbiage, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing JavaScript in a browser, the lack of annotations, and no output schema, the description is incomplete. It does not cover critical aspects like error responses, return value formats, or safety considerations, leaving gaps that could hinder effective tool use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('script' and 'tabId') with clear descriptions. The description does not add any additional meaning beyond what the schema provides, such as examples of valid JavaScript code or details on how 'tabId' interacts with browser tabs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute JavaScript code') and the context ('in the browser context'), distinguishing it from sibling tools that perform different browser automation tasks like clicking, navigating, or taking screenshots. It explicitly mentions the return value ('and return the result'), which is crucial for understanding its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing JavaScript in a browser, but it does not explicitly state when to use this tool versus alternatives like 'query_selector' for DOM queries or 'get_content' for content extraction. No guidance is provided on prerequisites, such as requiring an active browser session or specific permissions.
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 full burden for behavioral disclosure. While 'Navigate back' implies a navigation action, it doesn't specify what happens on success/failure, whether it waits for page load, or if it requires specific browser state. The description lacks crucial behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is 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 with the core action and resource, making it immediately understandable. Every word earns its place in conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a navigation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like error conditions, success indicators, or interaction with browser state. The minimal description leaves too many contextual gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema description coverage (2 of 3 parameters documented) and 0 required parameters, the description adds value by implying the core navigation behavior. However, it doesn't explain parameter purposes like 'waitUntil' options or 'tabId' usage, leaving some semantic gaps despite decent schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Navigate back') and resource ('browser history'), distinguishing it from sibling tools like 'go_forward' (forward navigation) and 'reload' (page refresh). It uses precise terminology that directly communicates 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'go_forward', 'reload', or 'navigate'. It doesn't mention prerequisites (e.g., requiring browser context or existing history) or typical use cases (e.g., after clicking links).
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 full burden for behavioral disclosure. It states the action but doesn't mention what happens if no forward history exists, whether it waits for page load, or what the expected outcome is. The description lacks crucial behavioral context for a navigation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple navigation operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a browser navigation tool with no annotations, no output schema, and 3 parameters (even if optional), the description is insufficient. It doesn't explain what happens on success/failure, what the return value might be, or important behavioral constraints. The description leaves too many contextual gaps for proper agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 parameters have descriptions). The description adds no parameter-specific information beyond what the schema provides. However, with 0 required parameters and relatively complete schema documentation, the baseline is high. The description doesn't compensate for the 33% gap but doesn't need to heavily given the optional nature of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate forward in browser history' clearly states the specific action (navigate forward) and resource (browser history). It distinguishes from sibling tools like 'go_back' (backward navigation) and 'navigate' (new URL navigation), providing precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., having forward history available), exclusions, or compare with similar tools like 'go_back' or 'reload'. Usage is implied but not explicitly defined.
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 full burden but offers minimal behavioral disclosure. It mentions capturing 'page or a specific element' but doesn't describe what happens (e.g., returns image data, saves to file, requires permissions, has visual rendering delays, or affects browser state). For a tool with 8 parameters and no annotation coverage, this leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately communicates the core function. Every word earns its place with no redundancy or unnecessary elaboration. It's perfectly front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex screenshot tool with 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (image data format, file location, etc.), performance characteristics, error conditions, or how it interacts with the browser context. The agent lacks crucial information to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 88%, providing good documentation for most parameters. The description adds minimal value beyond the schema - it hints at the 'selector' parameter's behavior ('screenshots viewport if not specified') but this is already covered in the schema. With high schema coverage, the baseline of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('capture a screenshot') and the target ('page or a specific element'), distinguishing it from all sibling tools which perform different browser automation functions like navigation, interaction, or content extraction. It uses precise language that immediately communicates 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need visual capture of a webpage or element) but provides no explicit guidance on when to choose this over alternatives like 'pdf' (which captures as PDF) or 'get_content' (which extracts text/HTML). There's no mention of prerequisites or limitations, leaving the agent to infer appropriate usage scenarios.
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 full burden but only states what the tool returns (IDs, URLs, titles) without disclosing behavioral traits like whether it lists tabs across all windows, if it requires specific permissions, how it handles private/incognito tabs, or what format the output takes. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all open browser tabs') followed by the return details. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately covers the basic purpose but lacks completeness regarding behavioral context (e.g., scope, permissions, output format). Given the sibling tools involve browser interactions, more context about tab enumeration behavior would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing non-existent parameters, maintaining focus on the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all open browser tabs') and resources involved ('with their IDs, URLs, and titles'). It distinguishes itself from siblings like 'get_content' or 'query_selector' by focusing on tab enumeration rather than content extraction or DOM querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to enumerate tabs, but provides no explicit guidance on when to use this versus alternatives like 'switch_tab' (for navigation) or 'new_tab' (for creation). It lacks explicit when-not-to-use statements or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavioral trait of waiting for a specified time, but it does not mention potential side effects like blocking execution, thread behavior, or error handling. It adds basic context but lacks depth for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given 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, no output schema, no annotations), the description is minimally complete. It explains what the tool does but does not address potential issues like maximum wait times or interaction with other tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'ms' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as usage examples or edge cases, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('wait') and resource ('milliseconds'), and it distinguishes itself from siblings like 'wait_for_navigation' and 'wait_for_selector' by focusing on a simple time delay rather than event-based waiting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for timing delays, but it does not explicitly state when to use this tool versus alternatives like 'wait_for_navigation' or 'wait_for_selector'. It provides clear context for a basic wait but lacks explicit exclusions or comparisons.
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. It discloses the tool's behavior (closing tabs, defaulting to active tab) but lacks details on permissions needed, whether the action is reversible, potential side effects (e.g., losing unsaved data), or error handling. It adds basic context but misses deeper behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds conditional behavior in the second. Every sentence earns its place with no wasted words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive action with one parameter) and no annotations or output schema, the description is minimally adequate. It covers the basic operation but lacks information on return values, error cases, or integration with sibling tools, leaving gaps for an AI agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'tabId' parameter. The description adds value by explaining the default behavior (closes active tab if not specified), which clarifies semantics beyond the schema's technical details. However, it does not elaborate on parameter format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close a browser tab') and the resource ('browser tab'), distinguishing it from siblings like 'list_tabs', 'new_tab', or 'switch_tab'. It precisely defines the verb and target, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it (to close a tab) and specifies behavior based on parameter presence (closes active tab if no tabId). However, it does not explicitly state when not to use it or mention alternatives like 'switch_tab' for changing tabs without closing, which could help differentiate usage 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?
With no annotations provided, the description carries full burden and adds valuable behavioral context beyond the basic action: it specifies that the new tab becomes active (important UI state information) and that URL navigation is optional. However, it doesn't mention potential side effects like browser focus changes or tab management 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: first states core functionality with optional parameter, second adds crucial behavioral detail. Every word earns its place, and the most important information (opening new tab) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no annotations and no output schema, the description is reasonably complete: it explains what the tool does, the optional parameter, and key behavioral outcome. However, it could mention what happens if no URL is provided (opens blank tab) for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single optional 'url' parameter. The description adds marginal value by mentioning 'optionally navigating to a URL' but doesn't provide additional semantic context beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Open') and resource ('a new browser tab'), with specific scope ('optionally navigating to a URL') and behavioral detail ('The new tab becomes active'). It distinguishes from siblings like 'navigate' (which changes current tab) and 'switch_tab' (which activates existing tab).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to open new tabs, optionally with URL navigation), but doesn't explicitly state when not to use it or name specific alternatives. It implies differentiation from 'navigate' (changes current tab) and 'switch_tab' (activates existing tab), but 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.

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:

[![puppeteer-mcp MCP server](https://glama.ai/mcp/servers/andytango/puppeteer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/andytango/puppeteer-mcp)

Score Badge

Copy to your README.md:

[![puppeteer-mcp MCP server](https://glama.ai/mcp/servers/andytango/puppeteer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/andytango/puppeteer-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/andytango/puppeteer-mcp'

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