How do I use QA Studio MCP Server?

1. Click on "Install 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 Related Servers Score Discussions

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

ParametersJSON Schema

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

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

ParametersJSON Schema

Name	Required	Description
`projectId`	Yes	The project ID to create the test run for
`name`	Yes	Name of the test run
`environment`	Yes	Environment name (e.g., "production", "staging", "local")
`description`	No	Optional description of the test run
`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-resultsB

Get test results for a specific test run

ParametersJSON Schema

Name	Required	Description
`projectId`	Yes	The project ID
`testRunId`	Yes	The test run ID
`status`	No	Optional filter by status

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'Get test results' but does not disclose format, pagination, order, or authentication requirements, leaving key behavioral traits unknown.

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, well-structured sentence with no wasted words. It is appropriately concise for a simple retrieval 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?

The description fails to explain what the results contain (e.g., list of test results, fields per result), output format, or any edge cases. Given absence of output schema, more context is needed for complete understanding.

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% (all 3 parameters described). The description adds no extra meaning beyond the schema; it reiterates 'for a specific test run' which matches required params but provides no additional parameter context.

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 tool retrieves test results for a specific test run, with a specific verb 'Get' and resource 'test results'. It distinguishes from sibling tools like 'get-test-run' (gets run details) and 'list-test-runs' (lists runs not 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 implies usage when needing test results for a run, but provides no explicit guidance on when to use versus alternatives like 'list-test-runs' or 'get-test-run', nor any exclusions.

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

Name	Required	Description
`projectId`	Yes	The project ID to list test runs for
`limit`	No	Maximum number of results to return (default: 50)
`offset`	No	Number of results to skip for pagination (default: 0)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided. Description does not disclose read-only nature or any behavioral traits (e.g., rate limits, data scope). Assumed read-only but not stated.

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?

Very concise (6 words). Front-loads purpose. Could add pagination details without bloat, but acceptable for a simple list 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; description does not mention pagination behavior, defaults, or return format. Inadequate for a tool with multiple parameters.

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%, so description adds no value beyond schema. Baseline 3 is appropriate; description just restates purpose.

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+resource: 'List test runs for a project'. Distinguishes from singular get-test-run and create-test-run. However, it doesn't explicitly mention pagination or scope.

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 vs alternatives (e.g., get-test-run) or context like pagination. Does not specify typical use case.

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)

ParametersJSON Schema

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

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: creating test cases, creating test runs, retrieving results, retrieving test run details, listing projects, listing test runs, and submitting results. No ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with kebab-case (e.g., create-test-case, list-projects). No deviations in style or convention.

Tool Count5/5

7 tools is well-scoped for a QA Studio server covering project listing, test case creation, test run management, and result submission. Each tool earns its place without being too few or too many.

Completeness4/5

The tool set covers core workflows: create test cases, create and list test runs, get run details, and submit results. Missing update/delete operations and a list-test-cases tool, but these are minor gaps for the apparent purpose.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
validatethat-mcp
io.github.RyanByrne
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Research & Data Product Management
2
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
platform7nOAuth
tech.p7n
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Communication Project Management Workplace & Productivity
2

Related MCP Servers

Qase MCP Server
Testing & QA Tools Project Management App Automation
hacobell-inc
F
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 4 months ago (2026-05-10 23:26 UTC)
30
-
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
3,508
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
3,508
MIT
TestRail MCP Server
Testing & QA Tools Developer Tools
valvacchs
A
license
B
quality
B
maintenance
Enables management of TestRail projects, suites, test cases, runs, and results through natural language.
Updated 2 months ago (2026-07-03 06:16 UTC)
42
1,580
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/QAStudio-Dev/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

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

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`list-projects`

`create-test-run`

`list-test-runs`

`get-test-run`

`get-test-results`

`create-test-case`

`submit-test-results`