Camoufox MCP Server

Server Quality Checklist

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

Latest release: v2.5.0
Disambiguation2/5
Many tools share the 'browse' prefix and differ only in output focus, such as browse, browse_snapshot, browse_outline, and browse_forms. Session-based equivalents like browse_session_navigate and browse_session_snapshot mirror one-shot tools, creating ambiguity about which to use. This overlap makes tool selection challenging.
Naming Consistency3/5
The server uses snake_case, but the prefix pattern is inconsistent: bare 'browse', 'browse_*', 'browse_session_*', and 'camoufox_status'. While the verb 'browse' is common, the mix of noun and verb forms and the odd 'camoufox_status' break predictability. Overall readable but not uniform.
Tool Count3/5
At 17 tools, the count is on the higher end of the appropriate range for a browser automation server. The breadth covers one-shot browsing, session management, and diagnostics, so it's not excessive, but it's borderline heavy. A few tools could be merged without losing functionality.
Completeness4/5
The server covers navigation, content extraction, screenshotting, diagnostics, and session lifecycle. It lacks dedicated form-filling or cookie tools, but browse_sequence and browse_session_action provide generic action execution. Core browsing workflows are supported, with only minor gaps.
Average 3.6/5 across 17 of 17 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already imply. It does not disclose that navigation may trigger side effects (annotations indicate readOnlyHint=false), what happens to the session, or that it may encounter CAPTCHAs. The parameter descriptions cover some behaviors, but the description itself is nearly a restatement of the tool name.
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, free of filler or redundancy. It is front-loaded and immediately states the core purpose. While very brief, this dimension rewards conciseness, and the sentence 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?
Despite having a rich schema with 8 parameters and an output schema, the tool description is a single sentence that does not provide an overview of the tool's capabilities, such as returning page content, supporting selectors, or handling CAPTCHAs. It fails to place the tool within the session lifecycle or explain its relationship to sibling tools, leaving the agent without sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 itself provides no parameter information, but the schema's detailed parameter descriptions fully document the URL, timeout, selector, output mode, and other options. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Navigate') and the resource ('an existing browser session'), which distinguishes it from session start/close tools. However, it does not explicitly differentiate from the sibling 'browse' tool, which could also imply navigation, so it lacks full 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an existing session from browse_session_start), exclusions, or any comparison to other browsing tools. The agent receives no usage context beyond the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and openWorldHint=true. The description adds the novel context that sessions are isolated and short-lived, which is useful. However, it doesn't disclose what 'start' returns or whether sessions require explicit closing, though the output schema covers some of that. Moderate added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with zero fluff, making it extremely conciseness and front-loaded. It earns its place but is perhaps too terse, missing the opportunity to add workflow context. Still, it is appropriately concise for a simple action.
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 having 22 parameters, an output schema, and nested objects, the description is extremely underspecified. It doesn't explain the session lifecycle, how this tool relates to sibling browse_session_* tools, or important defaults. The schema and output schema mitigate but don't eliminate the gap; the description fails to place the tool in the broader workflow.
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 all 22 parameters already have individual descriptions. The tool description adds no parameter semantics, and the baseline for high schema coverage is 3. It doesn't compensate or add any extra meaning beyond 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 uses a specific verb ('start') and names the resource ('browser session'), adding scope with 'isolated short-lived.' This distinguishes it from sibling session tools that navigate or close sessions. However, it remains terse and doesn't elaborate on what a session entails, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like 'browse' or other browse_session_* tools. It doesn't state that this should be called before other session operations or when a one-off 'browse' is more appropriate. There's no mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the 'navigate once' constraint, which is useful, but does not explain what 'bounded' means, how diagnostics are collected, or any side effects such as network requests. With annotations covering the main safety concerns, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words, front-loaded with the core action and output. It is perfectly concise and 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?
Despite having 23 parameters, nested objects, and an output schema, the description is only one sentence. It leaves ambiguity about what 'bounded console diagnostics' includes, whether it opens a new browser or uses an existing session, and how it interacts with session state. For a tool of this complexity, the description is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 23 parameters. The description adds no further parameter-level semantics, and the baseline of 3 is correct given the schema's completeness.
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 ('Navigate once') and the output ('bounded console diagnostics'), which is specific and distinguishes it from general browsing or network-oriented sibling tools. However, it doesn't explicitly mention that it returns console logs or messages, leaving some room for interpretation.
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 browse, browse_network_summary, or browse_snapshot. It only states what the tool does, not when it should be selected or when it should be avoided.
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?
'Navigate once' is a mild behavioral constraint, but the description doesn't disclose how navigation is handled, what triggers form extraction, or any side effects. Annotations already mark it as read-only, so the description adds minimal transparency beyond that.
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 sentence effectively captures the core functionality without unnecessary words. It's front-loaded with the key verb 'Navigate' and immediately specifies the return value.
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 an extensive schema and output schema, the description is too sparse for a tool with 26 parameters. It doesn't explain relationships to sibling tools, typical workflows, or how this fits into a broader browsing automation session.
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 detailed parameter descriptions, so the baseline is 3. The tool description doesn't add any parameter semantics beyond what the schema provides, but that's acceptable given the schema's completeness.
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 navigates to a URL and returns form fields and submit controls. This specific output distinguishes it from sibling tools like browse_links or browse_snapshot, which handle other aspects of page content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as browse_find or browse_snapshot. It only states what it does, without mentioning typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds almost no behavioral context beyond 'bounded', which is too vague. It does not disclose that actions may navigate, evaluate JavaScript, modify page state, or perform irreversible interactions, leaving significant risk unaddressed.
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 zero wasted words, front-loading the core purpose effectively. However, given the tool's complexity (large action union, many options), a bit more orientation would be appropriate; it is slightly under-sized rather than ideally concise.
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?
With rich schema, annotations, and an output schema, the description is minimally viable. It states the core function and existing-session requirement. However, it lacks usage context, does not clarify the variety of supported actions, and offers no differentiation from siblings, making it incomplete for a tool of this complexity.
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%, and the input schema provides detailed descriptions for parameters like sessionId, action, captchaPolicy, and snapshot limits. The description adds no parameter-level meaning beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run one bounded action in an existing browser session' uses a specific verb ('run'), a clear resource ('bounded action'), and context ('existing browser session'). It effectively distinguishes this from siblings like browse_session_start (create) and browse_sequence (multiple actions) by emphasizing 'one bounded 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?
The description provides no guidance on when to use this tool versus alternatives such as browse_sequence or browse_session_navigate. It implies a precondition (existing session) but does not state exclusions, alternatives, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds 'navigate once' and 'bounded', providing useful context about the tool's behavior, but does not disclose details like error handling or output limits beyond 'bounded'.
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?
One sentence, front-loaded, no redundancy. Every word earns its place.
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?
With 24 parameters and a rich output schema, a one-sentence description is minimal. The description lacks context on what diagnostics are included (e.g., failures, resource types) and when to use the tool, but the output schema and annotations compensate partially.
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%, so the baseline is 3. The description adds no parameter-specific information beyond what the schema already provides.
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 specific verb ('Navigate once') and identifies a distinct resource ('bounded network diagnostic summary'), which distinguishes it from sibling tools like browse_links or browse_console. However, it could be clearer about what the summary contains (e.g., failed requests, performance metrics).
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 mention of when to use this tool vs alternatives or any exclusions. The description implies a single navigation scenario but provides no explicit guidance on selecting it over other browse 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. However, the description adds only the vague term 'bounded' and does not explain what it means, nor does it disclose any behavioral traits such as stealth behavior, captcha handling, or response characteristics. It contributes minimal behavioral context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Navigate once and capture a bounded screenshot.' It contains no fluff, redundant text, or repetition of schema details. Every word serves a purpose, making it highly 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?
Despite having rich schema and annotations, the tool is complex (27 parameters, nested objects, output schema). The description is too terse to provide sufficient context for an agent to fully understand the tool's capabilities and limitations. Terms like 'bounded' are undefined, and there is no mention of key behavioral aspects like stealth profiles, wait strategies, or diagnostic options. Given the complexity, the description is under-specified.
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% for all 27 parameters, with each parameter having a detailed description. The tool description itself adds no parameter-specific meaning, but since the schema fully documents parameter semantics, a baseline score 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 'Navigate once and capture a bounded screenshot' uses a specific verb ('capture') and resource ('bounded screenshot'), and 'navigate once' clearly distinguishes it from multi-step tools like browse_sequence or persistent-session tools. It precisely states the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'navigate once' implies single-shot usage, subtly contrasting with browse_sequence, but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions or prerequisites. The guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=false, so the description's job is to add context like side effects or prerequisites. It only says 'close an existing session,' which adds minimal value beyond the tool name. It does not mention what happens if the session is already closed or whether any cleanup occurs.
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, straightforward sentence that conveys the essential information without any superfluous content. It is optimally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema present, the description is mostly complete. However, it could benefit from noting that closing a session is non-idempotent or that the session must be active, though the schema partially covers this. Given the low complexity, the description is adequate but not exhaustive.
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 100% of the parameter (sessionId) and describes it as 'Session ID returned by browse_session_start.' The description does not add any additional meaning to the parameter, so with high schema coverage the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Close an existing browser session" uses a specific verb (close) and resource (browser session), clearly distinguishing it from sibling tools like browse_session_start (start) and browse_session_navigate (navigate). It precisely identifies the action without ambiguity.
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, when not to, or what alternatives exist. It only states what the tool does, leaving the agent to infer that it should be used after a session is no longer needed. No exclusions or comparisons with siblings 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the 'Read' claim is consistent and safe. However, the description adds no additional behavioral context beyond the annotations, such as session expiration behavior, error conditions, or the meaning of the captchaPolicy parameter.
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 immediately conveys the tool's purpose without any filler or redundant detail. It is front-loaded and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a full output schema, extensive annotations (readOnly, openWorld), and complete parameter documentation, the description is sufficient for basic understanding. It does not explain non-obvious aspects like CAPTCHA handling, but those are covered in the schema, so this is acceptable for a read-only snapshot 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?
The input schema provides 100% parameter coverage, including descriptions for all five parameters, so the schema carries the full burden. The description adds no extra meaning to the parameters, therefore the baseline of 3 applies.
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 (read) and the resource (current state of an existing browser session), making it distinct from session creation or navigation tools. It does not explicitly name sibling alternatives, but the phrase 'existing browser session' differentiates it from non-session snapshots like browse_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 is for an already-started session, but it provides no explicit when-to-use guidance or exclusions compared to sibling tools. The context signal that a sessionId is required is present in the schema, not the description, so the guidance remains only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify readOnlyHint=true and destructiveHint=false, so the bar is lower. The description adds 'Navigate once', which conveys a one-time navigation action, but it doesn't disclose other behavioral aspects like bounded output or captcha handling that are present in the schema.
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 a clear action-first structure, listing the output types succinctly. Every word is meaningful and there is no redundancy.
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 26 parameters and output schema, the description is quite minimal. It does convey the core purpose clearly, but it lacks an overview of advanced options like captcha policy or stealth profiles. However, the rich schema and annotations compensate, making the description sufficient for high-level selection.
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%, so the baseline is 3. The description doesn't elaborate on any parameters, but all parameter details and constraints are already well-documented in the schema, so no additional semantics are necessary.
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 with a specific verb ('Navigate') and resource ('snapshot'), and enumerates the exact outputs (visible text, ARIA snapshot, interactive metadata). This distinguishes it from sibling tools like browse_links or browse_screenshot.
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, nor any exclusions. The description is purely functional and doesn't mention use cases or scenarios where other sibling tools would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds 'navigate once' and 'visible navigable' as useful behavioral qualifiers, but provides no details about rendering, waiting, or filtering mechanics. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At just eight words, the description is exceptionally concise and front-loaded with the action ('Navigate') and scope ('visible navigable links'). Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the extremely rich schema (100% parameter coverage), annotations, and an output schema, the one-sentence description is a sufficient high-level summary. It could briefly mention when to use this over sibling tools, but the existing structured data compensates for the brevity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema itself provides full parameter semantics. The tool description does not mention any parameters, but since the schema thoroughly documents all 25 parameters, a baseline score 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?
The description uses specific language: 'Navigate once' distinguishes it from session-based sibling tools like browse_session_navigate, and 'only visible navigable links' specifies the exact output scope. However, it does not explicitly name alternative tools, so it is clear but not maximally differentiating.
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?
No explicit when-to-use or alternative guidance is given. The description implies usage for extracting visible links after a single page load, but does not explain when to prefer browse_links over browse_find or browse_outline. This is implied usage at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds the useful fact that the tool performs a fresh navigation ('Navigate once') rather than reusing a session, which is behavioral context beyond the annotations. However, it does not disclose any other behavioral traits such as network request specifics or potential delays.
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 with no waste. Every word contributes: 'Navigate once' sets the execution model, and 'return page headings and landmarks' specifies the output. It is appropriately sized for an MCP tool description.
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?
Despite 25 parameters and an output schema, the description is complete enough for a simple outline-extraction tool. The core behavior is clearly stated, and the output schema presumably documents the return structure. It doesn't address edge cases or usage context, but for a read-only outline tool, it suffices.
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 all 25 parameters including detailed descriptions and enums. The tool description does not add any parameter-level semantics, so the baseline of 3 is appropriate—the schema carries the full burden and does so effectively.
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 navigates once and returns page headings and landmarks. This is a specific verb+resource combination that distinguishes it from sibling tools like browse_links, browse_forms, and browse_snapshot, which have different extraction targets.
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 phrase 'Navigate once' hints at a one-shot operation, but the description does not explicitly state when to use this tool vs alternatives or when not to use it. Given the large sibling set (browse_session_*, browse_find, etc.), this lack of guidance is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context: 'bounded' indicates output limits and 'Navigate once' implies no session persistence. This goes beyond the annotations without contradicting them, giving the agent a clearer expectation of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence (7 words). It is front-loaded with the core action and constraint ('Navigate once', 'bounded'), and every word contributes meaning. No waste or redundancy.
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?
Despite having 28 parameters, the schema and output schema are extremely detailed, so the description does not need to list options. The description gives a concise summary that orients the agent to the tool's primary purpose and its bounded-output nature. It is sufficiently complete for the complexity, though it could note the variety of output modes (text/html/metadata) which are only in the schema.
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 every parameter is thoroughly documented. The tool description does not add extra parameter semantics beyond the schema; it only hints at bounded content, which is already captured by maxChars. Baseline 3 is appropriate given full 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 'Navigate once and return bounded page content' uses a specific verb ('navigate') and resource ('page content'), and the word 'once' distinguishes it from sibling tools like browse_sequence. It is clear and unambiguous, though it could be more explicit about being a single-page fetch/scrape tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by 'Navigate once', which suggests it is for a single page rather than a sequence or session. However, there are no explicit references to alternatives or when-not-to-use scenarios. The schema's url parameter description does provide some use-case guidance, but the tool description itself lacks clear direction on choosing between browse and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds 'bounded' actions and 'final state' but does not disclose side effects like cookies, challenge handling, or failure behavior. It is consistent with annotations but adds limited extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the core workflow without wasted words. Every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the very detailed schema and output schema, the high-level description captures the essential workflow. It does not explain every option, but that is handled by the schema. The description could mention session alternatives, but for a bounded one-off sequence it is sufficiently complete.
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% and all parameters have descriptions. The description does not add parameter-level detail beyond the schema, so baseline 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 tool's function: navigate once, execute bounded selector actions, and return final state. It distinguishes itself from sibling tools like browse_session_action and browse by emphasizing a single navigation with a bounded action sequence.
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 phrase 'Navigate once' implies a one-shot use case, but it does not explicitly state when to prefer this over browse_session_* or browse. No alternative tools are named or exclusions given, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral traits: it navigates once, searches visible text (as opposed to HTML or raw source), and returns bounded context matches (limited by maxMatches and contextChars). This goes beyond the annotations and gives the agent a better understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing three short clauses: 'Navigate once, search visible text, and return bounded context matches.' Every word earns its place, and the structure front-loads the core action. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 27 parameters, nested objects, and an output schema, the description is minimal but sufficient to convey the essential purpose. The rich schema and output schema handle the detailed parameter semantics and return values, so the description does not need to explain them. However, it could have added a note about when to use it versus browse_links or browse_forms, but the sibling names partially cover that. It is complete enough for an agent to make an initial selection.
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 detailed descriptions for all 27 parameters, including query, maxMatches, contextChars, and others. The description does not add any meaning beyond what the schema already provides; it merely echoes concepts already present in the parameter descriptions. Therefore, a baseline score 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 tool navigates to a URL, searches visible text, and returns bounded context matches. This specific verb-action combination distinguishes it from siblings like browse_links (which finds links) and browse_forms (which finds forms), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need to search for visible text on a webpage and get surrounding context. It does not explicitly list exclusions or alternatives, but the sibling tool names (browse_links, browse_forms, browse_outline) imply the differentiation, so the agent can infer when to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds behavioral context by stating it returns status without launching a page. This goes beyond the annotations and clarifies that no browser session is created, which is valuable for an agent deciding between this and page-launching tools.
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 verb and resource list. Every word earns its place, with no filler or repetition.
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?
Given the tool's simplicity, no parameters, and an existing output schema, the description is complete. Annotations cover safety, and the description explains the tool's purpose and lack of side effects, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description need not explain parameter behavior. The baseline of 4 applies since there is no ambiguity about inputs, and the description fully covers what the tool does.
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 the specific verb 'Return' and names the exact resources: server, browser, queue, session, and policy status. The phrase 'without launching a page' clearly differentiates it from sibling browsing tools that do launch pages, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a lightweight status check that does not launch a page, which tells the agent when to use it (for status checks without browser side effects). However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true (the session may change externally) and this description goes beyond the annotations by explicitly mentioning 'after human action' and 'return current state', which signals that the tool waits for and reflects external state changes. It also implies the pause/resume flow, which is crucial behavioral context not apparent from annotations alone.
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 with no wasted words. It front-loads the essential action ('Resume a paused session') and includes the key output expectation ('return current state'), which is exactly what the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, rich parameter descriptions, and annotations, the description is sufficient. The only minor gap is not mentioning any specific return format details, but the output schema covers that. The description is complete for the tool's purpose and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with thorough parameter descriptions, especially captchaPolicy which details each enum value and the CAPTCHA_AUTONOMOUS behavior. The description says 'return current state' which aligns with the output schema. Although the description does not list parameters, the schema is rich and self-explanatory, so the description adds minimal but sufficient guidance.
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 a specific verb ('Resume') and resource ('a paused session'), and clarifies the return value ('return current state'). It distinguishes itself from sibling tools like browse_session_start, browse_session_snapshot, and browse_session_close by focusing on resuming a paused session after human action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context of use: after a human action, to resume a paused session. It does not explicitly name alternatives or exclusions, but the context is clear enough given the sibling set and the captchaPolicy pause option which connects to when this tool would be used.
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/whit3rabbit/camoufox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/whit3rabbit/camoufox-mcp)

Score Badge

Copy to your README.md:

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

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