camoufox-mcp-python

by zc-libre

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.3.0
Disambiguation5/5
Each tool targets a distinct interaction or observation (e.g., click vs. hover vs. drag, type vs. press_key vs. fill_form). The only mild overlap is between type and fill_form, but their descriptions clearly scope them to single-element vs. multi-field actions. Overall, no two tools are easily confused.
Naming Consistency4/5
All tools share the 'browser_' prefix, creating a strong family resemblance. However, the suffix pattern is mixed: some are verb-first (browser_click, browser_navigate) while others are resource-first (browser_tabs, browser_console_messages, browser_network_requests). Despite this, the prefix and clear action descriptions make the naming predictable.
Tool Count4/5
At 19 tools, the set is slightly above the typical 3-15 range but well-justified for a comprehensive browser automation server. The count covers navigation, input, observation, and tab/window management without feeling redundant. A few tools could theoretically be combined (e.g., screenshot modes), but the granularity is reasonable.
Completeness5/5
The tool surface covers the core browser automation lifecycle: navigation (navigate, back), interaction (click, hover, drag, select, type, press_key, fill_form), waiting (wait_for), and introspection (snapshot, console, network, screenshot). It also handles dialogs, file uploads, tabs, resize, and closing, leaving no obvious dead ends for standard automation scenarios. Advanced features like JS evaluation are absent but not essential for basic browser control.
Average 2.8/5 across 19 of 19 tools scored. Lowest: 1.3/5.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It fails to state whether file paths are required, what happens if no chooser is active, or whether the operation is a mutation of the browser state. This lack of transparency leaves the agent guessing about 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 brief, but it is under-specified rather than concise. A single vague sentence doesn't earn its place because it doesn't convey enough information to be useful. It is not a case of efficient clarity but of insufficient 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?
Given the tool's complexity (a file upload workflow), the lack of an output schema, and zero annotations, the description is severely incomplete. It doesn't explain the expected input, the result, or error conditions, leaving the agent with almost no basis 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?
The schema has one parameter 'paths' with 0% description coverage, and the description does not explain it. The name 'paths' hints at file paths, but the description never clarifies that they are needed for upload or how they should be formatted. This is a complete gap in parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle an active file chooser' uses a vague verb 'handle' that doesn't specify what action is performed (e.g., selecting files, uploading, canceling). It identifies the resource (active file chooser) but not the operation, making it unclear how it differs from other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, such as after a file chooser appears, or what conditions must be met. It also doesn't mention any alternatives or restrictions. The description provides no context for the agent to decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only says 'Drag from one ref to another,' revealing nothing about side effects, event triggers, or state changes. This is a significant gap for a browser interaction tool.
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, which is concise, but it under-specifies the tool's operation. It lacks necessary details about parameters and behavior, so the brevity is not valuable; it is merely incomplete.
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 four required parameters, no annotations, and no output schema, the description is severely inadequate. It does not explain what a ref is, what an element is, or the effects of the drag. The tool is essentially opaque to the agent.
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 schema has zero description coverage, and the description does not compensate. It mentions 'ref' but does not explain the distinction between startRef, endRef, startElement, and endElement. The parameter semantics remain completely undocumented.
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 the verb 'drag' and the resource 'from one ref to another,' indicating a drag operation. However, it does not explain what a 'ref' is or what the drag achieves, making the purpose vague. It does not distinguish from sibling tools like click or hover beyond the action name.
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. It does not mention scenarios for using drag over click or hover, nor any prerequisites or context. The description provides no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It only states the action with no detail on cursor movement, event triggering, or 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 terse sentence that omits essential operational details, making it under-specified rather than appropriately 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?
With no annotations, no output schema, and two parameters left unexplained, the description covers only the basic purpose and leaves 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?
The schema has 0% description coverage, and the description does not explain the 'ref' or 'element' parameters or how they relate to the hover target.
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 a specific action and target ('Hover over a web page element'), which distinguishes it from sibling actions like click or drag. However, it lacks explicit differentiation from other browser tools, so it does not fully meet the 'distinguishes from siblings' criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use hover versus click or other interactions. No alternatives or contextual triggers 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?
With no annotations, the description must disclose behavioral traits, but it only states the basic action. It does not reveal whether typing is sequential, whether it supports special keys, whether it triggers events, or what the 'submit' and 'slowly' parameters do. This is insufficient for a tool with several behavioral parameters.
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, front-loaded sentence with no waste. However, it is under-specified, lacking essential context about parameters and behavior, so while concise, it is not optimally informative for the agent.
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 5 parameters, no annotations, and no output schema, yet the description is only seven words. This is grossly inadequate for an agent to understand how to invoke the tool correctly, including required 'ref' and 'text', and optional behaviors like 'slowly' and 'submit'.
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%, so the description must explain parameters. It only mentions 'text' implicitly, but does not clarify 'ref', 'slowly', 'submit', or 'element'. The description adds almost no value over the parameter names in the schema.
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 identifies the action (Type) and the target resource (an editable element), making it easy to understand what the tool does. It distinguishes itself from siblings like browser_click or browser_navigate, though it could more explicitly differentiate from browser_fill_form or browser_press_key.
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 is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or context such as whether the element needs to be focused or visible, nor does it compare with similar browser actions like press_key or fill_form.
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 bears full responsibility for behavioral disclosure. It states only that it performs a click, but gives no details about potential navigation, waiting behavior, side effects, or how the click is executed (e.g., whether it scrolls elements into view). This minimal information does not meaningfully illuminate the tool's behavior beyond its most 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one short sentence, which is concise in length, but it is under-specified. It does not include any of the key contextual information that would make the tool usable, such as how to specify the target element or what the parameters control. This is an extreme brevity that sacrifices necessary detail, resembling the 'Process' example that scored 2 for under-specification.
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 5 parameters, no schema descriptions, no annotations, and no output schema, the description is completely inadequate. It fails to explain any parameter semantics or usage context, making it impossible for an agent to know how to correctly invoke the tool beyond the required 'ref'. The description does not fulfill the enrichment expected for a tool with this complexity.
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 input schema has no descriptions for its 5 parameters, and the tool description does not mention any of them. It provides zero guidance on what 'ref', 'element', 'button', 'modifiers', or 'doubleClick' mean or how to use them. The description does not compensate at all for the 0% schema description coverage, leaving the agent completely uninformed about 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 'Perform click on a web page' clearly identifies the action (click) and the target (web page). It distinguishes from sibling tools like browser_hover, browser_drag, and browser_type by focusing specifically on a click action. However, it does not mention that the click can target an element or include modifiers, which slightly limits clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention typical scenarios (e.g., clicking buttons, links) or related tools like browser_hover or browser_drag. The description provides no context about prerequisites or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the action without revealing whether selecting triggers events, waits for page updates, or requires the element to be focused. This leaves the agent uninformed about the tool's runtime 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is not redundant or padded. However, it is under-specified, lacking any structured detail about parameters or use cases, which would be more informative than this terse statement.
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 3 parameters, no output schema, and no annotations. The description provides no context about expected inputs, return behavior, or interaction prerequisites, making it insufficient for an agent to use the tool correctly in a browser automation workflow.
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 meaning or usage of 'ref', 'values', or 'element'. The agent must rely solely on parameter names and types, which is inadequate for constructing correctly formatted calls, especially for the 'ref' and 'element' properties.
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 function: selecting one or more dropdown values. It is specific about the action and resource, but does not differentiate it from other browser interaction tools such as browser_click or browser_type, which also manipulate 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. The description does not mention prerequisites, such as having the dropdown element visible or the page fully loaded, nor does it reference related tools like browser_click or browser_fill_form.
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 is the sole source of behavioral information, but it only states the basic action. It does not disclose side effects, how promptText interacts with dialogs, or whether the tool blocks execution until a dialog is handled, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler or repetition. It is well-structured for its brevity, but the extreme terseness contributes to under-specification, which slightly lowers the score.
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 2 parameters, lack of annotations, and absence of an output schema, the description is too minimal to be considered complete. It does not mention return values, error handling, or dialog behavior details, making it inadequate for reliable autonomous 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 'accept' or 'promptText' parameters at all. The agent must rely solely on parameter names and types, which is insufficient for understanding how to set promptText or when to use accept.
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+resource structure ('Accept or dismiss an active dialog'), making the tool's function immediately understandable. It also distinguishes itself from sibling browser tools by being the only dialog-handling tool, though it lacks detail on dialog types like alert, confirm, or prompt.
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, nor does it explain when to accept versus dismiss. There are no context clues about typical scenarios or prerequisites, leaving the agent without 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, the description carries the full burden of behavioral disclosure. It only states 'Navigate to a URL' and does not mention whether navigation waits for page load, handles errors, or affects the current tab or browsing session. This is insufficient for a browser automation tool.
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, but this is under-specification rather than appropriate conciseness. It fails to convey essential operational details, making it an incomplete specification rather than a model of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter tool but no output schema or annotations, the description should at minimum indicate the result or side effects of navigation. It lacks information about return values, waiting behavior, or interaction with the rest of the browser state, leaving the agent to guess.
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 schema has a single 'url' parameter with 0% description coverage. The description merely repeats the word 'URL' without adding details about expected format, protocols, or constraints. It provides no value beyond the parameter name.
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 to a URL' uses a specific verb (navigate) and resource (URL), clearly distinguishing it from sibling tools like browser_click or browser_navigate_back. It unambiguously states the tool's primary 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?
No guidance is provided on when to use this tool versus alternatives such as browser_navigate_back or browser_tabs. The description lacks context about typical use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It states that messages are 'collected' but does not explain what that means (e.g., from the current page, session, or history), whether the tool clears the collection, or whether it is a read-only operation. The return format is also undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It is front-loaded with the core action. However, it could be viewed as slightly under-specified for a two-parameter tool, but conciseness itself is well-executed.
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 lack of annotations and output schema, and the existence of two parameters, the description is too sparse. It misses critical context: what 'collected' means, the structure of the returned messages, and the effects of the level/filename parameters. This is a simple tool, but the description still leaves ambiguity.
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 description does not mention either parameter (level, filename). Although the schema provides enum values and defaults for both, the description adds zero explanatory value about how they filter or affect the returned console messages. With 0% schema coverage in the description, the tool description fails to compensate.
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 'Return collected console messages' clearly uses a specific verb ('return') and resource ('collected console messages'), making the tool's primary function obvious. While it doesn't explicitly distinguish itself from sibling tools like browser_network_requests, the name and phrasing make the domain unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 neither mentions usage contexts nor excludes other tools, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Press a key' without detailing key formats, special keys, modifier support, or post-press behavior. This is minimal and leaves significant unknowns for a tool that could accept complex keyboard input.
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 with no redundant words. It is front-loaded and to the point, earning a high score for conciseness, even though it could benefit from more content.
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, the description still lacks essential context: valid key formats, whether special keys are supported, or any interaction with the page. Without annotations or an output schema, the description is too sparse to be considered complete for reliable tool 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?
The schema has a single 'key' parameter with no description, and the tool description does not compensate. With schema description coverage at 0%, the description should at least explain what values 'key' accepts (e.g., 'Enter', 'a', 'Shift'), but it provides no such information, adding no semantic 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 ('Press') and the resource ('key on the keyboard'), making it easy to understand the tool's basic function. However, it doesn't differentiate from sibling tools like browser_type, which also involves keyboard input, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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_type or browser_click. The description provides no context, prerequisites, or exclusions, leaving the agent without direction on choosing between similar keyboard-related 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?
With no annotations, the description carries the full burden of disclosing behavior. It does not state whether this is a read-only operation, whether it returns the snapshot or saves it to a file (despite the optional filename parameter), or any side effects. This lack of transparency is a significant gap.
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 no wasted words. It is front-loaded with the key action and object, making it easy to parse.
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 (one optional parameter, no output schema), the description is still incomplete: it does not specify the snapshot's format, return value, file-saving behavior, or when it should be used. This leaves critical information uncovered.
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 schema has 0% description coverage, and the description does not mention the 'filename' parameter at all. The agent cannot infer its purpose or format from either source, leaving the parameter entirely 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 clearly states the action ('Capture') and resource ('current accessibility snapshot'), which distinguishes it from interaction-focused sibling tools like browser_click and browser_navigate. It is specific enough, though it does not elaborate on what an accessibility snapshot entails.
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_take_screenshot or browser_console_messages. There is no mention of preferred scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It names actions but fails to disclose side effects (e.g., close is irreversible, select changes current tab) or that the action enum uses 'new' instead of the described 'create'. Minimal transparency beyond the obvious.
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 with zero filler. Every word adds meaning, and it's appropriately sized for a tool with a small, enum-driven schema.
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 2 parameters, no output schema, and multiple mutation actions, the description is too terse. It doesn't explain what 'list' returns, what 'new' creates (URL?), or how index selects a tab. An agent would still need to infer crucial behavior.
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 coverage is 0%. The description doesn't mention the 'index' parameter or how it applies to actions like select/close. The 'create' wording conflicts with the enum value 'new', adding confusion rather than clarifying parameter 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 uses specific verbs (list, create, close, select) plus the resource 'browser tab', clearly distinguishing it from sibling tools like browser_click or browser_navigate. It captures the tool's full scope in a single sentence.
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 gives no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where browser_navigate or browser_close might be more appropriate, nor any prerequisites 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'List' without explaining output format, filtering behavior, or the effect of the includeStatic parameter. The description does not disclose whether this is a safe read-only operation or how it handles static resources by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core purpose. No wasted words, though it is under-specified in other dimensions.
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 no annotations, no output schema, and zero parameter descriptions, the description is far from complete for an agent to invoke the tool correctly. It explains neither the return value nor the purpose of the filename parameter, leaving essential context missing.
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 coverage is 0%, and the description provides no information about the two parameters, filename and includeStatic. The purpose of 'filename' is completely ambiguous, and the description adds no semantic value beyond the raw parameter names and defaults in the schema.
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 'List' and the resource 'network requests seen by the page'. It distinguishes the tool from siblings like browser_console_messages and browser_tabs by focusing specifically on network activity.
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 network requests need to be inspected, but provides no explicit guidance about when to use this tool versus alternatives like browser_console_messages. No exclusions or alternative suggestions 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 description clearly states the primary effect (resize viewport), but does not disclose potential side effects such as layout reflow or persistence across navigation. With no annotations, this is a minimal but not misleading statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. Perfectly concise for the tool's simplicity.
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?
Missing context around return values, side effects, or parameter semantics. For a tool with no annotations and no output schema, the description carries a heavier burden and falls short.
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 compensate by explaining parameter units, constraints, or expected values. The parameter names are self-explanatory, but the description adds no additional meaning.
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 'Resize the current page viewport' is a specific verb+resource statement that clearly distinguishes this tool from sibling browser tools like navigation, clicking, or screenshots.
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, nor are any prerequisites or exclusions 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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core action but omits critical behavioral traits: timeout behavior, what happens on failure, whether the wait is poll-based, how parameters combine, and default behavior when no arguments are provided. The lack of such details means an agent cannot anticipate outcomes reliably.
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, focused sentence with no filler. It conveys the essential purpose in 12 words, making it easy to parse quickly. 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 the tool has three optional parameters, no annotations, no output schema, and no parameter descriptions in the schema, the description is too sparse to be fully actionable. It omits crucial details like timeout handling, default waits, and parameter interaction rules. For an AI agent to invoke this reliably, 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?
The schema has 0% coverage for parameter descriptions, so the description must compensate. It does partially: 'text' implies appearance, 'textGone' implies disappearance, and 'time' implies duration. However, it does not explain units for time, whether parameters are mutually exclusive, what happens if multiple are provided, or the behavior when all are null. This is helpful but incomplete.
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 function: waiting for text to appear, disappear, or waiting a fixed duration. It uses a specific verb ('wait') and resource ('text'), and the purpose is distinct from siblings like browser_click or browser_navigate. It explicitly covers all three main behaviors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, no exclusions, and no prerequisites. It simply states what the tool does without contextualizing it within browser automation workflows, such as after navigation or before assertions. There is no mention of alternative tools for conditional waits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'fill' without detailing side effects, whether fields are validated, what happens on failure, or whether any events are triggered. This is insufficient for an action tool that mutates a webpage.
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, focused sentence that conveys the core purpose without any fluff or repetition. It is appropriately sized for its simplicity.
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 a parameter that references 'page snapshot', the description omits critical context like prerequisites (obtaining refs via browser_snapshot), error behavior, and whether the operation is atomic. This leaves the agent with insufficient information to use the tool correctly in complex scenarios.
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 low (the top-level 'fields' parameter has no description), so the description should compensate. It only says 'form fields' without explaining that each field requires a 'ref' from the page snapshot or how the value is applied. The nested schema has useful descriptions, but the description itself adds minimal value beyond the schema.
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 'Fill multiple form fields in one call' clearly states a specific verb and resource, and the phrase 'multiple form fields' distinguishes it from single-field tools like browser_type. It is unambiguous and directly explains what the tool does.
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 filling multiple fields at once, which hints at a batching scenario, but it does not explicitly mention alternatives or when not to use it. Sibling tools like browser_type and browser_select_option exist, and the description doesn't contrast with them, leaving the when-to-use guidance somewhat implicit.
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 says 'take a screenshot' but does not state whether the screenshot is returned, saved to a file, or how the filename parameter affects behavior. It also does not mention side effects like file system writes 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?
The description is a single concise sentence that front-loads the action and includes the three key capture targets. Every word earns its place, and there is no fluff or repetition.
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 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on parameter usage, return values, file handling, and edge cases (e.g., what happens if both element and fullPage are set). The description is barely adequate for a simple screenshot, but not for the full parameter set.
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 mentions 'full page' (likely mapping to fullPage) and 'referenced element' (element), but leaves ref, type, and filename unexplained. The relationship between ref and element is undefined, and the type parameter's enum is not described.
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 screenshots and specifies three modes: viewport, full page, and referenced element. This distinguishes it from other browser action tools like click or navigate, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose strongly implies when to use this tool (whenever a screenshot is needed), but there is no explicit mention of alternatives or situations to avoid. The sibling tool 'browser_snapshot' could be relevant, but the description does not clarify the difference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action without mentioning what happens when there is no previous page, whether it waits for the page to load, if it preserves or discards form data, or any side effects. While the action is simple, the lack of contextual behavior transparency leaves gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and directly communicates the tool's function. It earns its place by being succinct and unambiguous.
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 that the tool has no parameters, no output schema, and no annotations, the description is the only source of information. It covers the high-level action but omits details about return values, behavior under edge cases (e.g., no history), and potential side effects. This is adequate for a simple tool but not fully complete for an AI agent to anticipate all outcomes.
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 accepts zero parameters, so there are no parameter semantics to explain. According to the scoring rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to elaborate further.
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' uses a specific verb ('go back') and identifies a clear resource (the previous page). It distinguishes itself from the sibling tool 'browser_navigate' which implies forward navigation to a new URL, and from 'browser_tabs' which deals with tab management.
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 the agent needs to return to the prior page in the browser history, but it does not explicitly state when to use this tool over alternatives like 'browser_navigate' or provide any exclusion scenarios (e.g., no previous page, form state loss). The context is clear enough for a simple action, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It clearly states the action and its scope ('the current browser session'), which implies the session is terminated. It does not mention side effects like unsaved data loss, but for a close operation the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that delivers the essential information without waste. It is front-loaded and appropriate for the tool's simplicity.
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?
The tool is simple: no parameters, no output schema, no annotations. The description fully explains the operation ('Close the current browser session') and is sufficient for an agent to select and invoke it correctly in the context of sibling browser tools.
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, so the baseline is 4. The description correctly implies there is nothing to configure, and the empty schema aligns with the description. No parameter explanation is needed.
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 states a clear action and object: 'Close the current browser session.' This is a specific verb+resource that distinguishes it from sibling browser tools like navigate, click, or snapshot, none of which close the session.
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 you want to terminate the browser session—but does not explicitly state when to use it versus alternatives or provide context such as 'use when done with all tasks.' There are no obvious alternatives among siblings, but guidance is minimal.
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-mcp-python MCP server](https://glama.ai/mcp/servers/zc-libre/camoufox-mcp-python/badges/card.svg)](https://glama.ai/mcp/servers/zc-libre/camoufox-mcp-python)

Score Badge

Copy to your README.md:

[![camoufox-mcp-python MCP server](https://glama.ai/mcp/servers/zc-libre/camoufox-mcp-python/badges/score.svg)](https://glama.ai/mcp/servers/zc-libre/camoufox-mcp-python)

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/zc-libre/camoufox-mcp-python'

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