How do I use QA Studio MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@QA Studio MCP Server create a test run for project ABC123 called 'Sprint 45 Regression' in staging" 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.

QA Studio MCP Server

by QAStudio-Dev

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

QA Studio MCP Server

License: AGPL-3.0

MCP (Model Context Protocol) server for QA Studio - interact with your test management platform directly from Claude.

Features

This MCP server exposes QA Studio's API as MCP tools, allowing you to:

📋 List and search projects
🚀 Create and manage test runs
✅ View test results and execution history
📝 Create test cases
📊 Submit test results (manual testing)

Related MCP server: TestRail MCP Server

Installation

Option 1: NPM Package (Recommended)

npx @qastudio-dev/mcp-server

Or install globally:

npm install -g @qastudio-dev/mcp-server

Option 2: Local Development

For local development or if the package isn't published yet:

git clone https://github.com/QAStudio-Dev/mcp-server.git
cd mcp-server
npm install
npm run build

Configuration

Claude Desktop

Add to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

For published package (after publishing to npm):

{
  "mcpServers": {
    "qastudio": {
      "command": "npx",
      "args": ["-y", "@qastudio-dev/mcp-server"],
      "env": {
        "QA_STUDIO_API_URL": "https://qastudio.dev/api",
        "QA_STUDIO_API_KEY": "your-api-key-here"
      }
    }
  }
}

For local development (before publishing):

{
  "mcpServers": {
    "qastudio": {
      "command": "node",
      "args": ["/absolute/path/to/qastudio-mcp/dist/index.js"],
      "env": {
        "QA_STUDIO_API_URL": "https://qastudio.dev/api",
        "QA_STUDIO_API_KEY": "your-api-key-here"
      }
    }
  }
}

Note: Replace /absolute/path/to/qastudio-mcp with the actual path to your local repository.

Environment Variables

QA_STUDIO_API_URL - Base URL for your QA Studio API (default: http://localhost:3000/api)
QA_STUDIO_API_KEY - Your QA Studio API key (required)

Usage

Once configured, you can interact with QA Studio directly from Claude:

Examples

List projects:

Show me all projects in QA Studio

Create a test run:

Create a new test run for project ABC123 called "Sprint 45 Regression" in the staging environment

View test results:

Show me the test results for project ABC123, test run XYZ789

Create a test case:

Create a high priority functional test case for project ABC123:
Title: "Verify user login with valid credentials"
Steps:
1. Navigate to login page
2. Enter valid username and password
3. Click login button
Expected: User is redirected to dashboard

Submit test results:

Submit these manual test results for project ABC123, run XYZ789:
- "Login test" - passed
- "Registration test" - failed (Error: Email validation not working)
- "Logout test" - passed

Available Tools

`list-projects`

List all projects with optional search filtering.

Parameters:

search (optional): Search query to filter projects by name

`create-test-run`

Create a new test run for a project.

Parameters:

projectId (required): Project ID
name (required): Test run name
environment (required): Environment (e.g., "production", "staging")
description (optional): Test run description
milestoneId (optional): Associated milestone ID

`list-test-runs`

List test runs for a project.

Parameters:

projectId (required): Project ID
limit (optional): Maximum results (default: 50)
offset (optional): Pagination offset (default: 0)

`get-test-run`

Get detailed information about a specific test run.

Parameters:

projectId (required): Project ID
testRunId (required): Test run ID

`get-test-results`

Get test results for a specific test run.

Parameters:

projectId (required): Project ID
testRunId (required): Test run ID
status (optional): Filter by status (passed, failed, skipped, blocked, retest, untested)

`create-test-case`

Create a new test case in a project.

Parameters:

projectId (required): Project ID
title (required): Test case title
description (optional): Detailed description
priority (optional): CRITICAL, HIGH, MEDIUM, LOW
type (optional): FUNCTIONAL, REGRESSION, SMOKE, INTEGRATION, PERFORMANCE, SECURITY, UI, API, UNIT, E2E
automationStatus (optional): AUTOMATED, NOT_AUTOMATED, CANDIDATE
steps (optional): Array of test steps with action and expectedResult

`submit-test-results`

Submit test results for a test run (useful for manual testing).

Parameters:

projectId (required): Project ID
testRunId (required): Test run ID
results (required): Array of test results with title, status, duration, and optional error

Development

Local Development Setup

Clone and install dependencies:

git clone https://github.com/QAStudio-Dev/mcp-server.git
cd mcp-server
npm install

Build the project:
```
npm run build
```

Configure Claude Desktop for local development:

Edit your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add this configuration (replace the path with your actual project path):

{
  "mcpServers": {
    "qastudio": {
      "command": "node",
      "args": ["/Users/yourusername/path/to/qastudio-mcp/dist/index.js"],
      "env": {
        "QA_STUDIO_API_URL": "https://qastudio.dev/api",
        "QA_STUDIO_API_KEY": "your-api-key-here"
      }
    }
  }
}

Restart Claude Desktop to load the MCP server

Run tests:

# Run all tests
npm test

# Run tests in watch mode
npm run test:watch

# Run tests with UI
npm run test:ui

Watch mode for development:
```
# Automatically rebuild on file changes
npm run dev
```
After making changes, restart Claude Desktop to reload the server.

Testing the Server Directly

You can test the MCP server independently (without Claude):

# Set environment variables
export QA_STUDIO_API_URL="https://qastudio.dev/api"
export QA_STUDIO_API_KEY="your-api-key"

# Run the server (it will listen on stdio)
node dist/index.js

API Key Setup

To create an API key in QA Studio:

Log in to your QA Studio instance
Navigate to Settings → API Keys
Click "Create API Key"
Give it a name (e.g., "Claude MCP Server")
Copy the generated key and add it to your MCP configuration

Security

Never commit your API key to version control
Store API keys securely in environment variables or configuration files
Use HTTPS for production QA Studio instances
Rotate API keys regularly

License

This project is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0) - see the LICENSE file for details.

What does AGPL-3.0 mean?

You are free to use, modify, and distribute this software
If you modify this software and run it on a server (including offering it as a service), you must make your modified source code available to users
Any derivative work must also be licensed under AGPL-3.0
This ensures that improvements to the software remain open source and benefit the community

For more information, see the full license text or visit GNU AGPL-3.0.

Available Tools

7 tools

create-test-caseB

Create a new test case in a project

Name	Required	Description
`type`	No	Test type
`steps`	No	Test steps
`title`	Yes	Title of the test case
`priority`	No	Priority level
`projectId`	Yes	The project ID
`description`	No	Detailed description of the test case
`automationStatus`	No	Automation status

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description fails to disclose behavioral traits such as idempotency, side effects, permission requirements, or error handling. A mutation tool needs more context.

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?

A single concise sentence with no unnecessary words or repetition. It efficiently conveys the core purpose.

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

Completeness2/5

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

Despite having 7 parameters (including enums and nested arrays) and no output schema, the description does not explain return values, error conditions, or the meaning of the steps array. Incomplete for the complexity.

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 descriptions for all 7 parameters. The description adds no additional meaning beyond what the schema already provides, so 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 action (Create), resource (test case), and context (in a project), which distinctly separates it from sibling tools like create-test-run.

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?

No guidance on when to use this tool versus alternatives, no prerequisites mentioned (e.g., project must exist), and no explicit when-not or exclusion criteria.

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

create-test-runC

Create a new test run for a project

Name	Required	Description
`name`	Yes	Name of the test run
`projectId`	Yes	The project ID to create the test run for
`description`	No	Optional description of the test run
`environment`	Yes	Environment name (e.g., "production", "staging", "local")
`milestoneId`	No	Optional milestone ID to associate with the test run

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided. Description only says 'create', implying a write operation, but no details on side effects, permissions, or error states.

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?

Single sentence, no redundant text. Efficient but may be too minimal for a creation tool.

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

Completeness2/5

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

No output schema, no annotations. Description does not explain return values, errors, or behavior beyond creation. Incomplete for a 5-parameter mutation tool.

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?

Input schema has 100% description coverage, so schema already documents parameters. Description adds no extra meaning beyond the schema's descriptions.

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?

Clear verb 'Create' and resource 'test run' with context 'for a project'. Distinguishes from sibling tools like create-test-case (different resource) and read-only tools.

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?

No when-to-use or when-not-to-use guidance. No prerequisites or conditions mentioned.

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

get-test-resultsA

Get test results for a specific test run. Pass page to retrieve later pages.

Name	Required	Description
`page`	No	Results page to fetch (default: 1). Use pagination.totalPages to request later pages.
`status`	No	Optional filter by status
`projectId`	Yes	The project ID
`testRunId`	Yes	The test run ID

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose that results are paginated and that later pages are fetched via the page parameter, but says nothing about read-only safety, authorization needs, ordering, or result shape.

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 short sentences with the core action front-loaded and the pagination note second. Nothing is wasted or buried.

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?

With 4 parameters, a status enum, and no output schema, the description is thin: it never indicates what a 'test result' contains or how the totalPages metadata referenced in the schema is surfaced. The complete parameter schema compensates partially, but the read-side behavior is under-described.

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 100%, so projectId, testRunId, page, and status are already explained in the schema (including the pagination.totalPages hint). The description only repeats the page semantics, adding no new meaning beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Get test results for a specific test run'), which clearly separates it from the sibling get-test-run (which fetches the run itself). The purpose is unambiguous, though it never explicitly contrasts itself with that sibling.

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?

Gives one concrete usage instruction ('Pass page to retrieve later pages'), which is useful for pagination, but offers no guidance on when to use this versus get-test-run or the status filter, and no prerequisites. Usage is implied rather than spelled out.

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

get-test-runC

Get detailed information about a specific test run

Name	Required	Description	Default
`projectId`	Yes	The project ID
`testRunId`	Yes	The test run ID

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It only says 'Get detailed information', which is vague. It does not clarify if the operation is read-only, what data is returned (e.g., test steps, results), or any potential side effects.

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 with no wasted words. It is concise but could be improved by adding a bit more detail without becoming verbose.

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

Completeness2/5

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

Given the lack of output schema and the tool's purpose (getting details), the description should explain what the response includes. It does not, leaving ambiguity about the tool's output. Sibling tool 'get-test-results' suggests possible overlap, but no differentiation is provided.

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?

Input schema has 100% coverage with parameter descriptions (projectId and testRunId). The description adds no additional semantics beyond the schema. Since schema is sufficient, baseline score of 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 clearly states the verb ('Get') and resource ('detailed information about a specific test run'), distinguishing it from siblings like 'list-test-runs' (list vs. single) and 'create-test-run' (create vs. read). However, it could be more specific about what 'detailed information' includes.

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?

No guidance is provided on when to use this tool versus alternatives such as 'list-test-runs' or 'get-test-results'. The description does not mention any contextual cues or prerequisites.

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

list-projectsC

List all projects in QA Studio

Name	Required	Description	Default
`search`	No	Optional search query to filter projects by name

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description must convey behavioral traits. It only states 'List all projects,' implying a read operation, but fails to mention potential side effects, pagination, rate limits, or authorization needs.

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, concise sentence with no unnecessary words. It could be slightly improved by noting the optional filter, but it is efficient.

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

Completeness2/5

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

The description lacks details about return values (e.g., project fields), pagination, or output format. Given the absence of an output schema and annotations, the description should provide more context to be 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?

Schema description coverage is 100% with one optional parameter 'search' already described. The description adds no additional context beyond what the schema provides, so baseline score of 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 clearly states the action (List) and resource (projects in QA Studio), distinguishing it from sibling tools like list-test-runs. The phrase 'all projects' is slightly misleading given the optional search parameter, but the overall purpose is clear.

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?

No guidance is provided on when to use this tool versus siblings (e.g., create-test-case, list-test-runs). The description does not indicate any alternative tools or conditions for use.

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

list-test-runsC

List test runs for a project

Name	Required	Description
`limit`	No	Maximum number of results to return (default: 50)
`offset`	No	Number of results to skip (default: 0). Must be a multiple of limit so it maps to a Studio page.
`projectId`	Yes	The project ID to list test runs for

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about ordering, pagination semantics, or result shape. The one interesting behavioral constraint (offset must be a multiple of limit to map to a Studio page) lives only in the schema, not the description.

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?

A single front-loaded sentence with zero waste. However, it is arguably under-specified rather than truly concise, since the brevity leaves real gaps for an agent.

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?

No output schema and no annotations, but the tool is a simple paginated list with all three parameters documented in the schema, so an agent can call it correctly. The missing pieces are pagination/ordering behavior and when to prefer get-test-run, which keeps it from being 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?

Schema description coverage is 100%, so limit, offset, and projectId are already fully documented in the schema, which sets the baseline at 3. The description adds no additional parameter meaning such as default sort order or what a 'page' means in practice.

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?

States a specific verb (List) and resource (test runs) with scoping (for a project), which is enough to distinguish it from the get/create siblings by intent. It does not explicitly name those siblings, but the list-vs-single-vs-create distinction is inferable from the verb alone.

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?

No guidance on when to use this versus get-test-run (single run) or list-projects, and no mention of prerequisites such as needing a valid projectId or permissions. The only usage signal is the required projectId, which the schema already enforces.

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

submit-test-resultsA

Submit test results for a test run (useful for manual test execution tracking)

Name	Required	Description
`results`	Yes	Array of test results
`projectId`	Yes	The project ID
`testRunId`	Yes	The test run ID

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. The description only says 'Submit test results' without detailing side effects, whether it overwrites existing results, required permissions, or error scenarios. This lack of transparency could lead to incorrect usage.

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 concise sentence with a parenthetical clarification. It is front-loaded with the action and resource, containing no wasted words.

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?

For a simple tool with three clearly defined parameters, the description provides the essential purpose but lacks details on return values or behavior after submission. It is minimally adequate but could be improved with more context.

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 input schema has 100% parameter description coverage, so the description does not need to add parameter details. The description adds no extra meaning beyond the schema, so 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 action 'Submit test results' and specifies the resource 'for a test run'. It differentiates from sibling tools like create-test-case and get-test-results by focusing on submitting results rather than creating cases or retrieving results.

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 notes 'useful for manual test execution tracking', providing context for when to use the tool. However, it does not explicitly state when not to use it or suggest alternatives, leaving some ambiguity.

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.

2 tool updatesv1.1.1Oct 7, 2026

Changedget-test-results1 field changed

addedInput schema / properties / page

Added value: +{
+  "description": "Results page to fetch (default: 1). Use pagination.totalPages to request later pages.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

Changedlist-test-runs1 field changed

changedInput schema / properties / offset / description

Previous value: -"Number of results to skip for pagination (default: 0)"New value: +"Number of results to skip (default: 0). Must be a multiple of limit so it maps to a Studio page."

7 tool updatesv1.0.0Jan 2, 2026
- First observedcreate-test-case
- First observedcreate-test-run
- First observedget-test-results
- First observedget-test-run
- First observedlist-projects
- First observedlist-test-runs
- First observedsubmit-test-results

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

B3.3/5.0

Scored 2026-10-07 11:30 across 7 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Testiny Test Management AOAuth
io.testiny
Create and manage test cases, test runs and results in Testiny from your AI assistant.
Testing & QA Tools Project Management
152
https://app.testiny.io/api/v1/mcp-server
Cypress Cloud MCP BOAuth
io.cypress.mcp
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Testing & QA Tools CI/CD & DevOps
24
https://mcp.cypress.io/mcp
validatethat-mcp
io.github.RyanByrne
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Research & Data Product Management
2
https://validatethat.io/mcp
mcp-server
com.testrigor
Manage test suites, run tests, view results, and automate QA workflows via AI with testRigor.
Testing & QA Tools App Automation
2
https://api2.testrigor.com/api/v1/mcp

Related MCP Servers

Qase MCP Server
Testing & QA Tools Project Management App Automation
hacobell-inc
A
license
Not graded
quality
D
maintenance
Enables integration with Qase test management platform to create, retrieve, and manage test cases, test suites, and test runs through natural language interactions.
Updated 5 months ago (2026-05-10 23:26 UTC)
5 npm
ISC
TestRail MCP Server
Testing & QA Tools Developer Tools
denys-ispaniuk
A
license
B
quality
D
maintenance
Enables AI assistants to interact with TestRail test management system, supporting full CRUD operations on projects, suites, sections, test cases, runs, results, plans, and milestones.
Updated a year ago (2025-10-17 16:31 UTC)
35
54 npm
1
MIT
TestRail MCP Server
Testing & QA Tools CI/CD & DevOps Project Management
yshpyluk
A
license
B
quality
D
maintenance
Integrates TestRail with Claude Code to enable AI-assisted test management workflows, including project, suite, test case, test run, and result operations.
Updated a year ago (2025-10-08 19:51 UTC)
13
54 npm
MIT
TestRail MCP Server
Testing & QA Tools Developer Tools
valvacchs
A
license
B
quality
D
maintenance
Enables management of TestRail projects, suites, test cases, runs, and results through natural language.
Updated 4 months ago (2026-07-03 06:16 UTC)
42
1,816 npm
MIT

QA Studio MCP Server

Features

Installation

Option 1: NPM Package (Recommended)

Option 2: Local Development

Configuration

Claude Desktop

Environment Variables

Usage

Examples

Available Tools

list-projects

create-test-run

list-test-runs

get-test-run

get-test-results

create-test-case

submit-test-results

Development

Local Development Setup

Testing the Server Directly

API Key Setup

Security

License

What does AGPL-3.0 mean?

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`list-projects`

`create-test-run`

`list-test-runs`

`get-test-run`

`get-test-results`

`create-test-case`

`submit-test-results`