stealth-agent-browser-mcp

by ykshah1309

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct action: scrolling, waiting, navigation, snapshot, clicking, typing, selecting, tab management, JS evaluation, proxy configuration, and captcha solving. No overlapping purposes.
Naming Consistency4/5
Tools consistently use the browser_ prefix with verb or verb+noun patterns (e.g., browser_navigate, browser_set_proxy). The exception is browser_tabs (noun) which deviates slightly but remains clear.
Tool Count5/5
13 tools cover the core browser automation tasks without being excessive. Each tool has a clear role, and the count is well-scoped for the server's purpose.
Completeness4/5
Covers navigation, interaction, proxy management, and captcha solving comprehensively. Minor gaps exist, such as missing back/forward navigation or visual screenshot (snapshot returns AOM only), but most workflows are supported.
Average 3.5/5 across 13 of 13 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only lists actions but does not disclose behavioral traits such as side effects (e.g., closing a tab loses state), prerequisites (e.g., index required for switch/close), or authorization needs. The actions are named but their exact behavior is vague.
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 extremely concise (one line). While concise, it sacrifices clarity and structure. A list of actions without elaboration is too terse to be fully helpful, but it does front-load the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about return values, prerequisites, and action-specific behavior. For a tool with 3 parameters and multiple actions, this is insufficient. No output schema or annotations exist to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not add meaning beyond the schema. The description lists actions but does not explain the roles of 'url' and 'index' parameters, leaving ambiguity about which actions require them.
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 'Manage browser tabs: list, new, close, switch.' It specifies both the resource (tabs) and the actions, distinguishing it from sibling tools like browser_navigate or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, there is no mention that browser_navigate is for changing the current tab's URL, while browser_tabs with action 'switch' changes the active tab. The description lacks context for when to use each action.
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, and the description lacks behavioral details such as whether it clears previous selections, supports multiple selections (implied by array but not stated), or waits for elements. The agent has no information on side effects or error handling.
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 one short sentence, which is concise and front-loaded with the action. However, it lacks structure and could benefit from additional details without being verbose.
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 output schema, no annotations, and minimal parameter explanation, the description is incomplete. It does not describe return values, error conditions, or behavioral nuances like handling of multiple selections or invalid references.
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, but it only says 'addressed by ref' and 'Select one or more options'. It does not explain what 'ref' is (selector format) or what 'values' represent (option values, labels, or indices). Minimal added meaning.
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 verb 'Select' and the resource 'options in a <select>' addressed by 'ref'. It distinguishes from sibling tools like browser_click or browser_type which do different actions. However, it does not clarify what 'ref' refers to (e.g., CSS selector), slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or when not to use it. The description does not mention that it is specifically for <select> elements, nor does it exclude other uses. No prerequisites or context 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?
No annotations provided. Description lacks details on timeout behavior, return value, polling mechanism, or what happens when both conditions are true.
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?
Single sentence, no redundancy, well-formed.
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?
No output schema, no annotations, and description omits return value, error handling, and behavior edge cases. Incomplete for a tool with 3 parameters and implicit complexity.
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 67% (low), and the tool description adds no extra meaning beyond the schema descriptions. Does not explain how 'ref' resolves or what 'visible element' means.
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?
Clear verb 'wait' and specific conditions: text appearance or visible element. Distinct from siblings like browser_click or browser_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus alternatives or when not to use. Does not explain when to choose text vs ref condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals a key behavioral trait: the Bezier path with hesitation to defeat trajectory analyzers when SAB_HUMAN_MOUSE is true. Since no annotations are provided, this disclosure is valuable, though it omits other traits like waiting, retry logic, or failure outcomes.
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?
Two efficient sentences: first states purpose, second adds critical behavioral detail. No unnecessary words, information is front-loaded.
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?
Covers purpose and a key behavioral trait, but lacks details on parameters (button, clickCount), preconditions (snapshot dependency), error handling, and output (none provided). For a simple click tool with no annotations, the description is adequate but has notable gaps.
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 coverage is 33% (only ref described). Description adds minimal parameter context: it mentions ref addressing but does not explain button (left/right/middle) or clickCount (double-click, triple-click). The description does not compensate for the low 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?
Clearly states 'Click an element addressed by its ref', identifying the action and target. Distinguishes from sibling tools like browser_type (typing) and browser_select (selection) but doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., browser_type or browser_select). The mention of SAB_HUMAN_MOUSE suggests a scenario for evasion, but no explicit when-to-use or when-not-to-use advice.
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 full burden. It discloses the need for a restart and the constraint on existing contexts, but omits details on authentication requirements, destructiveness, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It front-loads the main action and immediately provides the critical follow-up step.
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 has three parameters, no output schema, and no annotations, the description is adequate but incomplete. It explains the update and restart requirement but lacks parameter semantics and comprehensive behavioral context.
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 has low description coverage (33% with only 'server' described). The tool description does not explain any parameters beyond the general 'proxy config', failing to add meaning for 'username' or 'password'.
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 'Update the proxy config', which is a specific verb and resource. It is distinct from the sibling 'browser_set_proxy_pool' by name, but no explicit differentiation is provided.
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 advises calling 'browser_restart' after setting the proxy and mentions a browser-level constraint, implying a specific workflow. However, it does not discuss when to use this tool versus alternatives like 'browser_set_proxy_pool'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'type into' but does not disclose behavioral details like waiting for element, clear behavior (though default in schema), keyboard event simulation, or error handling when ref not found.
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?
Single sentence, front-loaded with purpose, no redundant information. Every word is meaningful.
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?
For a simple typing action, the description covers the basic purpose but omits critical context like whether it waits for the element, what happens if ref is invalid, and how special keys are handled. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters have descriptions). The description adds the context that ref addresses an input/textarea, but doesn't explain the 'text' parameter. Baseline 3 due to high coverage, but no extra value beyond 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 action ('type') and the target ('input or textarea addressed by ref'). It distinguishes from sibling tools like browser_click (click) and browser_select (select).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites, and no conditions for appropriate usage. The description lacks any context about when to type versus when to use other browser interaction 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 provided, so description carries full burden. It describes the process but omits behavioral details like rate limits, costs, timeouts, or what happens on failure. The dependency on env vars (CapSolver/2Captcha) is mentioned but not explained.
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 that efficiently conveys the main workflow. It is clear and front-loaded with the tool's role, though slightly dense with multiple clauses.
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?
No output schema exists, but description does not explain return values (e.g., success flag or token). Input parameters are well-covered. Absence of failure/error handling info and provider configuration details makes it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the description adds little beyond schema descriptions (e.g., 'Override auto-detection' for type). Baseline 3 applies as schema already documents parameters adequately.
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 clearly states the tool is a fallback captcha solver for Turnstile/hCaptcha/reCAPTCHA, with specific steps: detect, submit to provider, poll, inject. Verb and resource are explicit, and it is distinct from all sibling 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'fallback' implies usage when other methods fail, but no explicit guidance on when to use this tool versus alternatives, nor when not to use it. No mention of prerequisites like provider configuration beyond env var names.
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?
Discloses that execution is observable by page scripts, which is a key behavioral trait. Without annotations, the description should provide more about error handling, return value, or side effects, but it does not.
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?
Two concise sentences, front-loaded with the core purpose. Every sentence provides unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high schema coverage, single parameter, and no output schema, the description adequately covers purpose and usage guidelines. It could improve by noting that the tool returns the expression's evaluated result, but overall is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The tool description adds minimal value beyond the schema, merely restating the same information. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it evaluates a JS expression in the page's main execution world. Verb 'evaluate' and specific resource differentiate it from sibling tools that perform other browser actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use sparingly and prefer AOM + action tools, providing clear when-to-use guidance. However, it lacks explicit exclusions or detailed alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by stating that a snapshot is returned after navigation and that 'aom' mode is the cheapest. This discloses expected behavior beyond the input schema, though it could detail side effects like page state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and return value. Every word contributes to clarity, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description only mentions a 'snapshot' without specifying its content or structure. For a navigation tool, this is adequate but leaves the agent without full understanding of what the snapshot contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enriches the 'mode' parameter by explaining 'aom' is cheapest and 'hybrid' adds a Set-of-Mark annotated screenshot. This adds practical meaning beyond the schema's enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'navigate' and the resource 'active session's page to a URL'. It also mentions the return value (a snapshot), which distinguishes it from sibling tools like browser_click or browser_type.
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 this tool versus alternatives. The description does not mention when not to use it or provide any context for selection among siblings, which are numerous and distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the deltaOnly behavior and its effect on output ('(no change)' if nothing new). However, it does not mention scrolling mechanics, boundary conditions, or what happens if the page is not fully loaded.
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?
Two short sentences that are front-loaded with the main purpose. Every sentence adds value with no redundancy. Highly efficient.
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 3 parameters, no annotations, and no output schema, the description covers the core functionality but omits details about scrolling behavior, pixel amounts, direction options, and return format structure. Adequate but with clear gaps.
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 only 33% (deltaOnly described). The description adds value by explaining deltaOnly's behavior, but it does not describe the 'pixels' or 'direction' parameters, which remain undocumented. The description partially compensates for low coverage.
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 ('Scroll and return') and the output format ('Readability-extracted Markdown view'). It uniquely identifies the tool among siblings which are different browser actions (click, type, navigate, etc.).
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 scrolling and reading content but does not explicitly state when to use this tool over alternatives like 'browser_snapshot' or 'browser_eval'. No when-not or alternative usage guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what each mode returns (YAML for aom, screenshot with overlays for hybrid) and implies read-only snapshot behavior. Lacks explicit statement about non-destructiveness or performance costs, but sufficient for a snapshot 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?
Two sentences, front-loaded with primary purpose, then details about modes. No redundant words; every sentence adds 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?
With no output schema, description partially explains return values (aom and hybrid) but omits 'vision' mode return. Lacks complete coverage of all modes despite having only one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers mode parameter with enum values and descriptions (100% coverage). Tool description adds useful context like 'token-lean' and 'Set-of-Mark screenshot', but 'vision' mode is only described in schema, not in main description.
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?
Clearly states 'Take a snapshot of the current page' with specific verb and resource. Lists three distinct modes, differentiating from sibling tools like browser_scroll_read or browser_click which do other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites or use cases relative to siblings like browser_scroll_read for reading text or browser_wait_for for waiting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that changes are deferred until restart and mentions sticky session support via environment variable, which are important behavioral traits. However, it does not detail error conditions or immediate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then adding crucial timing and sticky session info. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameter set, the description adequately covers when effect applies and sticky session support. It could mention required permissions or error handling, but overall it is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions. The description adds context about sticky sessions and runtime replacement, enhancing understanding beyond the schema. Baseline 3 raised due to this additional 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?
The description explicitly states the action ('Replace the residential proxy pool') and the context ('at runtime'), clearly distinguishing it from sibling tools like browser_set_proxy which likely handles individual proxies.
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 informs that changes take effect after 'browser_restart' and supports sticky sessions, providing clear usage context. It does not explicitly list when not to use, but for a simple configuration tool this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states that the tool closes the active session and starts a fresh one, which implies destructiveness (session state is lost). This is sufficient for a restart tool. No contradictions.
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 concise sentences. The first sentence states the main action, and the second adds a crucial use case. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete. It explains the tool's purpose, the fact that it uses current config, and a key scenario (after set_proxy). This is all needed for a simple restart tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The baseline for 0 parameters is 4. The description does not need to add parameter semantics since there are none.
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: close the active browser session and start a fresh one. This distinguishes it from sibling tools like browser_navigate (navigates within same session) and browser_set_proxy (changes proxy, but requires restart). The verb 'restart' and resource 'browser session' are specific.
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 notes that this tool is required after 'browser_set_proxy' to route new requests through the proxy. This provides clear context for when to use it. However, it does not mention any scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![stealth-agent-browser-mcp MCP server](https://glama.ai/mcp/servers/ykshah1309/stealth-agent-browser-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ykshah1309/stealth-agent-browser-mcp)

Score Badge

Copy to your README.md:

[![stealth-agent-browser-mcp MCP server](https://glama.ai/mcp/servers/ykshah1309/stealth-agent-browser-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ykshah1309/stealth-agent-browser-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ykshah1309/stealth-agent-browser-mcp'

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