camoufox-mcp

by ccostello97

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
Disambiguation5/5
Each tool has a clearly distinct action: navigate, snapshot, click, type, fill, hover, select, key press, wait, evaluate, screenshot, tabs, back, close. The only potential overlap is type vs. fill, but descriptions clarify that fill clears first, making them distinct.
Naming Consistency5/5
All tools use the 'browser_' prefix followed by a verb_noun pattern (e.g., browser_navigate, browser_click, browser_screenshot). The naming is predictable and uniform, with only minor deviations like browser_wait_for (verb_preposition) and browser_tabs (verb_noun but plural) that are still clear.
Tool Count5/5
14 tools is an ideal size for a browser automation server. It covers all essential interactions without being bloated. Each tool serves a specific purpose and there are no redundant or unnecessary tools.
Completeness4/5
The tool set covers the core browser automation lifecycle: navigation, interaction, tab management, screenshots, and JavaScript evaluation. Minor gaps exist, such as the absence of navigate_forward (only back) and a dedicated wait-for-element function (only wait for text or time). These are small but notable omissions.
Average 3.1/5 across 14 of 14 tools scored. Lowest: 2.4/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 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. The description 'Press a keyboard key' is a tautology of the name and adds no information about effects (e.g., whether it requires focus, simulates a single key event, or has side effects). This is critically insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, which is concise, but it does not earn its place because it merely restates the tool name. It lacks the explanatory depth needed for an agent to use it effectively. True conciseness would preserve clarity while adding necessary context, which is missing here.
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 parameter, no output schema, no annotations), the description is still incomplete. It does not explain when to press a key versus typing text, whether focus is required, or how the key press interacts with the page. The sibling tools provide context, but the description itself fails to leverage that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the sole parameter 'key' has a description with examples). The tool description does not add any parameter information beyond the schema. Per guidelines, baseline is 3, and no additional value is provided, so score remains 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a keyboard key' clearly states the action (press) and the resource (keyboard key). It is a specific verb+resource pair, but it does not differentiate from sibling tools like browser_type (which types text) or browser_click (which clicks). The purpose is clear but lacks distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., browser_type for typing multiple characters, browser_click for clicking). There is no mention of prerequisites, context, or exclusions. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether navigation is synchronous, whether it waits for page load, error handling, or side effects like clearing the current page state.
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 sentence with no wasted words. For a simple tool with one parameter, this level of conciseness is appropriate and earns its place.
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 annotations, no output schema, and only one parameter. The description is insufficiently complete, failing to explain return behavior, error conditions, or any side effects, which is critical for a navigation action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the only parameter 'url' has a description in the schema. The tool description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Navigate to a URL' clearly states the verb and resource, distinguishing it from sibling tools like browser_snapshot or browser_click. However, it is essentially a restatement of the tool name, adding minimal clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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_back. There is no context about prerequisites, URL format, or when navigation might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Close the browser' is vague about side effects: does it terminate the entire session, close the current tab, or prompt for unsaved data? No disclosure of destructive behavior or irreversible state changes.
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?
Extremely concise at three words, with no wasted text. However, it may be too brief for an agent to fully understand the tool's scope. Still, it is well-structured and front-loaded.
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 is a destructive action with no annotations or output schema, the description is inadequate. It does not explain what happens after closing, how to reopen, or what the agent should do beforehand. Lacks completeness for safe usage.
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?
Tool has zero parameters, so baseline is 4. The description adds no parameter information, but the input schema already shows no properties. No additional semantic value needed beyond the schema.
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?
Description states 'Close the browser', which is a clear verb+resource action. However, it is minimal and essentially a tautology of the tool name 'browser_close', and does not differentiate from siblings like 'browser_navigate_back' or 'browser_tabs' which also affect browser state.
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 on when to use this tool versus alternatives such as 'browser_navigate_back' or 'browser_snapshot' before closing. The description offers no context about prerequisites or typical workflows.
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 does not mention what happens after a click—like navigation, state changes, or waiting—nor any side effects like triggering popups or form submissions. It lacks details on error conditions (e.g., if ref is stale or element is hidden) and does not indicate whether the tool is destructive or read-only. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 9 words, efficiently stating the core action. It is front-loaded with the verb 'Click' and immediately clarifies the mechanism ('by its ref from the snapshot'). No redundant information is present. It earns points for brevity, but could be slightly more structured with optional usage notes.
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 2 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the return value (e.g., nothing, a success status, or updated page content), nor does it clarify the relationship to sibling tools like browser_snapshot (which generates the ref). The context signals indicate low complexity, but the lack of behavioral and usage guidance leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents both parameters. The description does not add new meaning beyond the schema; it merely states the tool's main action. The 'element' parameter's human-readable description is covered by the schema, and the description does not elaborate on how the 'ref' is obtained or validated. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Click an element by its ref from the snapshot' clearly specifies the verb 'Click' and the resource 'element by its ref from the snapshot'. It distinguishes itself from sibling tools like browser_hover, browser_type, and browser_fill by focusing specifically on clicking, and hints at dependency on browser_snapshot for obtaining the ref. However, it could be slightly more explicit about how it differs from browser_select_option or browser_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to use browser_hover or browser_fill. It does not mention prerequisites like the need for a recent snapshot, nor does it exclude inappropriate contexts (e.g., clicking elements that are not interactable). The usage context is only vaguely implied by the relation to snapshots.
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 fully disclose behavioral traits. It only mentions 'clears first', but omits critical details: what happens if the element is not found, whether it waits for the element, event triggering, or scrolling behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but could benefit from additional structure to separate usage notes, though the current form 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?
The description is too brief for a browser automation tool. It does not explain how to obtain the element reference, what happens on error, or the return value (no output schema). Given the absence of annotations and output schema the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with clear descriptions (e.g., ref is 'Element reference from snapshot', text includes clearing note). The tool description adds no new meaning beyond the schema, so a baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Fill text into an element' and mentions the clearing behavior, making the purpose evident. However, it does not differentiate from the sibling tool 'browser_type', which could cause confusion about which tool to use for text input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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_type or browser_click. There is no mention of prerequisites (e.g., needing a snapshot) 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?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Hover over an element' with no mention of effects (e.g., triggering hover events, non-destructive nature, potential failures if element not found). This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. For a tool with one parameter, this is efficient. However, it could be slightly more informative without sacrificing conciseness (e.g., 'Hover over an element on the page using a reference from a snapshot').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally complete. It conveys the basic action but lacks context about what happens after hovering, whether it returns anything, or if it waits for any events. An agent might need this context for correct sequencing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single 'ref' parameter is described as 'Element reference from snapshot'). The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter, but the description does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over an element' clearly states the verb and resource. It distinguishes from sibling tools like browser_click and browser_type, which perform different actions. However, it could be slightly more precise by specifying the context (browser page) but the tool name implies it.
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 hover versus alternative tools like click or type. There is no mention of prerequisites (e.g., needing a snapshot first) or conditions that might make hovering appropriate. The description is purely a statement of action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists actions but does not disclose side effects (e.g., closing a tab loses state), what 'new' does, or how index applies. The description largely restates the action parameter without adding behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the tool's purpose immediately. It wastes no words.
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 the simple surface, the tool has multiple actions with different implications and no output schema or annotations. The description fails to clarify return values, side effects, or the index/action relationship, leaving significant gaps for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both action and index. The description adds no additional meaning beyond the schema; it only repeats the action enum, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies the resource ('browser tabs') and enumerates the main actions (list, new, close, select), distinguishing it from sibling navigation/click tools. The verb 'manage' is a bit generic, but the action list clarifies scope.
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 on when to use this tool versus alternatives. It does not mention sibling tools like browser_navigate or provide contexts for choosing tab management over other browser operations.
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 exist, and the description does not disclose behavioral traits such as whether the evaluation is synchronous, what happens with errors, whether it can modify the DOM, or what the return value is. This is a risky gap for a tool that executes JavaScript.
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, which is concise and front-loaded. However, it could be slightly more structured by including a brief note about output or behavior, but it avoids waste.
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 power (executing JavaScript), the description is incomplete. It lacks information about return values, error handling, security implications, and whether it's a read-only or mutation operation. The absence of an output schema increases the need for descriptive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'expression' parameter as 'JavaScript expression to evaluate' with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Evaluate JavaScript in the page context' clearly identifies the verb (evaluate) and resource (JavaScript in the page context). It is distinct from sibling tools like browser_click, browser_navigate, etc., which perform other browser actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 example, the description does not mention that this tool runs arbitrary code, which differs from interactive tools like browser_type. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does, not how it behaves (e.g., does it clear previous selections? Does it trigger events? What happens if a value is invalid?). The parameter descriptions in the schema ('Element reference from snapshot', 'Values to select') add some context but do not disclose behavioral traits beyond parameter meaning.
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 extremely concise (5 words, one sentence) and front-loaded with the core action. No wasted words. However, it is under-specified for the tool's complexity, sacrificing completeness for brevity. Still, it earns its place by stating the purpose, so not a 5.
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 role in browser automation (with siblings like browser_snapshot, browser_click), the description lacks crucial context: how to obtain the 'ref' (from a snapshot), that the dropdown must be visible, or what the return value is. The schema covers parameter descriptions but not workflow context. The description is incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'ref' and 'values' clearly described. The tool description adds no additional parameter meaning, so baseline 3 applies. The description does not need to repeat schema details, but it also does not add 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 'Select option(s) in a dropdown' clearly states the verb ('Select') and the resource ('option(s) in a dropdown'). It distinguishes the tool from siblings like browser_click and browser_type, which are for general clicking or typing, and browser_fill, which is for text inputs. A specific, unambiguous purpose.
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 (e.g., clicking an option with browser_click, or typing a value). There is no mention of prerequisites (e.g., needing a snapshot first) or exclusions (e.g., only works with native <select> elements). The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions waiting for text or time, which covers basic use cases, but does not explain what happens if multiple parameters are supplied, whether it blocks other actions, or behavior on timeout. The description is adequate but lacks detail on 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 very short (one sentence) and front-loaded with the core purpose. However, it could benefit from a second sentence clarifying parameter behavior (e.g., 'Text, time, and text_gone can be used independently.'). Still, it is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, 0 required, no output schema), the description is too minimal. It does not explain return values, timeout behavior, or what happens when no parameter is passed. It leaves the agent guessing about how to interpret the interplay of parameters.
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 100% (all parameters have descriptions). The description does not add additional meaning beyond the schema—it merely summarizes the two main waiting modes. With complete schema coverage, baseline is 3, and the description does not elevate it.
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 that the tool waits for text appearance/disappearance or a specified time. It distinguishes itself from other browser tools by focusing on waiting, but could be more explicit about the 'wait for text to disappear' option from the text_gone parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like waiting for page load or navigation. It does not mention that it can be used to wait for dynamic content after actions like clicks, nor does it explain the interplay of the three parameters (e.g., they are independent or exclusive).
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 exist, so the description bears full responsibility. It discloses the append behavior but omits key traits: whether the element must be focused, what happens if the element is not interactive, and the optional submit action (pressing Enter) is not mentioned in the description. The description is too sparse to adequately inform an agent about side effects or requirements.
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 sentence with no extraneous words. It front-loads the action and immediately clarifies the key differentiator. Every word earns its place. It is a model of brevity for the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 parameters, no nested objects, no output schema) and strong schema coverage, the description provides adequate core information. However, it lacks mention of the submit behavior and does not reference the source of the ref parameter (from browser_snapshot). Completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific information beyond the schema; it does not explain how the ref relates to the snapshot or that submit triggers a form submission. The description does not degrade or improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Type' and the resource 'an element', and adds the critical behavioral distinction '(appends to existing)'. This clearly separates it from sibling tool browser_fill, which presumably replaces text. The purpose is unambiguous and well-differentiated.
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 when to use this tool (when appending text) via the parenthetical note, but it does not explicitly state when to use alternatives (e.g., browser_fill for overwriting) or provide any exclusions. The guidance is implied rather than direct, leaving the agent to infer the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it does not disclose important behavioral details such as whether the screenshot is saved as a file, returned as a path, or embedded in the response; nor does it mention permission requirements or visual fidelity.
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 straightforward sentence that communicates the core action efficiently. It is not burdened with extraneous details, though it could optionally add a bit more context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and lack of output schema, the description is minimally complete. However, it omits information about the return format (e.g., base64-encoded image, file path), which would be valuable for the AI agent to process the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides good coverage (100%) for the single parameter 'full_page'. The description does not add additional meaning beyond the schema's own description, so a 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 clearly states the action (take a screenshot) and the target (the current page), distinguishing it from navigation, clicking, typing, and other browser tools. The verb-resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a visual capture of the page is needed, but it does not explicitly state when to prefer this over browser_snapshot or other inspection methods, nor does it mention any prerequisites (e.g., page must be loaded).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates a navigation action (moving to previous page) but doesn't specify what happens if there's no browsing history, whether state is lost, or if waiting is required. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose. No unnecessary words, perfectly sized for the tool's simplicity.
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 zero parameters, no output schema, and a trivial action, the description provides sufficient context. It could mention browser history implications, but overall complete for a back navigation tool.
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 no parameters and schema coverage is 100%, so no additional parameter documentation is needed. The description correctly implies no arguments are required.
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 'Go back to the previous page' clearly indicates the tool navigates the browser back one step in history. It uses a specific verb and resource, and context from sibling tools shows it's distinct from navigation like 'browser_navigate' or page inspection like 'browser_snapshot'.
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 as a standard browser back action, appropriate after navigating pages forward. However, it provides no explicit guidance on when not to use it (e.g., if no history exists) or alternatives like 'browser_navigate' with a URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of transparency. It states that the tool returns element refs like 'e0, e1', which is helpful. However, it does not disclose any side effects (e.g., whether it modifies page state), performance implications, or prerequisites (e.g., must have a loaded page). The behavior is minimally described.
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 short sentences that front-load the core purpose and immediately specify the return format. Every word is necessary and no space is wasted.
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 the tool has no parameters and no output schema, the description provides a clear purpose and return value. It is reasonably complete for a simple read tool. However, it could mention that the snapshot reflects the current accessibility tree, or that element refs are only valid until the page changes, which would improve completeness. Still, it covers the essential information.
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 tool has zero parameters, and the input schema coverage is 100% (since there are no properties). According to guidelines, this gives a baseline of 3 even without parameter info in the description. The description does not add any parameter semantics, which is acceptable given the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get accessibility snapshot of the current page.' This is a specific verb-resource combination that distinguishes it from siblings like browser_screenshot (visual) and browser_click (interaction). The additional note about returning element refs clarifies the output.
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 that the tool is used to obtain element references for subsequent interactions, but it does not explicitly state when to use this tool over alternatives. For example, it does not mention that this should be called before browser_click or browser_type, nor does it describe situations where the snapshot should be avoided. The context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 MCP server](https://glama.ai/mcp/servers/ccostello97/camoufox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ccostello97/camoufox-mcp)

Score Badge

Copy to your README.md:

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

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