Skip to main content
Glama
parajuliminiyan

QA Automation MCP Server

by parajuliminiyan
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

QA Automation MCP Server

An AI-powered QA automation tool built on the Model Context Protocol (MCP). It crawls web pages, generates Playwright-based pytest tests using an LLM, runs them, and automatically heals failing tests — all driven by natural language instructions.

How It Works

User Instruction
      │
      ▼
 crawl_page(url)
      │  Headless Chromium extracts all interactive elements
      ▼
write_test(crawl_data, instruction, output_dir)
      │  Groq LLM generates a pytest + Playwright test file
      ▼
 run_test(crawl_data, output_dir)
      │  Pytest executes the generated test
      │
      ├── PASS → HTML report + text summary
      │
      └── FAIL (locator/timeout error)
              │
              ▼
         Auto-Healer
              │  Groq rewrites the broken locators
              ▼
         Re-run test
              │
              └── HTML report + text summary (marked "healed")

Related MCP server: QAcito

Features

  • Page Crawling — Extracts inputs, buttons, and links with CSS selectors, XPaths, and metadata

  • AI Test Generation — Converts a plain-English instruction + crawl data into a complete pytest test file

  • Automated Execution — Runs tests programmatically with pytest and captures all output

  • Auto-Healing — Detects locator/timeout failures and sends the broken test back to the LLM for repair, then re-runs automatically

  • Rich Reporting — Generates an HTML report with screenshots and a text summary; opens in browser automatically

  • Headless or Headed — Browser is headless by default; pass show_browser=true to watch it run

Architecture

MCP-server/
├── main.py            # MCP server entry point and request dispatcher
├── pyproject.toml     # Project metadata and dependencies
├── .env               # API keys (not committed)
└── src/
    ├── tools.py       # MCP tool definitions (schemas exposed to the client)
    ├── handlers.py    # Request handlers that wire tools to logic
    ├── crawler.py     # Playwright-based page crawling
    ├── writer.py      # LLM-powered test code generation
    ├── runner.py      # Pytest execution and result parsing
    ├── healer.py      # Auto-healing logic for failing tests
    └── reporter.py    # HTML and text report generation

MCP Tools

The server exposes three tools to any MCP-compatible client.

crawl_page

Crawls a URL and returns structured data about all interactive elements on the page.

Parameter

Type

Description

url

string

The page URL to crawl

Returns: JSON with title, inputs, buttons, and links, each containing locator strategies (CSS selector, XPath) and metadata.

write_test

Generates a pytest + Playwright test file from crawl data and a plain-English instruction.

Parameter

Type

Description

crawl_data

string

JSON output from crawl_page

instruction

string

What to test, e.g. "submit the login form"

output_dir

string

Root directory where test files will be saved

show_browser

boolean

Show the browser during execution (default: false)

Returns: Path to the generated test file at {output_dir}/generated_tests/test_*.py.

run_test

Executes the generated test and returns a report. Automatically attempts to heal locator/timeout failures.

Parameter

Type

Description

crawl_data

string

JSON from crawl_page (used for healing)

output_dir

string

Project root directory

test_file

string

Path to test file (optional; defaults to last generated)

Returns: Text summary + path to the HTML report at {output_dir}/test_results/report_*.html.

Prerequisites

  • Python 3.12+

  • uv (recommended) or pip

  • A Groq API key

  • Playwright browsers installed

Installation

1. Clone the repository

git clone <repo-url>
cd MCP-server

2. Install dependencies

uv sync

Or with pip:

pip install -e .

3. Install Playwright browsers

uv run playwright install chromium

4. Create a .env file

GROQ_API_KEY=your_groq_api_key_here

Running the Server

The server communicates over stdio, which is the standard transport for MCP clients like Claude Code.

uv run python main.py

Connecting to Claude Code

Add the server to your Claude Code MCP configuration (.claude/settings.json or ~/.claude/settings.json):

{
  "mcpServers": {
    "qa-automation": {
      "command": "uv",
      "args": ["run", "python", "main.py"],
      "cwd": "/absolute/path/to/MCP-server"
    }
  }
}

Once connected, you can drive the entire QA workflow through natural language in Claude Code:

"Crawl https://example.com, then write a test that fills in the search box and clicks Submit, and run it."

Generated Output

Each test run produces the following structure inside output_dir:

{output_dir}/
├── generated_tests/
│   └── test_<slug>.py          # Generated pytest test file
├── test_results/
│   └── report_YYYYMMDD_HHMMSS.html   # HTML report with screenshot
└── result.png                  # Screenshot from the last test run

The HTML report is opened automatically in your default browser after each run.

Auto-Healing

When a test fails due to a locator or timeout error, the healer:

  1. Parses the pytest output to identify the broken locator

  2. Sends the original test code, the error, and the fresh crawl data to the LLM

  3. Receives a rewritten version with corrected selectors (get_by_role, get_by_text, or CSS)

  4. Saves the patched file and re-runs the test

  5. Marks the final report with healed: true

Only one healing attempt is made per run. Logic errors (wrong assertions, incorrect flow) are not healed automatically.

Dependencies

Package

Purpose

mcp / fastmcp

MCP server framework

playwright

Browser automation

pytest

Test execution

pytest-playwright

Playwright fixtures for pytest

groq

LLM API for test generation/healing

python-dotenv

.env file loading

httpx

Async HTTP client

pydantic

Data validation

LLM Configuration

  • Provider: Groq

  • Model: llama-3.3-70b-versatile

  • Temperature: 0.3 for test generation, 0.1 for healing (tighter, more deterministic)

To switch models or providers, update src/writer.py and src/healer.py.

Limitations

  • Auto-healing only addresses locator and timeout errors, not test logic errors

  • Only one healing attempt per test run

  • Authentication and multi-step login flows are not handled automatically

  • Hardcoded to Groq's llama-3.3-70b-versatile model

License

MIT

Available Tools

3 tools
crawl_pageA

Crawl a webpage and extract all interactive elements like inputs, buttons and links with their locators. Always call this first before writing a test.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe full URL of the webpage to crawl.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It mentions extraction of interactive elements but does not discuss read-only nature, error handling, timeouts, or potential side effects. The lack of detail leaves some transparency gaps.

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 long, with the first defining the action and the second providing usage guidance. Every word is necessary and impactful, with no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, no nested objects, no output schema), the description covers the essential: what it does and when to use it. It lacks detail on output format or error behavior, but for a straightforward crawling tool, it is nearly 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?

There is only one parameter (url) with 100% schema description coverage. The tool description adds context that the URL is for crawling, but does not provide additional semantic meaning beyond the schema's 'The full URL of the webpage to crawl.' Baseline score 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?

The description clearly states the verb 'Crawl' and the resource 'a webpage', and specifies it extracts interactive elements like inputs, buttons, links with locators. It also distinguishes itself from sibling tools by saying 'Always call this first before writing a test.'

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 usage directive: 'Always call this first before writing a test.' This implies it is a prerequisite for write_test and run_test. However, it does not explicitly state when not to use it or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_testA

Run the generated pytest Playwright test. Automatically heals the test if it fails due to a locator error. Always call write_test first.

ParametersJSON Schema
NameRequiredDescriptionDefault
crawl_dataYesThe crawl data returned by crawl_page as a JSON string. Needed for auto-healing.
output_dirYesThe absolute path of the project the user is currently working in. Must be the same value passed to write_test. Use your working directory context — never use the MCP server's own directory.
test_fileNoAbsolute path to the test file to run. Use the path returned by write_test. If omitted, falls back to test_generated.py.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Mentions auto-healing on locator error, which is a key behavioral trait beyond a simple 'run'. However, no annotations are present; the description does not cover other behaviors such as error handling for non-locator failures, file modifications, or permissions requirements.

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 main purpose and key behavior. Every sentence adds value. No unnecessary 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?

For a tool with 3 parameters and no output schema, the description covers the main purpose and ordering. Lacks details on return values or side effects, but the scope is relatively simple and the schema covers parameters well.

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 all parameters well described; the description adds no additional param-specific meaning beyond what the schema provides. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs a generated pytest Playwright test and distinguishes it from siblings (crawl_page, write_test) as the execution step. The verb 'Run' directly indicates the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Always call write_test first', providing clear ordering. Does not explicitly mention when not to use or alternatives, but the required precedence is clear in context of siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

write_testA

Generate a pytest Playwright test based on crawl data and a user instruction. Always call crawl_page first to get the crawl_data. Returns the path to the generated test file — pass it as test_file when calling run_test.

ParametersJSON Schema
NameRequiredDescriptionDefault
crawl_dataYesThe crawl data returned by crawl_page as a JSON string.
instructionYesWhat the test should do.
output_dirYesThe absolute path of the project the user is currently working in — this is where tests and reports will be saved. Use your working directory context to determine this. In Claude Code CLI this is the directory you were launched from. In VS Code it is the workspace root. Never use the MCP server's own directory. Never ask the user for it.
show_browserNoIf true the browser opens visibly during the test. Default is false.

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description discloses the return value (file path) and prerequisite (crawl_data), but does not mention side effects, error conditions, or required permissions. Acceptable but could be more thorough.

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 with no wasted words. Front-loaded with the primary action ('Generate a pytest Playwright test'). Efficiently communicates workflow and return value.

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?

No output schema exists, but the description explains the return value. Parameter descriptions are comprehensive. Workflow with sibling tools is clearly explained. Could mention error handling or validation, but overall sufficient for an agent.

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 100% of parameters with descriptions. The tool description adds value by explaining that output_dir should be the current project directory and that crawl_data comes from crawl_page, complementing the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a pytest Playwright test from crawl data and an instruction, and distinguishes it from siblings by specifying a workflow order: crawl_page first, then this, then run_test.

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 call crawl_page first and mentions how the output (test_file) is used in run_test. Lacks explicit when-not-to-use but the workflow context provides adequate guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a distinct and clear purpose: crawl_page extracts elements, write_test generates tests, run_test executes them. No overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: crawl_page, write_test, run_test. Predictable and clean.

Tool Count5/5

Three tools perfectly cover the core workflow of a QA automation server: crawl, write, run. Not excessive, not insufficient.

Completeness4/5

The essential workflow is complete, but missing test management tools (e.g., delete, list) or debugging utilities. Minor gap.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • QAcito

    dpaul20
    A
    license
    Not graded
    quality
    B
    maintenance
    Autonomous QA platform powered by Claude + Playwright that allows AI to write, run, and fix tests for any project.
    MIT

  • qa-ai-agents

    abchahal
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables automated QA testing by running a pipeline of AI agents that generate test scenarios, architect test layers, write Playwright tests, and review code, all grounded in feature requirements and API contracts.

Latest Blog Posts

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/parajuliminiyan/PlaywrightMCP-Server'

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