Shade Browser Security MCP

by Atlas-X-AI

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have clear distinct purposes, but there is overlap among the network monitoring tools (browser_network_requests vs browser_network_intercept vs browser_ws_monitor) and the three browser_use_* variants (tor, tunnel, residential) are similar except for the network path. Descriptions help but an agent may struggle to pick the exact right tool in ambiguous situations.
Naming Consistency3/5
All tools are snake_case and most start with 'browser_', but the pattern after the prefix is inconsistent: some use verb_noun (use_tor, solve_challenge), some are noun phrases (network_requests, passive_recon), and one (form_scan) lacks the browser_ prefix. This mixed convention is still readable but not uniform.
Tool Count4/5
18 tools is slightly above the ideal 3-15 range but still manageable for a comprehensive security toolset. Each tool addresses a distinct aspect of browser security and anti-detection, so the count feels justified rather than bloated.
Completeness2/5
The toolset focuses heavily on network routing, monitoring, and stealth features, but omits basic browser lifecycle operations like navigate, screenshot, or close slot. Without a direct way to navigate to a URL (except via raw CDP), the surface is incomplete for practical security testing workflows.
Average 3.3/5 across 18 of 18 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 168 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'private per-slot X display only', which implies isolation and a display restriction, but it does not disclose side effects, coordinate system, or what happens on failure. The behavioral traits are minimally addressed.
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 wasted words. It is front-loaded with the action. However, it is under-specified for the tool's complexity, but that is more of a substance 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?
Despite an output schema being present, the description does not explain the output or the context of the click. It omits details like coordinate system, display handling, and the meaning of 'slot'. For a tool with four parameters and no annotations, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (x, y, slot, display). It vaguely refers to 'per-slot' but does not define the slot parameter or the display parameter. The agent has to guess their meaning and valid values.
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 clicks via OS input, specifying a private per-slot X display. This distinguishes it from browser-level clicking and other sibling tools like browser_cdp_command or browser_use_tunnel. However, it lacks a verb+resource construction like 'simulate' or 'perform', but 'Click' is clear enough.
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 prerequisites, use cases, or exclusions. Sibling tools exist for different purposes, but no comparison is provided.
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 mentions 'raw' which hints at low-level power, but does not disclose potential side effects, safety risks, or required permissions. This is a significant gap for a tool that can execute arbitrary CDP commands.
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 is front-loaded and immediately communicates the tool's core function, though it lacks elaborative detail that would come at the cost of 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?
For a tool that executes raw CDP commands, the description is under-specified. It lacks information about the nature of CDP, safety considerations, or how the output should be interpreted. While the output schema exists, the description still needs to convey the operational context, which it fails to do.
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% coverage with all three parameters (slot, method, params) having descriptions. The description adds no additional meaning beyond the schema, matching the baseline for 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 'Execute a raw CDP command' clearly states the tool's action and object, using the specific verb 'execute' and the resource 'raw CDP command'. It is distinct from sibling tools by being a low-level interface, though it does not explicitly differentiate from alternative higher-level browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 versus the specialized sibling tools such as browser_use_tor or browser_network_intercept. The one-line description provides no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Inject' and 'keep it alive' imply a persistent action, but there is no explanation of side effects, cleanup, required browser state, or whether the injection is reversible. The description adds minimal context beyond 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, front-loaded sentence with no filler words. It delivers the essential action and context in a minimal, scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with no annotations and an output schema that is not shown. It omits prerequisites (e.g., open browser, existing Bitwarden item), the meaning of 'isolated slot', how 'keep it alive' is managed, and any disambiguation from related injection tools. The output schema may cover return values, but the behavior and usage context remain incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or format of the two required parameters, 'slot' and 'bw_item_id'. The phrase 'isolated slot' hints at 'slot', but there is no explicit mapping or additional detail that would help an agent construct correct arguments.
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 ('Inject'), the target resource ('a Bitwarden passkey'), and the specific context ('into an isolated slot'), with an added behavioral clause ('and keep it alive'). This distinguishes it from sibling tools like browser_inject_signer (signer vs. passkey) and browser_webauthn_bypass (bypass vs. injection).
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 offers no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Users are left to infer usage from the tool name and the general context, which is insufficient given the overlapping sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It only states 'passive', which implies non-intrusiveness but does not disclose what data is collected, whether network requests are made, or any side effects. The slot parameter's suggestion to use a Tor-routed slot is an implicit safety cue but is not elaborated.
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 wasted words. It is efficient but slightly under-specified for a complex security tool, making it not quite a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a passive reconnaissance tool, the description is too sparse. It does not explain what the tool outputs, what type of reconnaissance is performed, or any limitations or setup requirements. Even though an output schema exists, the description should provide more context to guide selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter descriptions already explain 'domain' and 'slot' (including the recommendation for a Tor-routed slot). The description adds no new parameter-level information, so baseline 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 'Run passive reconnaissance against a domain' uses a specific verb and resource, and the term 'passive' helps distinguish it from more active or specific browser tools. However, it lacks detail on what reconnaissance entails, so it does not fully differentiate from sibling tools like browser_network_requests.
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 its siblings or what prerequisites exist. It does not mention alternatives or exclusions, leaving the agent to infer appropriate use from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist and the description only names the action and target. It does not disclose whether scanning is read-only, what 'gate controls' means, whether a state is returned, or any side effects; this leaves critical behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is efficiently front-loaded but somewhat terse, lacking any structural aids like bullet points or definitions for jargon.
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?
At one sentence, the description is far too minimal for a tool that operates within a large browser automation context. It fails to convey when to use the scan, what to expect from the output (even if the output schema exists), or how it relates to other browser tools.
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 provides complete descriptions for both parameters, so the description need not add parameter info. However, it adds no extra semantic nuance beyond the schema, making the baseline score 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 a specific verb 'Scan' with a clear resource 'current page' and identifies target artifact types ('fillable form fields', 'gate controls'). It is distinguishable from sibling tools, though 'gate controls' is somewhat vague jargon.
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, prerequisites, or alternatives. It simply states what the tool does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It fails to mention side effects like replacing window.ethereum, the impact on existing providers, whether the injection is persistent, or the security implications of using a private key. It only states the injection action and its MetaMask independence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words, front-loading the central action. It is easily scanned, though it lacks structural depth; however, conciseness itself is good.
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 an output schema, the description omits critical context for a tool that handles a private key. It doesn't explain what the tool returns, whether it activates the provider, or how to undo the injection. No annotations compensate, leaving a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond the schema's own descriptions of slot, chain_id, and private_key. It does not explain how these parameters affect the injected provider.
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 ('inject') and resource ('minimal EIP-1193 wallet provider'). The phrase 'No MetaMask needed' differentiates it from relying on MetaMask and, combined with the name, distinguishes it from the sibling 'browser_inject_passkey'.
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 explicit guidance on when to use the tool versus alternatives such as browser_inject_passkey or simply using MetaMask. The 'No MetaMask needed' line implies a use case but doesn't state prerequisites, exclusions, or scenarios where this tool should be preferred.
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 must carry the full burden of behavioral disclosure. It only mentions that session state preservation is optional, but fails to disclose potential side effects such as disruption of ongoing browser activity, whether the rotation is immediate or takes time, or whether an active tunnel is required. The tool's behavior beyond the core action is largely opaque.
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 two short clauses, front-loading the core action and promptly addressing the optional session preservation. Every word earns its place; there is no waste or 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 lack of annotations and the existence of an output schema, the description is too sparse to fully contextualize the operation. It omits situational context such as prerequisites (e.g., needing an existing tunnel), what the return value indicates, and potential impact on the current browser session beyond cookies/localStorage. The tool appears to be a simple rotation, but the absence of these details leaves the agent under-informed.
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?
Both parameters are already fully described in the schema with 100% coverage: 'slot' is documented as 'CDP slot number currently in use' and 'preserve_session' as 'Save and reload cookies/localStorage across rotation.' The description's phrase 'Optionally preserves session state' adds no new meaning beyond the schema. It does not clarify the cryptic 'slot' parameter, so it adds minimal value beyond the structured 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 states a specific verb and resource: 'Rotate to a new tunnel exit IP.' This clearly distinguishes the tool from sibling tools like browser_use_tunnel or browser_use_tor, which establish a tunnel rather than rotate its exit IP. The action is unambiguous and concisely stated.
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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The only hint is 'Optionally preserves session state,' which indicates a choice about session handling but does not frame when rotation is appropriate or preferred over other IP-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'apply or regenerate' without explaining side effects, persistence, reversibility, or what 'stealth personality' actually changes. The lack of detail on operational impact is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded, and contains no filler. Every word contributes to understanding the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with optional parameters and an output schema, so the description is minimally adequate. However, it lacks behavioral context (what happens when a personality is applied) and usage context, leaving the agent to infer key details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (slot and personality_name), so the description adds little beyond the schema. Baseline of 3 is appropriate because schema coverage is 100%.
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 ('Apply or regenerate') with a clear resource ('a stealth personality profile') and scope ('for a browser slot'). This clearly distinguishes it from siblings like browser_cdp_command or browser_passive_recon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, complementary tools, or scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a significant behavioral trait: it uses prototype patching to log WS frames, which implies modification of browser internals. However, it does not mention side effects, reversibility, or potential detection by websites. With no annotations providing safety hints, this is somewhat insufficient but better than no behavioral disclosure.
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 two short sentences, immediately front-loading the core purpose ('Install WebSocket monitoring') and then adding the method and target. No word is wasted, achieving high clarity in minimal space.
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?
While the tool is simple with one optional parameter and an output schema, the description lacks usage context: no mention of when to use it, how logs are delivered, or whether installation persists. The prototype patching detail gives some context, but the absence of alternative guidance and operational details makes it a 3 rather than higher.
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 contains a single 'slot' parameter with a description 'CDP slot number 0-19', which fully covers its meaning (100% coverage). The tool description adds no additional parameter semantics, but per the baseline for high schema coverage, a score of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool installs WebSocket monitoring and logs all WS frames via prototype patching. This distinguishes it from sibling tools like browser_network_requests and browser_web3_monitor by focusing specifically on WebSocket frame logging. However, it could be more explicit about the primary action (monitoring vs setting up).
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 browser_network_requests or browser_web3_monitor. There are no stated exclusions or prerequisites. This forces the agent to infer use cases from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'launch' and 'through VPN tunnel' with no details about slot auto-assignment, tunnel selection, readiness, errors, or side effects. The agent is left uncertain about what happens after invoking the tool.
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 states the core action and the network path efficiently, making it easy to scan and understand.
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 moderate complexity (2 optional parameters, output schema present), the description is too sparse. It does not explain what a 'browser slot' is, how the returned output relates to the launched browser, or any prerequisites such as tunnel availability. The minimal guidance leaves gaps for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (slot and tunnel_id), achieving 100% schema coverage. The description adds no additional parameter meaning beyond what the schema already offers, 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 uses a specific verb ('Launch') and resource ('a browser slot') with a clear method ('through a Shade VPN tunnel'). It distinguishes this tool from siblings like browser_use_tor and browser_use_residential by specifying the tunnel-based network path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a browser slot over a VPN tunnel is needed, which is a distinct scenario from Tor or residential proxies. However, it provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives. The context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'capture' but the tool name 'intercept' suggests a more active role (e.g., blocking or modifying requests). The description does not disclose whether interception is passive, whether requests are continued or aborted, or if there are side effects on page behavior. This is a significant transparency gap for an interception tool.
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 that is efficient and exactly describes the tool's function. Every word earns its place, with no fluff or 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 complexity (interception behavior, optional parameters, output schema), the description is minimal. It covers the basic purpose but omits important context such as whether interception affects browsing, whether the network domain must be enabled, or how this relates to sibling tools. The presence of an output schema reduces the need to describe return values, but side effects and usage prerequisites remain unaddressed.
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 clear descriptions for each parameter (slot, url_pattern, capture_body). The description adds no extra meaning beyond what the schema already provides; it merely aligns with the capture_body parameter. 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 'Capture network requests with full request/response bodies' clearly states the verb (capture), resource (network requests), and specific scope (full bodies). It distinguishes from sibling browser_network_requests by emphasizing the body capture, making it clear this tool is for intercepting with full payloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing network traffic with bodies but does not explicitly state when to use this over alternatives like browser_network_requests, nor does it provide any exclusions or prerequisites. It gives a clear context but lacks explicit guidance on choosing between 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain what 'premium' means (e.g., cost, limits), the lifecycle of the slot, or any side effects such as session persistence. The description is too thin to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the primary action. It contains no unnecessary details and is appropriately 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 only two parameters, 100% schema coverage, and an output schema, the description is minimally sufficient. However, it lacks contextual detail about when to use this tool over proxy alternatives and what the 'premium' designation entails, leaving clear gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (geo and slot) with 100% coverage. The tool description adds no additional semantic nuance beyond what the schema already states, 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 uses the specific verb 'Launch' and identifies the resource 'browser slot' with a clear differentiator ('residential proxy in a chosen region'). This distinguishes it from sibling tools like browser_use_tor and browser_use_tunnel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for residential proxy needs via the phrase 'residential proxy', but it does not explicitly state when to prefer it over alternatives or provide any exclusions. There is no mention of alternatives or clear when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that it 'logs all wallet RPC calls' but gives no details on side effects of 'installing' monitoring, whether it modifies the existing window.ethereum object, how logs are accessed, or if the behavior is reversible. This is a significant gap for a tool that performs an installation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that immediately convey the core action and purpose. No filler words, and the key functionality is front-loaded. 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?
Given the tool's simplicity (one parameter, output schema present), the description is mostly adequate but leaves gaps about operational context—such as whether monitoring starts immediately, how logs are returned, and whether there are any prerequisites. It is a minimum viable description but lacks depth for a tool that modifies browser behavior.
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 the only parameter 'slot' with a description, so schema coverage is 100%. The description adds no additional meaning about the slot parameter, which aligns with the baseline score of 3 for well-documented schemas.
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 a specific action ('Install window.ethereum monitoring') and its effect ('Logs all wallet RPC calls'). It identifies a distinct resource (window.ethereum) and differentiates from sibling tools like browser_ws_monitor or browser_network_requests by focusing on wallet RPC calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to monitor Ethereum wallet RPC calls) but does not explicitly mention alternatives or exclusions. It lacks guidance on scenarios where browser_network_requests or browser_inject_signer might be more appropriate, leaving usage partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that it creates a virtual authenticator via CDP, but fails to mention side effects on browser state, persistence, cleanup, or any setup requirements. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with zero filler, front-loaded with the core action and followed by the practical effect. 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?
The tool has a well-documented schema and an output schema, so basic invocation details are covered. However, the description lacks usage context, caveats about the 'most' WebAuthn claim, and any relation to sibling tools, leaving open questions about when and how to apply this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides thorough descriptions for both parameters (slot range and rp_id examples/defaults), so the description adds no parameter-specific meaning. Since schema coverage is 100%, 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 clearly states that the tool creates a virtual WebAuthn authenticator via CDP, using a specific verb and resource. It also communicates the intended effect ('Bypasses most WebAuthn'), which distinguishes it from sibling tools like browser_inject_passkey.
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 'Bypasses most WebAuthn' implies when the tool might be useful, but there is no explicit guidance on when to use it versus alternatives such as browser_inject_passkey or browser_solve_challenge. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of transparency. It only discloses that requests are 'recent' and implies a read operation, but doesn't address side effects, scope, or limitations (e.g., whether it clears the log or only tracks CDP slot).
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 with the verb 'Get', and the parenthetical adds relevant context without 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?
The tool has an output schema, so return values are covered. However, the description lacks behavioral detail and usage context that would be especially important given no annotations, making it only minimally 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?
Both parameters have descriptions in the schema (coverage 100%), so the baseline is 3. The description adds no parameter semantics beyond the schema, though it could clarify 'slot' context.
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?
Description uses specific verb 'Get' with resource 'recent network requests', clearly stating the tool's function. It is distinguished from sibling tools like browser_network_intercept which focuses on interception, 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?
States a clear use case: 'useful for debugging API calls', which signals when the tool is appropriate. However, it does not explicitly mention alternatives or when not to use, leaving some room for ambiguity compared to the ideal.
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 for behavioral disclosure. It only states the launch action and Tor routing but does not mention possible side effects, prerequisites, speed implications, or what happens to the slot. Minimal behavioral disclosure.
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 concise sentence that is front-loaded with the action and destination, with no filler or redundant phrasing. Every word contributes value.
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?
The tool is simple (1 optional param, output schema present), and the description covers the core purpose and context. However, it lacks usage alternatives and behavioral caveats, leaving the description somewhat under-specified for a launch tool that may have network implications.
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 covers 100% of the single parameter (slot) with a clear explanation, and the tool description adds no additional parameter semantics beyond the schema. 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 clearly states a specific action ('Launch a browser slot through Tor') with a clear resource and purpose ('.onion browsing'). It distinguishes from sibling tools like browser_use_residential or browser_use_tunnel by specifying Tor and .onion.
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 a clear use case ('.onion browsing') which implies when this tool is appropriate. However, it does not explicitly contrast with alternative sibling tools or state when not to use it, lacking exclusion guidance.
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 states what is checked (IP, DNS, WebRTC leaks) but does not mention side effects, permissions, whether the operation is read-only, or how results are reported. The term 'check' implies a safe read, but it is not explicit.
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 two short sentences, front-loaded with the core function, and earns every word. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple tool with one optional parameter and an output schema. It clearly ties into the sibling workflow (post-tunnel-assignment check) and names the leak types checked. Minor gaps include prerequisites and behavior on leak detection, but the output schema likely covers result details.
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 for its only parameter ('CDP slot number 0-19'), which is clear. The tool description adds no additional meaning beyond the schema, 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 clearly states the tool's function: checking for IP, DNS, and WebRTC leaks. This specific verb+resource distinguishes it from sibling tools like browser_use_tunnel and browser_rotate_ip, which manage tunnels rather than verify them.
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 explicitly states when to use the tool: 'Run after every tunnel assignment.' This gives clear contextual guidance. It does not mention alternatives or when not to use, but the strong directive implies a specific workflow.
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 responsibility. It discloses the key behavior of using an external solver and that it is premium, but lacks details on side effects, network interactions, or prerequisites. This is moderately transparent but incomplete.
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 that conveys the essential purpose and method without unnecessary words. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough given that an output schema exists and parameter semantics are fully covered. Slight gaps exist around prerequisites (e.g., needing an active browser slot) but these are minor given the tool's simple nature.
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 already documents all parameters. The description does not add any additional meaning beyond the schema, aligning with the baseline score of 3.
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 ('solve') with a clear resource ('Cloudflare Turnstile challenge') and adds context about using an external solver. This distinguishes it from sibling tools, none of which mention challenge solving.
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 phrase 'detected Cloudflare Turnstile challenge' clearly indicates when to use this tool. However, it does not explicitly state alternatives or when not to use it, though siblings don't show similar functionality.
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:

[![shade-browser-security MCP server](https://glama.ai/mcp/servers/Atlas-X-AI/shade-browser-security/badges/card.svg)](https://glama.ai/mcp/servers/Atlas-X-AI/shade-browser-security)

Score Badge

Copy to your README.md:

[![shade-browser-security MCP server](https://glama.ai/mcp/servers/Atlas-X-AI/shade-browser-security/badges/score.svg)](https://glama.ai/mcp/servers/Atlas-X-AI/shade-browser-security)

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/Atlas-X-AI/shade-browser-security'

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