Camoufox Playwright MCP

by chandu-cpz

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but 'browser_snapshot' and 'browser_take_screenshot' could confuse agents as both capture page state, and 'browser_type' vs 'browser_fill_form' overlap slightly. Descriptions help differentiate them.
Naming Consistency5/5
All tools follow a consistent 'browser_<action_or_noun>' pattern using lowercase with underscores. The naming is predictable and uniform, making it easy for agents to infer tool function from the name.
Tool Count5/5
24 tools is well-scoped for a browser automation server, covering navigation, interaction, forms, dialogs, console, network, tabs, and more. Each tool addresses a distinct operation without being excessive.
Completeness4/5
The tool set covers most common browser automation operations (CRUD-like for page interactions), but lacks a forward navigation tool and explicit waiting for elements beyond text. These minor gaps are workable.
Average 2.9/5 across 24 of 24 tools scored. Lowest: 1.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context (e.g., what happens when a dialog is handled, or that it may dismiss browser prompts). With annotations present, the description still fails to add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is not appropriately sized since it conveys no useful information. It is under-specification rather than concise, and provides no front-loaded key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that handles browser dialogs (which can be alert, confirm, or prompt), the description is completely inadequate. It lacks any explanation of behavior, return values, or how parameters relate to dialog types. No output schema is provided to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (accept, promptText, _meta). The meaning of 'accept' as boolean and 'promptText' as optional string is left entirely to the agent to infer from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like browser_click, browser_fill_form, or browser_press_key. There is no context about dialog types or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not explain what resizing entails (e.g., viewport changes, side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is too brief and redundant with the title. It does not earn its place as it adds no new 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 tool with 2 required parameters and no output schema, the description should provide context on units, side effects, or behavior. It does not, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters (width, height). It does not specify units, valid ranges, or the meaning of _meta. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resize the browser window' is a direct restatement of the tool name and title. It does not add any specificity or detail, making it a tautology.
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 context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description need not restate that clicking modifies state. However, it adds no additional behavioral context such as possible navigations, event triggers, or prerequisites (e.g., page must be loaded). The description is essentially a restatement of the title, providing no value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short (one sentence), it is under-specified rather than concise. It omits critical parameter and behavioral information, and every sentence should earn its place; this one adds almost no value beyond the tool name and title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (1 required) and no output schema, the description is severely incomplete. It provides no information on parameter usage, return values, or side effects. For an interactive browser tool, this level of documentation is insufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the JSON schema provides no documentation for any of the 6 parameters. The description fails entirely to explain what 'target', 'button', 'modifiers', 'doubleClick', or 'element' mean or how they affect the click behavior. An agent has no guidance on how to populate parameters correctly.
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 states 'Perform click on a web page', which clearly identifies the action (click) and the resource (web page). However, it does not differentiate this tool from sibling tools like browser_hover or browser_press_key, which have similar purposes. The name alone conveys the core action, but the description adds no distinguishing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 click versus alternatives like hover, press_key, or drag. With 23 sibling tools including many interaction tools, the absence of usage context makes it hard for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral traits beyond what annotations already provide (destructiveHint=true, readOnlyHint=false, openWorldHint=true). It does not explain what 'upload' means in a browser context (e.g., whether it triggers a network request, requires a specific page element, or has side effects). With no output schema and minimal description, the agent is left guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words), but this brevity comes at the cost of essential information. It is under-specified rather than concise. A better description would include parameter hints or usage context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive, open-world, 2 parameters no schema descriptions, no output schema), the description is woefully incomplete. It fails to explain how to use the 'paths' parameter, what the tool does in the browser, or what the result will be. An agent cannot reliably invoke this tool based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the two parameters ('_meta' and 'paths') at all. With 0% schema description coverage, the description must compensate, but it only repeats the overall purpose. An agent cannot infer what 'paths' expects (local file paths, URLs, or something else) or what '_meta' is for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Upload one or multiple files' uses a specific verb ('upload') and resource ('files'), and clearly distinguishes this tool from siblings like 'browser_navigate' or 'browser_click' which have no upload capability. The addition of 'one or multiple' adds specificity beyond the title.
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, what prerequisites are needed (e.g., a file input element on the page), or any alternatives. Without such context, an agent may misuse it in situations where upload is not applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description carries a lower burden. However, it adds no behavioral context beyond the name—e.g., whether fields are validated, what happens when a field is missing, or if the form submits automatically. This is insufficient for a mutation tool with side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At 4 words, the description is extremely short but under-specified for a tool with complex nested parameters. It sacrifices necessary information for brevity, making it more deficient than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, one a nested array of objects with 4 fields) and absence of an output schema, the description must provide more context. It fails to mention return values, error handling, or prerequisites (e.g., form must be visible). The description is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate for parameter meanings. The description offers no details about the 'fields' array, its required properties (name, target, type, value), or how to specify values. The agent must infer semantics from the schema alone, which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' clearly states the action (fill) and resource (form fields), implying batch operation. However, it does not differentiate from sibling tools like browser_type (single field) or browser_select_option, and the title 'Fill form' is redundant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_type for individual fields or browser_select_option for dropdowns. The description lacks any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set 'destructiveHint: true' and 'openWorldHint: true', which signal that this operation can change state (navigate away) and may open external sites. The description does not add any behavioral context beyond what annotations provide—it does not mention page load behavior, error handling, or impact on the current page state. With annotations covering the core behavioral hints, a 3 is appropriate (adds no extra value).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than concise. It fails to provide necessary details about behavior, parameters, or sibling differentiation. Every sentence should earn its place; one tautological sentence does not justify its existence.
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 that there are 22 sibling tools, no output schema, and only 50% parameter description coverage, the description is inadequate. The agent lacks information about navigation behavior, error states, return values, and how this tool fits into the browser automation workflow. A more complete description would mention page-load completion, redirect handling, or domain restrictions.
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 'url' is described). The description does not elaborate on the 'url' parameter's format (e.g., must include scheme, relative vs absolute) nor explain the optional '_meta' field's purpose. Since coverage is moderate (50%), the description adds minimal value beyond the schema, and the baseline starts at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
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. There is no mention of prerequisites (e.g., an active browser tab), no indication of when to prefer 'browser_navigate_back' or other navigation tools, and no exclusion cases. The agent receives zero contextual help for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows it is a mutating action. However, the description adds no extra behavioral context, such as whether keyboard shortcuts are supported, how it interacts with page focus, or that pressing certain keys (e.g., Alt+F4) could close the browser.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified. It does not add meaningful information beyond the title, making it more of a restatement than a useful 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?
Given the tool's simplicity, this is a minimal description, but with many sibling tools and no output schema, the agent needs more context about when to press a key, what key formats are accepted, and potential side effects. The current description is insufficient for reliable selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'key' parameter. There are no enums or format hints, so the agent has no guidance on what values to use (e.g., 'Enter', 'a', 'ArrowUp'). The description completely fails to compensate for the lack of schema 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 'Press a key on the keyboard' uses a specific verb and resource, clearly distinguishing it from sibling tools like browser_type (which types text) and browser_click (which uses the mouse). It is slightly terse but unambiguous about the core action.
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?
There is no guidance on when to use this tool versus alternatives. For instance, it does not clarify whether this should be used for individual key presses while browser_type is for text entry, nor does it mention any prerequisites like element focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral fact that it captures an accessibility snapshot, which is consistent with the annotations. No additional behavioral traits (e.g., side effects, return format) are disclosed beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but omits essential information. It is concise at the expense of completeness, making it under-specified. Every sentence should earn its place, but this sentence does not provide enough value for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no parameter descriptions, the description is woefully incomplete. It does not explain what the tool returns, how to use the parameters, or any behavioral details. The annotations are present but insufficient on their own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero information about the five parameters (_meta, boxes, depth, target, filename). The agent has no indication of what each parameter controls, making it impossible to use the tool correctly. The description fails to compensate for the lack of schema 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 uses a clear verb 'Capture' and specifies the resource as 'accessibility snapshot', distinguishing it from the sibling tool 'browser_take_screenshot' by claiming it's better. However, the term 'accessibility snapshot' is vague and not defined, leaving some ambiguity about what exactly is captured.
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 weakly implies usage via 'better than screenshot' but provides no explicit guidance on when to use this tool versus alternatives like browser_evaluate or browser_console_messages. There is no mention of prerequisites, prohibitions, or specific 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?
Annotations already mark the tool as read-only and non-destructive. The description mentions waiting for time to pass but does not disclose polling behavior, timeout semantics, error handling (e.g., what happens if text never appears), or whether the operation blocks. These are critical behavioral gaps beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. For a tool with four parameters and multiple wait conditions, the description should be structured to list options, defaults, or constraints. The current brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and 4 parameters with 0% schema coverage. The description does not explain return values, side effects (even though it's read-only, agents need to know what happens), or confirmation of wait success versus timeout. This leaves significant gaps for an agent to use the tool correctly.
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?
Schema coverage is 0%, so the description must carry the full burden for parameters. It mentions 'text to appear or disappear or a specified time to pass', which hints at text, textGone, and time parameters, but gives no details on syntax, precedence, mutual exclusivity, or the _meta parameter. The description is too vague to help an agent correctly set parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for text to appear, disappear, or a time to pass. The verb 'Wait for' and the three conditions are specific, but it does not differentiate this tool from siblings like browser_find or browser_snapshot, which also interact with page content.
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. For instance, there is no mention of using browser_find to check for text before waiting, or how this tool relates to browser_snapshot for reading page state. The description lacks any when-to or when-not-to instructions.
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 destructiveHint=true already signaling destructive behavior, the description adds no additional context about what actually gets closed—whether it closes all pages, terminates the browser session, or has irreversible effects. The page vs. browser ambiguity further obscures behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it highly concise and front-loaded. However, its brevity contributes to ambiguity, so while structurally concise, it sacrifices clarity.
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?
The tool's scope (browser vs. page) is unresolved, and there is no mention of what happens to open tabs, whether the action is reversible, or what the expected outcome is. Given the tool's simplicity, a clearer statement about closing the entire browser instance would make it complete.
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 only parameter is an optional _meta object with no functional significance, so the schema already covers the parameter surface. The description adds nothing about parameters, but that is acceptable since there are no meaningful parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the page' conflicts with the tool name 'browser_close' and title 'Close browser', creating ambiguity about whether it closes the entire browser or just the current page/tab. This is misleading for agents that know the distinction between a page and a browser in automation contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like browser_navigate_back or browser_tabs, nor any prerequisites or side effects. Agents are left to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds nothing beyond that — it doesn't disclose return format, pagination, or whether messages are cleared after retrieval. With annotations carrying most of the burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at 3 words, which is not necessarily concise but under-specified. It lacks front-loading of critical information like filtering capability or scope. It could be shorter with clearer meaning, but it earns a 3 because it's not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no behavioral guidance, the description is incomplete for a function that returns diagnostic data. It doesn't explain return values, filtering semantics, or message lifetime. The annotations help with safety but not with completeness.
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?
Schema description coverage is 0% across 4 parameters, so the description must compensate. The description only says 'console messages' without explaining what 'level', 'filename', 'all', or '_meta' mean. It adds no meaningful behavior beyond the schema's parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns all console messages' clearly identifies the resource (console messages) but is vague because 'all' is ambiguous — it could mean all levels, all files, or all messages regardless of filtering. It doesn't specify the scope (e.g., current page, session) or differentiate from siblings.
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?
There is no guidance on when to use this tool versus alternatives. Among many browser tools, some like browser_network_requests also return diagnostic data, but no comparison or exclusions are provided. The description lacks both explicit and implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, implying mutation. The description confirms a drag-and-drop action, which is inherently mutable, but does not add context beyond annotations—e.g., it does not mention that elements might be moved, that the operation may trigger events, or that it could fail if elements are not draggable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, which is concise, but it lacks structure (no bullet points, no front-loaded key info). It is not verbose, but it also does not earn its place by adding significant value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no schema descriptions, and annotations indicating a destructive/stateful action), the description is insufficient. It does not address return values, error conditions, or how to specify elements. The agent cannot reliably invoke this tool correctly with the given information.
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?
Schema description coverage is 0%, meaning the description carries full burden for parameter meaning, but it provides none. The description does not explain what 'startTarget', 'endTarget', 'startElement', or 'endElement' are (e.g., CSS selectors, XPath, element IDs). For a tool with 5 parameters and no schema descriptions, this is a major gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Perform drag and drop between two elements', which clearly identifies the action as a drag-and-drop operation between elements. However, it does not distinguish this from the sibling 'browser_drop' tool; the name 'browser_drop' already implies a drop action, and the description here adds no 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?
No guidance is provided on when to use this tool versus alternatives like 'browser_drop', or on prerequisites such as the page needing to be interactive or elements needing to be selectable. The description lacks any context about required conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating mutation and destructiveness. The description adds no further behavioral context (e.g., whether prior selections are cleared, error conditions, or side effects). The agent gains no additional insight beyond what structured annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short and front-loaded, it is too minimal to be useful. It does not earn its place because it omits critical information about parameters and usage; conciseness here sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (2 required), no output schema, and annotations that signal destructiveness, the description is grossly incomplete. It fails to explain how to target the dropdown, specify options, or interpret results, leaving the agent without sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – no parameter descriptions exist in the input schema. The tool description ('Select an option in a dropdown') provides zero explanation of what 'target', 'values', or 'element' mean or how to use them. The description fails to compensate for the absent schema semantics, leaving the agent completely uninformed about parameter usage.
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 'Select an option in a dropdown' uses a specific verb ('Select') and resource ('dropdown'), clearly distinguishing it from sibling tools like browser_click or browser_fill_form. It explicitly states the action and target element type.
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 (e.g., browser_click, browser_fill_form), nor does it state any prerequisites or exclusions. The agent is left to infer usage context 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?
Annotations already indicate destructiveHint=true, so the agent knows closing tabs is destructive. However, the description adds no further behavioral context: no mention of what happens when creating a tab (e.g., focus changes), whether selecting a tab is safe, or any side effects. With annotations present, the description's minimal contribution earns a low score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, efficiently listing the four actions. It is front-loaded and has no filler. However, it could be slightly more structured (e.g., grouping actions with their required parameters) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, 1 required, no output schema, and no parameter descriptions in the schema, the description is severely incomplete. It does not explain how to use each action, what parameters are needed, what the return value looks like (e.g., list returns tabs?), or any interaction patterns. The agent would lack essential information to invoke the tool correctly.
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?
Schema description coverage is 0%, so the description bears full responsibility for explaining parameters. It only lists the action enum values (list, new, close, select) but does not explain required parameters for each action (e.g., url for new, index for close/select, _meta). This provides minimal value beyond the schema itself.
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 states the tool manages browser tabs with four specific actions: list, create, close, or select. This clearly distinguishes it from sibling tools like browser_navigate or browser_click, which do not involve tab management. The verb+resource (manage tabs) is specific and actionable.
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 vs alternatives. For example, when to use browser_tabs with 'close' vs browser_close, or when to use 'select' vs browser_navigate. There are no exclusions, prerequisites, or contextual hints to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (modifies UI state) and openWorldHint=true (external side effects). The description adds no behavioral context beyond what annotations provide—no mention of typing speed, submission behavior, or error conditions. It neither contradicts nor significantly supplements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the key action. However, it is too brief to add sufficient value—it sacrifices completeness for conciseness, especially given the 0% parameter coverage.
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?
With 6 parameters, 0% parameter coverage, no output schema, and no sibling differentiation, the description is incomplete. It fails to inform the agent about return behavior, failure modes, or how optional parameters change behavior, leaving a large gap for a typing action.
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?
Schema description coverage is 0%, so the description must compensate entirely for parameter meaning. It only mentions typing text into an editable element, but does not explain parameters like 'slowly' (typing speed), 'submit' (auto-submit after typing), or 'element' (alternative target). The agent gets no help understanding how to use these optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Type text into editable element' is clear about the verb (Type) and resource (text into editable element). However, it does not differentiate from sibling tools like browser_fill_form or browser_press_key, which could overlap in function, so it is adequate but not distinctive.
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?
There is no guidance on when to use this tool versus alternatives such as browser_fill_form (for form-level typing) or browser_press_key (for key-level input). The description does not mention prerequisites (e.g., element must be focused) or when not to use it, limiting decision support for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true, so the description's claim of 'evaluate' is neutral and does not contradict. However, the description adds no extra behavioral context, such as the potential for side effects or security implications, which would be valuable given the destructive annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, making it extremely concise. It is front-loaded with the key action. However, the brevity is at the cost of completeness, so while structurally efficient, it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, and annotations indicating destructive and open-world behavior, the description is far too sparse. It does not explain the return value, how to use the parameters, or the execution context, leaving significant gaps for an agent to use the tool correctly.
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?
Schema description coverage is 0%, so the description must compensate. It only mentions 'expression' and 'page or element', which loosely maps to the 'function' and 'target'/'element' parameters, but fails to explain the meaning of '_meta', 'filename', or the distinction between 'target' and 'element'. This is insufficient for the five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Evaluate JavaScript expression') and the context ('on page or element'), which is specific and uses a verb-resource structure. However, it does not differentiate from the sibling tool 'browser_run_code_unsafe', which has a similar purpose, missing an opportunity to distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as 'browser_run_code_unsafe' or other browser interaction tools. There is no mention of prerequisites, limitations, or when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, indicating a mutating action with side effects. The description adds no additional behavioral context beyond a simple hover action—like what happens if the element is not found, or if hovering triggers JavaScript events. Given the annotations, a 3 is fair since the description doesn't contradict them but also doesn't enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (4 words), front-loading the action. However, it sacrifices necessary detail. For a 3-parameter tool, this is arguably under-specified rather than concise.
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 (3 params, 0% schema coverage, no output schema), the description is incomplete. It doesn't explain return values, error states, or how the parameters map to behavior. The sibling tools suggest a browser automation context, but the description fails to leverage that for clarity.
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?
Schema description coverage is 0%, so the description must compensate. But it only explains the overall action, not the two parameters (target and element). It fails to clarify what 'target' and 'element' mean individually (e.g., target might be a selector, element might be an index). The default null for element is also unexplained.
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 'Hover over element on page' uses a specific verb ('hover') and resource (element on page), clearly distinguishing it from sibling tools like browser_click, browser_drop, or browser_drag. However, it could be slightly more specific about whether it requires a CSS selector or XPath for the target.
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 vs alternatives. It doesn't explain that hovering is often a prerequisite for dropdowns or tooltips, nor does it mention that browser_click or browser_fill_form might be better for direct interaction. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true and openWorldHint=true, which signal that the tool modifies state and interacts with external resources. The description adds context by saying 'as if dragged from outside the page', explaining the simulated behavior. However, it does not disclose other behavioral traits such as side effects on the element, permissions needed, or error states. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the first sentence stating the core purpose and the second adding a key constraint. It is front-loaded and avoids unnecessary words. However, it could be slightly more structured (e.g., listing parameters), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, destructive behavior, no output schema, and zero schema descriptions, the description is insufficient. It does not explain how to use the parameters (e.g., how to specify 'target'), what the return value is, or prerequisites like the element being present. It only distinguishes from siblings via the 'outside the page' phrase. More detail is needed for a complete understanding.
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?
The schema description coverage is 0%, meaning the description must compensate, but it only mentions two of five parameters ('paths' and 'data') without explaining their types or formats. The other parameters ('target', 'element', '_meta') are not described at all. 'target' is required but its meaning (e.g., CSS selector) is not clarified. The description adds minimal value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (drop), the resource (files or MIME-typed data), and the target (an element). It distinguishes from siblings like 'browser_drag' by specifying 'as if dragged from outside the page', and from 'browser_file_upload' by emphasizing MIME-typed data. The constraint 'at least one of paths or data' further clarifies the purpose.
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 provides implicit guidance by stating 'as if dragged from outside the page', which hints at when to use this tool (external drag-and-drop) versus internal drag (browser_drag). However, it does not explicitly state when not to use it or mention alternatives like browser_file_upload. The constraint about requiring paths or data is helpful but not a full usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true and readOnlyHint=false, indicating this is a mutation that may cause side effects (e.g., losing current page state). The description simply restates the action without adding behavioral context (e.g., what happens to form inputs, whether it triggers reload, or if it fails without history). With annotations covering the safety profile, the description adds no significant extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the tool's purpose without any padding. Every word earns its place—'Go back' and 'previous page in the history' are precise and sufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with no required parameters, no output schema, and annotations that clarify its destructive nature, the description is complete. The agent can understand what the tool does and infer its effects. No additional details (e.g., return behavior or failure modes) are necessary given the tool's simplicity.
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 only parameter is _meta (common metadata), which has no description in the schema (0% coverage). The parameter is universal and typically used for tracing, so omitting its explanation in the description is acceptable. The description does not need to elaborate on _meta because it is a standard parameter with well-understood semantics.
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 'Go back to the previous page in the history' uses a specific verb ('Go back') and resource ('previous page in the history'), clearly distinguishing it from sibling tools like browser_navigate (which goes to a URL) and browser_click (which interacts with page elements).
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 browser_navigate (forward navigation) or browser_wait_for. The agent receives no context about prerequisites (e.g., requires history), no explicit 'when not to use' advice, and no differentiation from other navigation-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint as false, so the behavioral safety profile is covered. The description adds the ability to retrieve partial data via the 'part' parameter, which is useful context beyond annotations but does not disclose error behavior or format of the response.
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 sentences: the first states the core function, the second provides a critical usage hint. Every sentence serves a purpose with no wasted words. Front-loaded with the primary behavior.
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?
No output schema exists, so the description must convey what is returned. It mentions 'headers and body' but does not specify the structure or provide details on error cases (e.g., invalid index). Adequate for a simple tool but leaves the output format ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75% per context), so baseline is 3. The description adds context for the 'index' parameter by linking it to browser_network_requests, which is not in the schema. Other parameters like 'part' and 'filename' are already well-described in the schema, so minimal additional value.
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?
Clearly states it returns full details (headers and body) of a single network request, or a part if 'part' is set. Distinguishes from sibling 'browser_network_requests' by specifying it operates on a single request selected by index.
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?
Explicitly instructs to use the index from browser_network_requests, establishing a clear usage sequence. Does not explicitly mention when not to use it or alternatives, but the dependency is clear and sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the critical behavioral trait that screenshots cannot be used for actions (unlike browser_snapshot). It does not contradict annotations, but could mention file saving or return format.
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 sentences, front-loaded with the essential purpose, and every word adds value. No redundancy or wasted text.
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?
Despite good purpose/guidelines, the description lacks parameter explanations and does not describe the output (e.g., image format, where it is stored). For a tool with 7 undocumented parameters and no output schema, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description omits any explanation of the 7 parameters (type, scale, target, element, filename, fullPage, _meta), leaving the agent to guess their meaning and effect.
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 takes a screenshot of the current page and explicitly contrasts itself with browser_snapshot, making the unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It not only says what the tool does but also warns against using it for actions and directs to browser_snapshot instead, providing explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Unsafe: executes arbitrary Python... RCE-equivalent', which goes well beyond the annotations (destructiveHint: true) to explain the severity and attack surface. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action then the critical safety caveat. Efficient and clear, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and schema that handle parameters, the description adequately covers purpose and safety. However, lacking output schema or return value info, and sibling differentiation is missing, but overall complete for the tool's risk profile.
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%, so the schema partially documents parameters. The description adds no parameter-specific details; it only repeats 'Python Playwright code' from the schema's code parameter description. Minimal added value.
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 runs Python Playwright code snippets and is uniquely identified as 'unsafe'. The verb 'run' plus 'Playwright code' makes the resource and action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over siblings like browser_evaluate. The safety warning implies restricted use cases but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and destructiveHint: false, so the tool's safety profile is clear. The description adds valuable behavioral detail: it returns 'matching snapshot nodes with a few lines of surrounding context (like search snippets)', which is not obvious from annotations alone. This goes beyond the annotation data and helps the agent understand the return format.
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, well-structured sentence. It is front-loaded with the core purpose ('Search the accessibility snapshot') and efficiently adds return format and cost context in the same sentence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool has no required parameters, no output schema, and relatively low complexity, the description is fairly complete. It explains what it does, what it returns, and the trade-off vs. browser_snapshot. A slight gap is the lack of mention that text and regex might be mutually exclusive, and no example of the return format. But overall, for a non-complex tool, it covers the essentials well.
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 0%, so the description must compensate. It does mention that the tool searches for 'text or a regular expression', which semantically covers the 'text' and 'regex' parameters. However, it does not explain the '_meta' parameter at all, nor does it specify how to choose between text and regex (e.g., mutual exclusivity). With 3 parameters and some coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb ('Search'), the resource ('accessibility snapshot of the current page'), and the query types ('text or a regular expression'). It clearly distinguishes this tool from siblings by focusing on search within the snapshot for element location, as opposed to browser_snapshot which captures the whole snapshot.
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 use: when you need to locate an element and its ref, and contrasts it with capturing the whole snapshot, offering a cost-benefit argument ('cheaper'). However, it does not explicitly state when NOT to use it (e.g., when you need the entire snapshot structure) or list alternative sibling tools by name, though the contrast with 'whole snapshot' implicitly references browser_snapshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the agent knows it's a safe, read-only operation. The description adds behavioral context: it returns a numbered list, it covers requests since page load, and numbers are used to retrieve details via another tool. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that clearly state the purpose and a usage hint. Every sentence adds value, and there is no redundancy or unnecessary detail.
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?
The description explains the return value (numbered list) and how to get full details via a sibling tool. It does not specify the exact format of the list items or any limitations, but for a list tool with good schema coverage and annotations, this is sufficient. The output schema is absent, so the description carries the burden; it does so adequately.
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 (75%), with three of four parameters having descriptions. The tool description does not add any parameter information beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns a 'numbered list of network requests since loading the page.' It uses a specific verb ('returns') and resource ('network requests'), and distinguishes itself from the sibling tool 'browser_network_request' by indicating that tool is used for full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage hint: 'Use browser_network_request with the number to get full details.' This tells the agent when to switch to a sibling tool. It does not explicitly state when to use this tool vs other browser tools, but the context of siblings and the tool's purpose are clear enough.
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:

[![camoufox-playwright-mcp MCP server](https://glama.ai/mcp/servers/chandu-cpz/camoufox-playwright-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chandu-cpz/camoufox-playwright-mcp)

Score Badge

Copy to your README.md:

[![camoufox-playwright-mcp MCP server](https://glama.ai/mcp/servers/chandu-cpz/camoufox-playwright-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chandu-cpz/camoufox-playwright-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/chandu-cpz/camoufox-playwright-mcp'

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