A
licenseB
qualityD
maintenanceA Model Context Protocol server that enables automated end-to-end testing with LLMs using Playwright's accessibility tree rather than pixel-based inputs.
1
2
Apache 2.0
ForgeQA AI
ForgeQA AI
ForgeQA AI is a licensed, locally run Playwright end-to-end testing MCP server for Claude Desktop and Cursor. It helps AI coding agents inspect semantic accessibility structure, validate role-based browser workflows with explicit outcome assertions, and compile reviewed flows into reusable Playwright specifications.
Tools
scan_dom_accessibilityopens a supplied URL in a fresh headless Chromium session and returns a structured accessibility-tree snapshot with meaningful roles, names, and states.dry_run_qa_flowexecutes role-based browser interactions and outcome assertions, then returns a step-by-step pass/fail report.compile_playwright_specconverts reviewed actions and assertions into a reusable Playwright E2E specification in the localtestsdirectory.
Related MCP server: browser-devtools-mcp
Supported interactions and assertions
Click, fill, check, select options, and press keys.
Verify visible and hidden elements.
Verify exact or partial text.
Verify input values and checked states.
Verify final URL outcomes.
Requirements
Node.js 20 or newer. Use the current Node.js LTS release.
Claude Desktop or Cursor with MCP support.
Playwright Chromium 1.63.0.
A ForgeQA AI license key delivered after purchase.
Install the matching Chromium runtime once:
npx -y playwright@1.63.0 install chromiumPurchase
ForgeQA AI is available as a $79 one-time purchase:
The purchase includes the npm package, setup guide, and a unique Gumroad license key.
Claude Desktop and Cursor configuration
{
"mcpServers": {
"ForgeQA": {
"command": "npx",
"args": ["-y", "@ltorrey/forgeqa-mcp@1.1.0"],
"env": {
"GUMROAD_LICENSE_KEY": "YOUR_GUMROAD_LICENSE_KEY"
}
}
}
}The MCP server uses stdio and runs locally through Node.js and Chromium.
Claude Desktop paths
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Cursor paths
Global:
~/.cursor/mcp.jsonProject-specific:
<project-root>/.cursor/mcp.json
Privacy and safe use
ForgeQA AI contains no product telemetry. At startup, it sends the Gumroad product ID and license key to Gumroad for validation. It does not log or persist the key. Test inputs and browser activity run locally, while target websites receive ordinary browser requests.
dry_run_qa_flow performs real browser interactions. Use ForgeQA AI only on applications and environments you are authorized to test. Prefer staging environments and disposable test data for flows that submit forms or change server-side state. Review generated specifications before running them.
Licensing, support, updates, and refunds
Each purchase provides a unique license key that must not be shared or published.
Configuration examples pin version 1.1.0 so updates cannot silently change behavior. Review release notes before changing versions.
For support, reply to the Gumroad receipt or use the creator contact on the product page. Never send a complete license key in a support message.
Sales are final. Refunds are not offered except where required by applicable law or Gumroad's mandatory policies.
Disclaimer
ForgeQA AI is testing infrastructure, not a guarantee that an application is defect-free. Review generated specifications and test results before relying on them in a release decision.
This repository contains public registry metadata and installation instructions. The licensed implementation is distributed through npm.
Registry inspection mode
npm run start:glama starts a restricted MCP runtime for automated registry inspection. It publishes the same public tool names, descriptions, schemas, and safety annotations as ForgeQA AI, but every tool call is rejected. It cannot scan pages, run QA flows, or generate test files, and it does not bypass product licensing.
Copyright 2026 Lajuane Torrey. All rights reserved.
Available Tools
3 toolscompile_playwright_specCompile Playwright specB
Write validated role-based browser actions and assertions to a Playwright spec in the local tests directory.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| test_name | Yes | ||
| target_url | Yes | ||
| validated_actions | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| file_path | Yes | |
| action_count | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description is not contradicting them. The description adds that the tool writes to the local tests directory, which is useful behavioral context. However, it does not disclose whether the tool overwrites existing files, creates new files, or requires specific permissions, which would be valuable for a write operation.
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 is concise and front-loads the key action ('Write validated role-based browser actions and assertions'). It avoids redundancy with the title and schema. It could be slightly more informative about the parameters, but it is appropriately sized for a tool with a rich schema.
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 complex schema with many action types, and the description does not explain the workflow context (e.g., that this is the final step after validation). The output schema exists, so return values are covered, but the description lacks guidance on how the validated_actions should be structured or what happens on write. Given the complexity, a bit more context would help.
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 0%, so the description carries the burden of explaining parameters. The description mentions 'validated role-based browser actions and assertions' which maps to the validated_actions parameter, and 'Playwright spec' maps to the output. However, it does not explain test_name or target_url, nor the structure of validated_actions beyond the schema. The schema itself is rich with descriptions for each action type, so the description adds minimal value beyond what the schema provides.
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 states a specific verb ('Write'), a resource ('Playwright spec'), and a qualifier ('validated role-based browser actions and assertions'), which clearly distinguishes it from the sibling tools scan_dom_accessibility and dry_run_qa_flow. It does not explicitly name the siblings, but the action of compiling a spec is distinct enough that an agent can infer the purpose.
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 this tool is used after validation ('validated actions') and writes to the local tests directory, giving some context. However, it does not explicitly state when to use this tool versus the siblings, nor does it mention prerequisites like having run a dry run or scan first. The 'validated' qualifier hints at a workflow but leaves the when-to-use guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dry_run_qa_flowDry-run QA flowA
Run role-based browser actions and assertions in a fresh headless Chromium session and return a step-by-step pass/fail report.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Starting page URL | |
| actions | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| logs | Yes | |
| passed | Yes |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=false (potentially mutating) and openWorldHint=true (external interaction). The description adds the behavioral detail of a 'fresh headless Chromium session', which clarifies that each call is isolated and state is not shared. It also states the report is returned. This is useful beyond the annotations, though it does not mention side effects, rate limits, or the 'dry-run' semantics explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that packs the core action, environment, and output. It is front-loaded with the verb and resource, and contains no redundant words. It is an excellent example of concise writing.
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 (a QA runner with multiple action types), the description is terse. It mentions the fresh session and the report, but does not clarify the 'dry-run' nature (no permanent side effects on external systems), any prerequisites (e.g., URL accessibility, authentication), or constraints (e.g., maximum number of actions). The existence of an output schema reduces the need to describe the return format, but more operational context would be helpful for correct invocation.
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 50% – the 'url' parameter is described, but 'actions' has no top-level description. The tool description only says 'role-based browser actions and assertions', which is vague and does not explain the structure or expected format of the actions array. The nested item schemas do provide per-element descriptions, but the description does not add enough to compensate for the missing top-level parameter description.
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 ('Run'), resource ('role-based browser actions and assertions'), and environment ('fresh headless Chromium session'), plus the expected outcome ('step-by-step pass/fail report'). It differentiates from the sibling tools by mentioning the QA execution context, but does not explicitly name them or contrast itself, so it falls short of the model example (get_calls) which explicitly named its sibling.
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?
There is no guidance on when to use this tool versus its siblings (scan_dom_accessibility, compile_playwright_spec). The description explains what it does but does not provide any conditions or exclusions. An agent would have to infer the context from the name and the described functionality, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_dom_accessibilityScan DOM accessibilityARead-only
Open a supplied URL in a fresh headless Chromium session and return its accessibility tree as structured content.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL to scan |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| snapshot | Yes |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate safety. It does add useful context: the session is 'fresh' and 'headless', and the output is the 'accessibility tree as structured content'. However, it doesn't disclose potential pitfalls such as network dependencies, timeouts, or that the tree may not include all DOM elements (e.g., offscreen or hidden).
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 one concise sentence that front-loads the core action and provides key context (fresh, headless) without waste. It's appropriately sized for a single-parameter tool.
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 one parameter, a clear output schema, and simple annotations, the description covers the essentials. However, it doesn't specify how to interpret the accessibility tree or whether it includes all ARIA roles, which could matter for downstream use. For a straightforward tool, this is adequate but not exhaustive.
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 has 100% description coverage for the only parameter (url), so the description doesn't need to re-explain it. The description adds the implication that the URL must be accessible via headless Chromium, but that's minimal added meaning. Thus 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 states a specific action ('scan DOM accessibility') and clarifies it opens a URL in headless Chromium to produce an accessibility tree. It doesn't explicitly contrast with siblings, but the tool name and description are clear enough to distinguish from QA flow and Playwright spec 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 description implies the tool should be used when you need an accessibility tree from a URL, but it doesn't provide explicit guidance on when NOT to use it or when to prefer sibling tools. For example, it could say 'use compile_playwright_spec for automated test generation' or 'use dry_run_qa_flow for end-to-end QA scenarios.' Without this, the agent must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
compile_playwright_spec - First observed
dry_run_qa_flow - First observed
scan_dom_accessibility
TDQS
A3.8/5.0
Scored across 3 tools
Disambiguation4/5
The three tools are largely distinct: one scans the accessibility tree, one executes a QA flow in the browser, and one writes a Playwright spec. dry_run_qa_flow and compile_playwright_spec both consume role-based actions and assertions, so an agent could initially confuse execution with persistence, but the descriptions clarify the difference.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern: scan_dom_accessibility, dry_run_qa_flow, and compile_playwright_spec. The naming is predictable and action-oriented.
Tool Count5/5
Three tools is a tight, well-scoped set for an AI-assisted QA server. Each tool maps cleanly to a distinct stage in the workflow: inspect, validate, and generate.
Completeness4/5
The core QA workflow is covered: accessibility scanning, flow verification, and spec generation. Minor gaps exist, such as no tool for listing or updating compiled specs, but these are workable for most use cases.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Run, debug, and triage tests from your IDE using natural language, no dashboard switching, no manual data transfers. The TestMu AI (formerly LambdaTest) MCP Server is a single remote server exposing four tool suites: HyperExecute — analyze your project, generate YAML configs and test runner commands, then monitor jobs and sessions. Automation — pull a TestID's details plus command, network, and console logs into one chat for instant root-cause analysis. Includes mobile app upload. SmartUI — explain pixel, layout, DOM, and perceptual changes in a visual regression run, with context-aware React/HTML/CSS fixes. Accessibility — audit any public URL or a local React app against WCAG and get ready-to-apply remediation steps. Connects over https://mcp.lambdatest.com/mcp using OAuth 2.1 — no API keys in your config. One-click install in Cursor; works with Claude, GitHub Copilot, Cline, and any MCP client. Tests execute on the TestMu AI cloud: 3,000+ browsers and 10,000+ real devices.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceA Playwright-based MCP server that exposes a live browser as a traceable, inspectable, debuggable and controllable execution environment for AI agents.3,661 npm57-
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI-powered browser automation, web scraping, and testing using Playwright across Chromium, Firefox, and WebKit. It allows users to perform actions like navigation, clicking, typing, and taking screenshots through natural language interfaces.6 npmMIT
- FlicenseAqualityBmaintenanceAn MCP server that gives Claude direct control of a real browser via Playwright, enabling AI-driven web testing, autonomous test execution, and live failure analysis through natural language.84,799 npm3-