Click on "Deploy 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-touch-mcp Show me the test results for the latest test run"
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.
MCP (Model Context Protocol) server for the QA Touch test management API. Lets AI assistants like Claude browse projects, manage test cases, drive test runs, record results, and file defects in your QA Touch domain.
Node.js 18+
A QA Touch account on a Professional or Enterprise plan (the API is gated to those plans)
An API token: in QA Touch go to Profile → Edit Profile → Generate API Key
Related MCP server: Testmo MCP Server
The server is configured entirely through environment variables:
Variable | Required | Description |
| yes | Your QA Touch domain name |
| yes | Your API token |
| no | Override the API base URL (default |
The token grants access to all data in your QA Touch domain. Keep it out of version control.
claude mcp add qa-touch --env QATOUCH_DOMAIN=yourdomain --env QATOUCH_API_TOKEN=yourtoken -- npx qa-touch-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"qa-touch": {
"command": "npx",
"args": ["qa-touch-mcp"],
"env": {
"QATOUCH_DOMAIN": "yourdomain",
"QATOUCH_API_TOKEN": "yourtoken"
}
}
}
}npm install
npm run build
QATOUCH_DOMAIN=yourdomain QATOUCH_API_TOKEN=yourtoken node dist/index.jsProjects — list_projects, get_project, create_project
Test cases & modules — list_test_cases (filter by approval status, module, mode, or requirement), get_test_case, get_test_case_steps, list_modules, create_module, create_test_case (exploratory / text / BDD / step templates), update_test_case, import_test_cases_csv
Releases & plans — list_releases, create_release, list_test_plans, list_workspaces
Test runs & results — list_test_runs, get_test_run, create_test_run (all cases / specific cases / by module), clone_test_run, list_test_run_results (by run, release, history, or case), get_test_run_metadata, update_test_result, update_test_result_steps, bulk_update_test_results, update_test_results_multi, add_test_result (with attachments)
Defects — list_defects, create_defect (with attachments), get_defect_metadata
Requirements — list_requirements, create_requirement_document, create_requirement
Rate limiting: QA Touch allows 50 requests/minute. The server throttles client-side and retries once on 429, honoring Retry-After.
Pagination: list tools accept a page parameter. The QA Touch API returns meta.current_page/last_page as null on page 1; the server normalizes this and adds a has_next flag.
Attachments: png, pdf, jpg, jpeg, gif, xls, xlsx, doc, docx, csv, log, zip, txt — max 2 MB per file, validated before upload.
Batch limits: multi-case status updates are capped at 20 items per call because the API takes parameters in the URL and rejects over-long URIs.
npm run build # compile TypeScript
npm test # run unit tests (vitest)API reference notes used for this implementation: docs/qatouch-api-reference.md.
Add a result to one or more test run results with a status, optional comment, time spent and file attachments (png, pdf, jpg, jpeg, gif, xls, xlsx, doc, docx, csv, log, zip, txt; max 2 MB each). Result keys come from list_test_run_results; a case key with prefix CASE (e.g. CASEaSaD) is also accepted.
Inputs: status (required), projectKey (required), resultKeys (required), testRunKey (required), +3 more.
Set one status (and optionally assignee/comment) across many results of a test run. by selects the target:
run: every case in the run (status only)
modules: all cases in the given modules (moduleKeys required)
cases: the given case codes, e.g. TR001 (caseCodes required)
For per-case different statuses use update_test_results_multi instead.
Inputs: by (required), status (required), projectKey (required), testRunKey (required), +4 more.
Clone an existing test run for re-testing. All cases in the new run start as Untested.
Inputs: projectKey (required), testrunKey (required), testrunName (required).
Create a new defect in a project. Use get_defect_metadata to see valid priority values. Optionally attach local files (png, pdf, jpg, jpeg, gif, xls, xlsx, doc, docx, csv, log, zip, txt; max 2 MB each).
Inputs: priority (required), projectKey (required), issueSummary (required), filePaths.
Create a new module (section) for test cases in a project. Pass parentKey to create it as a child of an existing module.
Inputs: moduleName (required), projectKey (required), parentKey.
Create a new project in the QA Touch domain.
Inputs: name (required).
Create a new release (milestone) in a project.
Inputs: milestone (required), projectKey (required).
Create a new requirement under a requirement document.
Inputs: title (required), projectKey (required), documentKey (required), desc.
Create a new requirement document in a project under a release.
Inputs: title (required), projectKey (required), releaseKey (required).
Create a test case in a module (section). template selects the style:
exploratory: no predefined steps
text: single steps text + expected_result
bdd: Gherkin feature script (featureScript required)
steps: structured step list (stepsTemplate required)
Inputs: template (required), caseTitle (required), projectKey (required), sectionKey (required), +8 more.
Create a test run in a project. scope selects which test cases are included:
all: every test case in the project
cases: specific test cases (caseIds required)
modules: cases from specific modules (moduleKeys required; optional mode filter)
Inputs: scope (required), testRun (required), assignTo (required), projectKey (required), +5 more.
Get the available defect statuses, severities, priorities, issue types and environments. Pass kind for a single list, or omit it for all five.
Inputs: kind.
Get a single project's detail including test case, test run, defect and milestone (release) counts.
Inputs: projectKey (required).
Get a single test case's detail: mapped test runs with status, custom field values, and step descriptions with expected results.
Inputs: caseKey (required), projectKey (required).
List the steps (description + expected result) of a test case. Works for both test cases and test run cases; step result keys returned here are used for step-level status updates.
Inputs: caseID (required).
Get a single test run's detail.
Inputs: projectKey (required), testRunKey (required).
Get the available test run statuses (names, plus the numeric status IDs used by bulk update endpoints). Pass projectKey to also list the users assignable to test runs.
Inputs: projectKey.
Bulk import test cases into a project from a local CSV file (QA Touch sample format). Max 100 test cases per request; file max 2 MB.
Inputs: filePath (required), projectKey (required).
List the defects of a project.
Inputs: projectKey (required), page.
List the modules (sections) of a project. Set includeCounts to also return the hierarchical module/submodule test case counts.
Inputs: projectKey (required), includeCounts.
List projects in the QA Touch domain. Paginated (50 per page); the response includes pagination metadata (current_page, last_page, total). Pass page to fetch subsequent pages.
Inputs: page.
List the releases (milestones) of a project.
Inputs: projectKey (required), page.
List the requirements of a project. Set includeDocuments to also return the requirement documents they are organized under.
Inputs: projectKey (required), page, includeDocuments.
List test cases for a project. Paginated (50 per page). Optionally filter by ONE of: approvalstatus, moduleKey, mode, or requirementKey — the QA Touch API rejects multiple filters in one request. view: "count" (only valid together with mode) returns just the count.
Inputs: projectKey (required), mode, page, view, +3 more.
List the test plans of a project, optionally filtered by name.
Inputs: projectKey (required), name.
List test run results. source selects the lookup:
run: all results of a test run (requires projectKey + testRunKey; paginated, 100 per page)
release: results for a release (requires projectKey + releaseKey; optional status filter)
history: history of one result (requires projectKey + testRunKey + resultKey)
case: runs & results mapped to a test case (requires caseID)
Inputs: source (required), page, caseID, status, +4 more.
List the test runs of a project, optionally filtered by name.
Inputs: projectKey (required), name, page.
List the workspaces (groups/teams) of the QA Touch domain.
Inputs: no named parameters.
Update an existing test case. template must match the case style: exploratory, bdd (featureScript required) or steps (stepsTemplate required). Only provided fields are sent.
Inputs: caseKey (required), template (required), projectKey (required), mode, +10 more.
Update the status of a single test run result, with an optional comment.
Inputs: status (required), resultKey (required), projectKey (required), testRunKey (required), +1 more.
Update several test run results in one call, each with its own status (numeric ID: 1=Passed 2=Untested 3=Blocked 4=Retest 5=Failed 6=Not Applicable 7=In Progress 8=Hold). caseFormat says how case values identify cases:
caseKey: the case key (e.g. MNe7x)
code: the numeric part of the case code (TR0029 → "29"); supports per-item comments and timeSpent
codeTR: the full case code (e.g. TR0028)
Keep batches small (~20) to avoid the API's URL length limit.
Inputs: items (required), caseFormat (required), projectKey (required), testRunKey (required), +2 more.
Update the status of one or more steps of a test run case. Step result keys come from get_test_case_steps.
Inputs: status (required), projectKey (required), testRunKey (required), stepResultKeys (required), +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 32 tools
Most tools target a distinct resource and action, but the five test-result tools (update_test_result, update_test_result_steps, update_test_results_multi, bulk_update_test_results, add_test_result) have closely related purposes and rely on dense descriptions to differentiate them. A few pairs like get_test_case/get_test_case_steps also overlap slightly, though the descriptions clarify their intent.
Names follow a consistent verb_noun pattern in snake_case (list_, get_, create_, update_, clone_), which is predictable and readable. Minor inconsistencies exist: bulk_update_test_results vs update_test_results_multi encode the same bulk concept in different positions, and add_test_result vs update_test_result could be more clearly distinguished.
At 32 tools, the server exceeds the 25+ threshold and feels heavy for an agent to navigate. Many tools are narrowly scoped, such as the five result-update variations, and some read-only conveniences like list_test_plans and list_workspaces could potentially be merged or trimmed.
The server covers core QA workflows well: projects, releases, test runs, test cases, modules, requirements, and defects all have create/list/get capabilities. However, there are notable gaps: no update/delete for projects, releases, test runs, modules, or defects, and test plans only support listing, so lifecycle workflows can dead-end.
Create and manage test cases, test runs and results in Testiny from your AI assistant.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Test management for AI agents: cases, runs, results, cycles and traceability.
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
