qa-touch-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QATOUCH_DOMAIN | Yes | Your QA Touch domain name | |
| QATOUCH_BASE_URL | No | Override the API base URL | https://api.qatouch.com/api/v1 |
| QATOUCH_API_TOKEN | Yes | Your API token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List projects in the QA Touch domain. Paginated (50 per page); the response includes pagination metadata (current_page, last_page, total). Pass |
| get_projectA | Get a single project's detail including test case, test run, defect and milestone (release) counts. |
| create_projectB | Create a new project in the QA Touch domain. |
| list_test_casesA | 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. |
| get_test_caseA | Get a single test case's detail: mapped test runs with status, custom field values, and step descriptions with expected results. |
| get_test_case_stepsA | 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. |
| list_modulesA | List the modules (sections) of a project. Set includeCounts to also return the hierarchical module/submodule test case counts. |
| create_moduleA | Create a new module (section) for test cases in a project. Pass parentKey to create it as a child of an existing module. |
| create_test_caseA | Create a test case in a module (section).
|
| update_test_caseA | Update an existing test case. |
| import_test_cases_csvA | 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. |
| list_releasesC | List the releases (milestones) of a project. |
| create_releaseB | Create a new release (milestone) in a project. |
| list_test_plansA | List the test plans of a project, optionally filtered by name. |
| list_workspacesA | List the workspaces (groups/teams) of the QA Touch domain. |
| list_test_runsB | List the test runs of a project, optionally filtered by name. |
| get_test_runB | Get a single test run's detail. |
| list_test_run_resultsA | List test run results.
|
| get_test_run_metadataA | 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. |
| create_test_runA | Create a test run in a project.
|
| clone_test_runA | Clone an existing test run for re-testing. All cases in the new run start as Untested. |
| update_test_resultA | Update the status of a single test run result, with an optional comment. |
| update_test_result_stepsA | Update the status of one or more steps of a test run case. Step result keys come from get_test_case_steps. |
| bulk_update_test_resultsA | Set one status (and optionally assignee/comment) across many results of a test run.
|
| update_test_results_multiA | 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).
|
| add_test_resultA | 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. |
| list_defectsC | List the defects of a project. |
| create_defectA | 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). |
| get_defect_metadataA | Get the available defect statuses, severities, priorities, issue types and environments. Pass |
| list_requirementsA | List the requirements of a project. Set includeDocuments to also return the requirement documents they are organized under. |
| create_requirement_documentC | Create a new requirement document in a project under a release. |
| create_requirementA | Create a new requirement under a requirement document. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
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.