QA Studio MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QA_STUDIO_API_KEY | Yes | Your QA Studio API key (required) | |
| QA_STUDIO_API_URL | No | Base URL for your QA Studio API | http://localhost:3000/api |
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-projectsC | List all projects in QA Studio |
| create-test-runC | Create a new test run for a project |
| list-test-runsC | List test runs for a project |
| get-test-runC | Get detailed information about a specific test run |
| get-test-resultsA | Get test results for a specific test run. Pass page to retrieve later pages. |
| create-test-caseB | Create a new test case in a project |
| submit-test-resultsA | Submit test results for a test run (useful for manual test execution tracking) |
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 7 tools
Most tools target distinct resources+actions (list-projects, create-test-case, create-test-run). The main risk is get-test-run vs get-test-results, but the descriptions clarify one returns run metadata and the other returns per-result records. Boundaries are otherwise clear.
All tools follow a strict verb_noun kebab-case convention (get-test-run, list-projects, submit-test-results, create-test-case, etc.). No mixing of styles or inconsistent verbs.
Seven tools is well within the healthy range and each maps to a clear operation. It is slightly lean for a full test-management surface, but nothing is redundant or bloated.
Coverage includes reads (list/get for projects, runs, results), creates (test case, test run), and result submission. However, there is no list/get for test cases, no update or delete for test cases or runs, and no way to close/finalize a run, leaving notable lifecycle gaps.