Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@QA Agent Pro test the checkout flow on our e-commerce site and capture any errors"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Stop testing manually. Let AI do the boring work.
QA Agent Pro is a Model Context Protocol (MCP) server that gives your AI (Claude, Cursor, etc.) eyes and hands to browse the web. It turns your AI into a tireless QA Engineer that can test your website 24/7.
📱 Mobile Simulation: Test your responsive design on iPhone, Pixel, or iPad views instantly.
🚨 Bug Hunter: Automatically captures hidden JavaScript errors (Console Logs) that break your app.
📸 Visual Proof: Takes screenshots of every step, so you have evidence of what works (and what doesn't).
⚡ Zero Config: Connects to Claude Desktop in seconds.
Related MCP server: Chrome MCP Docker
Your AI gains these superpowers:
navigate(url): Open any website in a real Chrome browser.
click(selector) & type(selector, text): Interact like a real user.
set_viewport(width, height, mobile): [PREMIUM] Simulate mobile devices.
get_console_logs(): [PREMIUM] Extract error logs for debugging.
screenshot(name): Capture visual evidence.
Clone this repo:
git clone https://github.com/yourusername/qa-agent-mcp.git
cd qa-agent-mcpInstall & Build:
npm install && npm run buildAdd to Claude Desktop Config:
{
"mcpServers": {
"qa-agent": {
"command": "node",
"args": ["/absolute/path/to/qa-agent-mcp/build/index.js"]
}
}
}This tool is available for:
Personal Use: Free for open source projects.
Commercial License: $49 (Lifetime access).
Corporate/Agency Use: If you are using this tool to test client websites or commercial products, you must purchase a license.
Run the included verification script to see the agent in action (Mobile + Desktop test):
node build/verify-qa.jsBuilt with ❤️ by [Your Name]
Click an element on the page identified by a CSS selector
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the element to click |
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 the action ('click') but doesn't describe what happens after clicking (e.g., page navigation, form submission, error handling), whether it requires specific page states, or any side effects like waiting for page loads. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation action with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure status), error conditions, or behavioral nuances like click simulation versus actual browser events, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'selector' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (it merely repeats 'CSS selector'), so it meets the baseline of 3 where the schema does the heavy lifting without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('click') and target ('an element on the page identified by a CSS selector'), using a precise verb+resource combination. It effectively distinguishes this tool from sibling tools like 'type' (which inputs text) or 'navigate' (which changes URLs), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (e.g., whether a page must be loaded first), exclusions (e.g., when not to click certain elements), or comparisons to sibling tools like 'get_text' or 'screenshot'. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all console logs captured during the session
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that logs are 'captured during the session', implying real-time or session-specific data, but lacks details on format, volume, permissions, or potential side effects like performance impact. This leaves significant gaps for a tool that retrieves data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core action and resource without any wasted words. It's efficiently structured and easy to parse, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'console logs' entail (e.g., error messages, browser logs), the return format, or any limitations, which is inadequate for a tool that retrieves session data without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't add unnecessary param details, earning a high score for not overloading with irrelevant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all console logs captured during the session'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_text' or 'screenshot', which might also retrieve session data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_text' or 'screenshot', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the text content of an element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states what the tool does but doesn't disclose error handling, performance characteristics, whether it returns formatted/raw text, or if it requires specific page states. This is inadequate for a tool with potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that likely interacts with a browser/page context, the description is incomplete. It doesn't explain return values, error conditions, or dependencies on other tools (e.g., 'navigate' first), leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the 'selector' parameter fully. The description adds no additional meaning about parameter usage beyond implying it extracts text from elements matching the selector, which aligns with but doesn't enhance the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'text content of an element', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_console_logs' or explain what type of element it works on (DOM element vs. other).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (e.g., needing a page to be loaded), when not to use it, or how it relates to siblings like 'click' or 'navigate'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the screenshot file (without extension) |
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 the action but doesn't cover aspects like file format (e.g., PNG, JPEG), save location, permissions needed, or error handling. This leaves significant gaps for a tool that performs a system-level operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a system operation with potential side effects), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., file path, success status) or behavioral details like format or errors, leaving critical gaps for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'name' parameter documented as 'Name for the screenshot file (without extension)'. The description adds no additional parameter semantics beyond this, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Take a screenshot') and the target ('of the current page'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_text' or 'set_viewport', which might also involve page content manipulation, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_text' for text extraction or 'set_viewport' for viewport adjustments. It lacks explicit context, exclusions, or prerequisites, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the browser viewport size (e.g., for mobile simulation)
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Viewport width in pixels | |
| height | Yes | Viewport height in pixels | |
| mobile | No | Whether to simulate a mobile device |
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 states the tool sets the viewport size and hints at mobile simulation, but lacks critical behavioral details: it doesn't specify if this affects current page rendering, requires an active browser context, has side effects (e.g., page reload), or error conditions (e.g., invalid dimensions). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Set the browser viewport size') and includes a concise, relevant example. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly scannable and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like how the viewport change is applied, what happens to the current page, error handling, or return values. For a tool that modifies browser state, more context is needed to ensure safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'width', 'height', and 'mobile' parameters. The description adds marginal value by linking 'mobile simulation' to the 'mobile' parameter, but doesn't provide additional semantics beyond what the schema already documents (e.g., no guidance on typical width/height values, interaction between 'mobile' and dimensions, or default behaviors). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('browser viewport size'), with the parenthetical example providing additional context about mobile simulation. It distinguishes from siblings like 'navigate' or 'screenshot' by focusing on viewport configuration rather than navigation or capture. However, it doesn't explicitly differentiate from all siblings (e.g., it could mention this is for visual/rendering adjustments vs. interaction tools like 'click' or 'type').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with the example 'e.g., for mobile simulation', which implies a use case but doesn't specify when to use this tool versus alternatives or prerequisites. There's no explicit when/when-not guidance, no mention of dependencies (e.g., requires a browser session), and no comparison to sibling tools like 'navigate' for page loading or 'screenshot' for capturing the viewport after setting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into an input field identified by a CSS selector
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector of the input field | |
| text | Yes | Text to type |
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 the action ('Type text') but fails to describe critical behaviors such as whether it simulates keystrokes, clears existing content, handles errors if the selector is invalid, or requires the page to be in a specific state. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and target, with zero wasted words. It is appropriately sized for a simple tool with two parameters, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation action with no annotations and no output schema), the description is incomplete. It does not address behavioral aspects like error handling, side effects, or return values, which are crucial for an agent to use the tool correctly in a web automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('selector' and 'text') fully documented in the input schema. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Type text') and target resource ('into an input field identified by a CSS selector'), using precise verbs and distinguishing it from sibling tools like 'click' or 'get_text'. It directly communicates what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'click' or 'set_viewport', nor does it mention prerequisites such as needing a page to be loaded. It lacks explicit context for usage decisions, leaving the agent to infer based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
clickget_console_logsget_textnavigatescreenshotset_viewporttypeEach tool has a clearly distinct purpose with no overlap: click, get_console_logs, get_text, navigate, screenshot, set_viewport, and type all target specific, non-overlapping browser automation tasks. An agent can easily tell them apart based on their unique functions.
All tool names follow a consistent verb_noun or verb pattern with snake_case: click, get_console_logs, get_text, navigate, screenshot, set_viewport, and type. This predictable naming scheme makes the set easy to understand and use.
With 7 tools, the count is well-scoped for a QA/browser automation server. Each tool earns its place by covering essential actions like navigation, interaction, and debugging without being overwhelming or too sparse.
The toolset covers core QA workflows: navigation, interaction (click, type), content retrieval (get_text, get_console_logs), and configuration (set_viewport, screenshot). Minor gaps exist, such as missing tools for handling alerts or cookies, but agents can work around these with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run multi-step tasks in a real Chrome browser: persistent environments, live view, human takeover.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/samusilv/qa-agent-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
