VRO Camoufox MCP

Overview Schema Related Servers Score Discussions

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 clear prefix-based purpose: artifact.* handles artifact lifecycle, browser.* manages the browser session, and listing.* deals with page extraction. Even the overlapping listing.enumerate_member_inventory and listing.crawl_member_inventory are distinguished by the latter being a higher-level traversal, with descriptions clarifying the relationship.
Naming Consistency5/5
All tool names follow a consistent pattern of domain.snake_case_action, e.g., browser.start_session, listing.crawl_member_inventory, artifact.confirm_remote_sync. No mixed conventions or verb-style inconsistencies.
Tool Count5/5
Twelve tools is within the ideal range and well-scoped across three subdomains: browser control (4), listing extraction (3), and artifact management (5). Each tool serves a distinct purpose and earns its place without redundancy.
Completeness4/5
The tool surface covers the core browser session lifecycle, listing inspection/traversal, and artifact management from creation through sync confirmation and cleanup. Minor gaps exist, such as no explicit artifact discovery for confirmed items or more granular browser interactions (e.g., navigation, clicking), but these are workable for the apparent scope.
Average 3.1/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'attempts' hints at a best-effort or possibly fallible operation, and 'deterministic' implies a fixed approach, but there is no mention of side effects, prerequisites, error behavior, or whether the overlay is permanently removed. The description adds minimal behavioral nuance beyond the raw 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 concise sentence with no redundant words, effectively front-loading the core action. It is appropriately short for a tool of this apparent scope, though the terseness does border on under-specification.
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 two parameters, no annotations, and no output schema, the description should explain the tool's operation more fully. It fails to describe how overlay_types works, the expected behavior when invoked, or any limitations. The description is insufficient for an agent to confidently select and invoke the tool correctly in all relevant situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention either parameter (browser_session_id or overlay_types). The phrase 'known overlays' might indirectly allude to overlay_types, but it does not clarify how the parameter is used, what values it accepts, or what happens if it is omitted. The description provides no compensatory value for the undocumented 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 'dismiss' and a resource 'overlays', which clearly distinguishes this tool from siblings like browser.open_url or browser.inspect_page. However, 'known overlays' is vague and does not define what constitutes a known overlay, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any preconditions like checking for overlay presence or handling failures. It is a bare statement of intent with no contextual instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It mentions 'visible' tiles but does not explain side effects such as scrolling behavior, limits, or whether the page is mutated. The tool likely interacts with the browser (given the browser_session_id parameter), but this is 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 concise sentence with no filler or redundancy. It is appropriately front-loaded, though arguably too brief for the tool's complexity, making it more under-specified than structurally wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no annotations, and no output schema, the description is far too sparse. It does not explain return values, scrolling behavior, metadata retrieval, or when to stop, leaving critical gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of any of the five parameters (max_listings, scroll_limit, include_tile_metadata, etc.). The description does not help an agent understand what each parameter controls or how they affect the enumeration.
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 ('Enumerates') and identifies the resource ('visible listing tiles on a member profile page'), making the core purpose clear. It does not explicitly contrast with sibling tool 'listing.crawl_member_inventory' which likely performs a broader crawl, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'listing.crawl_member_inventory'. The description simply states what it does, without explaining context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'Creates or returns' discloses an important behavioral trait: the tool is idempotent and will return an existing session if one is already active. With no annotations provided, this is helpful, but the description omits other behavioral details such as side effects, required setup, or state resets, leaving the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified. While it earns its place by stating the core operation, it lacks critical details that a slightly longer description could have provided, making it concise yet incomplete.
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 as a session initializer with 3 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain the return value, prerequisites, or how this fits into the workflow of the sibling tools. The agent would not know when or why to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for the lack of parameter documentation. The description mentions none of the parameters (locale, headless, timezone) and provides no guidance on their meaning or usage. The schema only lists names and defaults, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Creates or returns') and resource ('controlled browser session'), making it obvious this is a session management tool. However, it does not differentiate itself from siblings like browser.open_url or browser.inspect_page, nor does it explain what 'controlled' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that this should be called before other browser tools, nor does it describe any prerequisites or exclusions. No context signals are provided in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and mentions 'allowlisted', which hints at a restriction, but it does not disclose what happens on failure, whether the session navigates away, or what 'wait_until' and 'timeout_ms' imply about behavior. This leaves significant ambiguity about tool side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise with no wasted words. It is front-loaded with the action and resource, making it easy to parse. However, its brevity means it lacks depth, though that is more of a completeness issue than a conciseness issue.
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 no output schema, no annotations, and 4 parameters with zero schema descriptions, the description is far from complete. It does not explain the return value, error handling, or the meaning of the timeout and wait conditions. This is inadequate for a tool that navigates a browser session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameter meanings. It only implicitly refers to 'URL' and 'browser session', but provides no guidance on 'timeout_ms' or 'wait_until', which are key parameters. The description adds negligible value beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Opens'), the target ('an allowlisted URL'), and the context ('in the browser session'), which specifically identifies the tool's purpose. It distinguishes from sibling tools like browser.start_session (which starts a session) and browser.inspect_page (which inspects), as opening a URL is a distinct 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, prerequisites (e.g., an active session), or alternatives. It does not mention any exclusions or conditions under which another tool should be used instead, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and persistence, without mentioning side effects, required browser session state, return values, or potential failures, which is insufficient for a tool that writes an artifact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundant words, making it easy to parse. It is appropriately concise, though this brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain the significance of 'local artifact,' the role of intended_drive_path, the full_page behavior, or the relationship to remote sync siblings. Given four parameters, no annotations, and no output schema, this falls short of providing complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the four parameters (browser_session_id, filename, full_page, intended_drive_path). Since schema description coverage is 0%, the description adds no semantic meaning to the parameters, leaving the agent to infer from parameter names alone.
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 specifies the action ('captures a screenshot'), the target ('the current page'), and the outcome ('persists it as a local artifact'), distinguishing it from sibling tools like browser.inspect_page or artifact.get.
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 given on when to use this tool instead of alternatives. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It discloses a critical safety constraint (only_confirmed must remain true), but it does not clarify whether cleanup is permanent, what effects it has, or what the tool returns. This is insufficient for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—with the core purpose stated upfront and a critical safety warning following. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is too terse. It conveys the general purpose and one safety rule, but leaves parameter semantics and behavioral outcomes unexplained, making reliable invocation difficult.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning only to only_confirmed via the safety note, while dry_run and max_age_hours remain unexplained beyond their names and defaults.
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 'cleans up' with a clear resource 'old confirmed artifacts', making the purpose unmistakable. It also distinguishes itself from sibling tools like artifact.list_pending (lists) and artifact.get (retrieves) by focusing on deletion/cleanup.
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 does not provide any guidance on when to use this tool versus alternatives. The safety note about only_confirmed is a constraint, not an explanation of appropriate contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that a signed URL is optional but does not explain any side effects, prerequisites (like authentication), or the time-limited nature of signed URLs. It also doesn't clarify whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose and the optional parameter behavior efficiently.
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?
There is no output schema, so the description should explain the return value structure. It only says 'metadata' and 'signed download URL' without detailing format, error behavior, or what happens if the artifact does not exist. Given the simplicity of the tool, more context is still needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'artifact metadata' and 'optionally a signed download URL', which maps to include_signed_url, but it does not explain artifact_id at all, nor does it note that include_signed_url defaults to true (making the signed URL included by default). This leaves the parameter semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves artifact metadata and optionally a signed download URL. The verb 'Retrieves' is specific, and the resource is clearly 'artifact metadata'. It distinguishes itself from siblings like artifact.list_pending (listing) and artifact.cleanup (deletion).
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. It does not mention that this is for a single artifact by ID, nor does it contrast with sibling tools like artifact.list_pending. The usage context is only implied by the 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?
With no annotations provided, the description carries the behavioral burden. It discloses that the tool avoids returning full DOM content, indicating output is explicitly bounded and safe. However, it does not explain other important traits like whether it is read-only, how it handles dynamic content, or any limits on the summary beyond the DOM non-dumping 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 sentence with no filler words, making it highly concise and front-loaded. It earns its place by clearly communicating the core purpose. However, given five parameters and no other context, the brevity approaches under-specification rather than pure conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has five parameters, no output schema, and no annotations, yet the description only provides a one-sentence summary. It does not describe what the returned summary contains, what each parameter controls, or what the response looks like. This is insufficient for an agent to fully understand the tool's behavior in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides zero explanation of the five parameters (browser_session_id, max_links, include_links, max_text_chars, include_visible_text). It fails to compensate for the schema's lack of descriptions, leaving all parameter semantics entirely to the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Returns a safe page summary' – explicitly defining the action (returning) and object (page summary). It also distinguishes the tool from siblings by emphasizing 'safe' and 'without dumping arbitrary full DOM content', which sets it apart as a bounded, summary-only inspection 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?
The description implies the tool should be used when you need a page summary, and the 'without dumping arbitrary full DOM content' phrase hints at avoiding heavy DOM dumps. However, it does not explicitly state when to prefer this over alternatives like listing.inspect_current or browser.open_url, nor does it name any specific sibling as an alternative.
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 full burden. It does disclose a key behavioral trait: the tool only transitions to REMOTE_CONFIRMED if verified=true. However, it omits other important behavioral details such as side effects, reversibility, error scenarios, or what happens when verified=false.
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 exactly two sentences, front-loaded with the primary purpose and followed by the key condition. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, so the description needs to be thorough. It states the purpose and condition but lacks information on return values, failure behavior, prerequisites, and overall workflow, making it incomplete for an agent to confidently invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'verified' parameter's gating role, but does not describe artifact_id, remote_provider, remote_path, remote_sha256, or remote_file_id. The parameter names are somewhat self-explanatory, but the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Confirms remote sync for an artifact') and adds a specific behavioral detail ('Transitions to REMOTE_CONFIRMED only if verified=true'). This distinguishes it from sibling artifact tools like artifact.get or artifact.cleanup.
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 given about when to use this tool vs alternatives, prerequisites, or excluded scenarios. The description does not mention any related tools or caution against using it in certain cases, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Lists' implies a safe, read-only operation, but the description does not explicitly state that it only reads and does not modify any state. It also does not disclose any side effects, pagination behavior, or ordering semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that immediately conveys the core purpose. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves significant gaps: it does not explain what the returned list contains, how to interpret the items, or how 'pending' is defined. Parameters are undocumented, making the tool harder to use correctly. The description is too sparse for a tool with two optional parameters and no structured output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either 'limit' or 'older_than_hours'. Since the description is the only source of parameter meaning and it is silent, the agent has no basis for understanding how these optional parameters affect the results.
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 ('Lists'), the resource ('pending artifacts'), and the specific filtering context ('awaiting remote sync confirmation'). It distinguishes this tool from siblings like artifact.get and artifact.confirm_remote_sync by focusing on the pending/unsynced state.
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 is for viewing artifacts that have not yet been confirmed for remote sync, but it does not explicitly state when to use this versus alternatives or provide any exclusionary guidance. Given sibling tools like artifact.confirm_remote_sync, a note about using this before confirming would improve the score.
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 full burden. It discloses sequential opening and bounded traversal, but does not mention error handling (despite the continue_on_listing_error parameter), side effects on the browser session, or what happens after opening listings.
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 that is easy to scan. However, terms like 'Higher-level bounded traversal' are slightly vague and could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no annotations, no output schema), the description is insufficient. It fails to mention return behavior, error handling, or how it interacts with the browser session. The sibling context also suggests more differentiation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters. While parameter names and defaults provide some hints, the description adds no semantic value for browser_session_id, max_listings, continue_on_listing_error, or capture_listing_screenshots.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('enumerates', 'opens each listing sequentially') and clearly indicates the resource (member page listings). It distinguishes from sibling 'enumerate_member_inventory' by implying a deeper traversal that opens each item rather than just listing them.
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 a higher-level traversal but does not explicitly state when to use this over the sibling 'enumerate_member_inventory' or other tools. It mentions 'bounded' suggesting a limit, but no exclusions or alternative recommendations.
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 includes a critical precondition (page_type == LISTING) but does not mention what the extraction returns, whether it navigates or only reads the current page, or how it handles failures or missing prerequisites.
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 consists of two short, front-loaded sentences with no redundant information. Every word contributes to the core purpose and a key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter description coverage, this description is minimal. It omits return value details and parameter behavior, which are necessary for reliable invocation. The basic action and precondition are clear, but the tool is under-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description should compensate by explaining the three parameters (browser_session_id, include_description, include_seller_summary). It does not, leaving the agent to infer meanings from parameter names alone. The description adds no semantic depth 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 clearly states the tool extracts one listing from the current page, using a specific verb and resource. The precondition 'Requires page_type == LISTING' distinguishes it from sibling tools like listing.enumerate_member_inventory and listing.crawl_member_inventory, which operate on multiple listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by requiring page_type == LISTING, telling the agent when the tool is applicable. However, it does not explicitly mention alternatives or when not to use it, though the sibling tool names suggest other listing-related operations.
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 server](https://glama.ai/mcp/servers/grappaheiss/camoufox/badges/card.svg)](https://glama.ai/mcp/servers/grappaheiss/camoufox)

Score Badge

Copy to your README.md:

[![camoufox MCP server](https://glama.ai/mcp/servers/grappaheiss/camoufox/badges/score.svg)](https://glama.ai/mcp/servers/grappaheiss/camoufox)

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/grappaheiss/camoufox'

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