# Qase Test Management [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/qase-tms/qase-mcp-server  
**GitHub Stars:** 37  
**npm Downloads (last month):** 7170  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/qase-test-management

## Description
Official MCP server for Qase — manage test cases, runs, suites, defects via AI tools.

## Tools
Capabilities this server exposes over MCP:

- **qase_api** — Call any Qase REST endpoint directly, for the few things no dedicated tool covers: method, a /v1/… path on the configured host, optional body or query. Prefer a dedicated tool where one exists — they normalize enums and validate before spending a call. JSON only; uploads go through qase_attachment_upload. A DELETE asks for confirmation like the dedicated delete tools. Cost: one API call, 0.3-1.5s.
- **qase_attachment_delete** — Delete an attachment by its hash (from qase_attachment_upload). Anything referencing it keeps the reference but the file is gone; this cannot be undone. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_attachment_upload** — Upload files and get back the hashes other tools reference them by. Pass `file_base64` plus `filename` for one file, or `files` for several in one request; `file_path` only works when the server runs on the same machine as the file — never on the hosted connector. The hash must then be passed in an `attachments` field; uploading alone attaches nothing. This is the only tool that sends multipart/form-data, which is why qase_api cannot send files. Cost: one API call per request, dominated by size.
- **qase_case_bulk_create** — Create up to 100 test cases in one request — the batch form of qase_case_upsert, and the right tool whenever more than one case is being written. Same fields and enum handling as qase_case_upsert; creates only, update through qase_case_upsert with `id`. Cost: one API call regardless of batch size — ten cases measured 1.2s against 5.6s as ten separate calls.
- **qase_case_delete** — Delete a test case by project code and ID. Its execution history goes with it and this cannot be undone; consider marking it deprecated through qase_case_upsert instead. No bulk delete — one call each, each asking the user for confirmation. Cost: one API call, about 0.4s.
- **qase_case_upsert** — Create or update a single test case: with `id` it updates, without it creates. Enum fields accept a label such as "high" or the project's numeric ID. Writing more than one case? Use qase_case_bulk_create — one request instead of one per case. If the project has "Test case review" enabled, writes may need a review — run qase_discover_tools with "review". Cost: one API call, about 0.6s to create, 0.4s to update.
- **qase_ci_report** — Report a whole finished CI run in one call: creates the run, records every result, completes it. Use qase_result_record instead when the run already exists and results arrive in stages. Each result needs a numeric `case_id` and a status; batches over 200 are split for you, up to 2000. Cost: three API operations behind one call, about 0.7s for a small run.
- **qase_custom_field_delete** — Delete a custom field by ID. Reach is workspace-wide: it disappears from every project, with the values entered for it, and this cannot be undone. To remove it from one project only, edit `projects_codes` with qase_custom_field_upsert. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_custom_field_upsert** — Create or update a custom field. On create, `entity` (case, run, defect) and `type` are required and fixed forever — the update endpoint cannot change them. Fields are workspace-wide; scope with `projects_codes` or is_enabled_for_all_projects. Read existing fields with qase_project_context or qase_get. Cost: one call to create, two to update, 0.5-0.9s.
- **qase_defect_delete** — Delete a defect by project code and ID; its links to results go with it and this cannot be undone. Usually resolving it through qase_defect_upsert with `id` is the right move, so the record survives. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_defect_upsert** — Create or update a defect: with `id` it updates, without it creates, and then `title`, `actual_result` and `severity` are required. Severity and status are labels ("blocker", "open"…), mapped for you. For a defect born from a specific test failure use qase_triage_defect; search with qql_search before filing a duplicate. Cost: one API call, about 0.5s.
- **qase_discover_tools** — Search the tool catalogue by what you are trying to do — "delete", "milestone", "review", "custom field" — and get back the matching tools with their descriptions. Every tool is already listed and callable; use this when you do not know which one fits, rather than re-reading the whole list. Cost: no API call, matching happens in memory, about 3ms.
- **qase_environment_delete** — Delete an environment by project code and ID. Runs that referenced it lose the attribution, so filtering history by that environment stops working; this cannot be undone. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_environment_upsert** — Create or update an environment — a named target such as staging or production that runs are attributed to. With `id` it updates, without it creates. Existing environments come back from qase_project_context. Cost: one API call, about 0.5s.
- **qase_external_issue_link** — Link or unlink test cases and runs to issues in Jira Cloud or Jira Server — the only trackers supported. A case may link several issues; a run holds one, and a new link replaces it. Read links back with qase_get. Cost: one API call for the whole set of links, about 0.5s.
- **qase_get** — Fetch one known record by type and ID — case, suite, run, result, plan, defect, milestone, environment, shared_step, review, custom_field and more. Use it only when you already have the ID and want that one record; for several, anything filtered, or a loop over IDs, use qql_search — one search returns the whole page. Cost: one API call, 0.3-0.5s; ten in sequence measured 5.3s against 1.2s for one qql_search.
- **qase_milestone_delete** — Delete a milestone by project code and ID. Runs and cases keep existing but lose the association, so release reporting built on it stops working; this cannot be undone. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_milestone_upsert** — Create or update a milestone — a dated marker, typically a release, that runs and cases are grouped under. With `id` it updates, without it creates. Existing milestones come back from qase_project_context. Cost: one API call, about 0.5s.
- **qase_plan_delete** — Delete a test plan by project code and ID. Only the plan goes — its cases and the runs made from it stay — but anything launching it by ID breaks; this cannot be undone. To change its cases use qase_plan_upsert instead. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_plan_upsert** — Create or update a test plan — a named, reusable set of case IDs such as a smoke or regression pack. With `id` it updates, without it creates. qase_regression_run turns a plan into a run in one call. Cost: one API call, about 0.5s, growing with the number of cases.
- **qase_project_context** — Seed everything about a project in one call: details, the full suite tree, milestones, environments, custom fields and users — make it first when starting on a project. Each collection returns its first 100; check `coverage` and pass `full: true` to page. For one record by ID qase_get is cheaper; for filtered questions use qql_search. Cost: six API calls behind one, 0.5-1.3s cold, cached 5 minutes.
- **qase_project_create** — Create a project. The code must be unique in the workspace, and there is no update endpoint afterwards — title, code and access cannot be changed through the API, so choose them deliberately. Read an existing project with qase_project_context. Cost: one API call, about 1.5s.
- **qase_project_delete** — Delete an entire project by code — every case, suite, run, result, defect and milestone in it, with no trash to recover from; this cannot be undone. The most destructive call in the API; confirm the code with qase_project_context first. Asks the user for confirmation and does not proceed without it. Cost: one API call, about 0.5s.
- **qase_regression_run** — Build and start a test run from a suite, a plan, or an explicit list of case IDs, in one step — it resolves the cases itself. It opens a run, it does not close one: for a finished pipeline use qase_ci_report; to assemble a run by hand use qase_run_upsert. Cost: two API calls behind one, about 1s.
- **qase_result_delete** — Delete one result from a run, by run ID and result hash. The case and the rest of the run are untouched; pass rates shift and this cannot be undone. To discard a whole run use qase_run_delete. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_result_record** — Record up to 200 results into an existing run — status, duration, comment, stacktrace, attachments — in one call, not one per test. Status is a label only: passed, failed, blocked, skipped, invalid. If the run does not exist yet and the job is finished, qase_ci_report creates, records and completes in one call. Cost: one API call for the whole list, about 0.5s.
- **qase_review_bulk_create** — Open several test case reviews in one request — the batch form of qase_review_create, for proposing more than one change. Same fields as qase_review_create; `case_id` for an edit review, omitted for a create review. The API has no endpoints for approving, merging or declining — those are UI-only; read status with qase_review_list. Cost: one API call regardless of batch size.
- **qase_review_create** — Open a test case review — the pull-request flow for cases. Pass `case_id` to propose changes to an existing case (send only the fields that change), or omit it to propose a new one. Several at once? Use qase_review_bulk_create. The API has no endpoints for approving, merging or declining — those are UI-only; read status with qase_review_list. Cost: one API call, about 0.5s.
- **qase_review_delete** — Delete a review by ID. This removes the proposal entirely — it does not decline it, and declining is UI-only — and merged reviews cannot be deleted; the referenced case is untouched. Cannot be undone; asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_review_list** — List a project's reviews with their current state — the only way to learn what happened to a review you opened, since the API has no endpoints for approving or merging — those are UI-only. Filter by status to see what is still open. For one review by ID, qase_get is cheaper. Cost: one API call, about 0.5s.
- **qase_review_update** — Update an open review: the proposed case fields, the reviewers, or both, by review ID. IMPORTANT: changing the proposal RESETS every approval already given; updating only `reviewers` keeps them. The API has no endpoints for approving, merging or declining — those are UI-only; read status with qase_review_list. Cost: one API call, about 0.5s.
- **qase_run_complete** — Mark a test run complete so it reports as finished. It is a reporting state, not a lock — results recorded afterwards still land and change its counts. If all results are in hand at once, qase_ci_report does this as its final step. Cost: one API call, about 0.4s.
- **qase_run_delete** — Delete a test run by project code and ID, together with every result in it; this cannot be undone. Rarely what you want: to stop accepting results use qase_run_complete, to fix one result use qase_result_delete. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_run_upsert** — Create or update a test run — the container results are recorded into, so open it before qase_result_record. Scope it to a milestone, environment, plan or case list. To build one from a suite or plan use qase_regression_run; for a finished CI job use qase_ci_report, which opens, records and closes in one call. Cost: one API call, about 0.5s.
- **qase_shared_step_delete** — Delete a shared step by project code and hash. Every case referencing it loses those steps, so the reach is far wider than one record; check references first. Cannot be undone; to change content use qase_shared_step_upsert instead. Asks the user for confirmation first. Cost: one API call, about 0.4s.
- **qase_shared_step_upsert** — Create or update a shared step — a block of steps written once and reused across cases. With `hash` it updates, without it creates; shared steps are identified by hash, which qase_case_upsert takes in a step's `shared` field. Updating changes every referencing case. Cost: one API call, about 0.5s.
- **qase_suite_delete** — Delete a test suite by project code and ID. WARNING: the cases inside, and any child suites, are deleted with it along with their history, and `delete_cases` currently has no effect. Read the tree from qase_project_context and move what matters first. Asks the user for confirmation. Cost: one API call, about 0.4s.
- **qase_suite_upsert** — Create or update a test suite — the folder cases live in. With `id` it updates, without it creates; nest with `parent_id`. The existing tree comes back from qase_project_context, so read it rather than guess parent IDs. Cost: one API call, about 0.5s.
- **qase_tool_help** — Read the full documentation of one tool before calling it for the first time in a session. Every description in the tool list is deliberately short — what the tool is for and what it costs — and the details that prevent a wrong first call live here: argument semantics, limits, what cannot be undone, and which tool to use instead. Pass the tool name exactly as listed. Cost: no API call, static text, about 1ms. Cheaper than one rejected call.
- **qase_triage_defect** — Create a defect from a test failure with the context written into it; `title`, `actual_result` and `severity` are required. The API has no way to attach runs or results to a defect — reference them in actual_result. For a defect unrelated to a failure use qase_defect_upsert. Cost: one API call, about 0.5s; file one defect per distinct cause.
- **qql_help** — Read the QQL reference before writing a query. Pass a `topic`: overview, syntax, entities, operators, functions, examples, aggregation or enumValues. Field names differ per entity and from the write tools, and a query naming an unknown attribute is rejected — read `entities` first. Cost: no API call, about 2ms; cheaper than one rejected qql_search.
- **qql_search** — Search any entity with Qase Query Language — filtering, cross-project, sorting, aggregation — and the right way to fetch many records at once instead of looping over qase_get. Call qql_help first for syntax, fields and enum values. Use qase_get when you already know the one ID you want. Cost: one API call, 0.5-0.9s per page; ten records here cost 1.2s against 5.3s as ten qase_get calls.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "qase-test-management": {
    "command": "npx",
    "args": ["-y","@qase/mcp-server"]
  }
}
```

## Documentation & README

# Qase MCP Server

Official [Model Context Protocol](https://modelcontextprotocol.io) (MCP) server for [Qase Test Management Platform](https://qase.io) — connect AI assistants to your test cases, runs, defects, and more.

[![npm version](https://img.shields.io/npm/v/@qase/mcp-server)](https://www.npmjs.com/package/@qase/mcp-server)
[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
[![MCP Registry](https://img.shields.io/badge/MCP_Registry-io.qase%2Fmcp--server-blue)](https://registry.modelcontextprotocol.io/v0/servers?search=io.qase%2Fmcp-server)

## Table of Contents

- [Overview](#overview)
- [Use Cases](#use-cases)
- [Quick Start](#quick-start)
  - [Use the hosted Qase MCP (recommended)](#use-the-hosted-qase-mcp-recommended)
  - [Run it yourself](#run-it-yourself)
- [Building on top of this server](#building-on-top-of-this-server)
- [Upgrading](#upgrading)
- [Tools](#tools)
- [Documentation](#documentation)
- [Contributing](#contributing)
- [License](#license)
- [Support](#support)
- [Links](#links)

## Overview

The Qase MCP Server lets AI assistants (Claude, Cursor, Codex, and any other MCP client) read and write Qase test cases, runs, results, defects, suites, milestones, and more — through a standardized protocol, with no custom integration code.

**Features:**

- **40 task-oriented tools** (42 total, with `qase_discover_tools` and `qase_tool_help`) — consolidated from 83 v1 tools for lower token usage and better LLM accuracy
- **Composite tools** — multi-step workflows in a single call: CI reporting, defect triage, regression run setup
- **QQL support** — Qase Query Language for advanced searches across cases, runs, results, defects, and plans
- **Project context bootstrap** — one call returns full project structure (suites, milestones, environments, users, custom fields)
- **Test case review** — propose new cases or changes for review, assign reviewers, and track status (approving and merging remain UI-only)
- **Short descriptions, documentation on demand** — every tool is listed from the first request; `qase_tool_help` returns a tool's full documentation when the agent first reaches for it, and `qase_discover_tools` searches the catalogue by task
- **Hosted or self-run** — connect to `https://mcp.qase.io/mcp` (or `https://mcp-eu.qase.io/mcp` on the EU cluster) with just your Qase login, or run the server locally with your own API token
- **Tenant-safe caching & HTTP resilience** — two-tier cache (in-memory + optional Redis), connection pooling, retry with backoff
- **Escape hatch** — direct REST API access for any endpoint via `qase_api`

## Use Cases

| Scenario | Example prompt | Tool |
| --- | --- | --- |
| Bootstrap project context | "Show me the structure of project DEMO — suites, milestones, environments" | `qase_project_context` |
| Create or update a test case | "Create a high-priority smoke test case in project DEMO titled 'Login with valid credentials'" | `qase_case_upsert` |
| Report CI results | "Report these CI results for project DEMO: case 1 passed, case 2 failed with 'timeout error'" | `qase_ci_report` |
| Triage a failed test | "Create a critical defect for the login timeout failure in run #42" | `qase_triage_defect` |
| Search with QQL | "Find all failed test results from the last 7 days in project DEMO" | `qql_search` |

See [Tools](#tools) and [docs/tools.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/tools.md) for the full reference.

## Quick Start

### Use the hosted Qase MCP (recommended)

No install, no API token — connect to the Qase-hosted server and sign in with your Qase account.

> **Note:** The hosted Qase MCP is available on **every paid plan**. On the Free plan, or on a dedicated instance, [run the server yourself](#run-it-yourself) with your own API token — that works everywhere.

> **Pick the URL for your region:** `https://mcp.qase.io/mcp` for the main cloud (`app.qase.io`), `https://mcp-eu.qase.io/mcp` for the EU cluster (`app-eu.qase.io`). The examples below use the main cloud; on the EU cluster substitute the EU URL and change nothing else.

- **Claude** — open **Settings → Connectors**, find **Qase Test Management**, click **Connect**. (The directory connector is main-cloud; on the EU cluster add `https://mcp-eu.qase.io/mcp` as a custom connector.)
- **Cursor** — add `{"mcpServers": {"qase": {"url": "https://mcp.qase.io/mcp"}}}` to `.cursor/mcp.json`.
- **Codex** — add the URL `https://mcp.qase.io/mcp` in **Settings → MCPs → Add server**, or configure `~/.codex/config.toml` for the CLI.
- **VS Code** — add `{"servers": {"qase": {"type": "http", "url": "https://mcp.qase.io/mcp"}}}` to `.vscode/mcp.json`, or run **MCP: Add Server**.

Full per-client steps, other clients, and the active-workspace model: **[docs/connect.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/connect.md)**.

### Run it yourself

Install the package and provide your own API token:

```bash
npm install -g @qase/mcp-server
export QASE_API_TOKEN=your_api_token_here
```

Then point your MCP client's stdio config at the `@qase/mcp-server` binary. Full install options, client configs (Claude Desktop, Cursor, Claude Code, Codex, OpenCode), environment variables, and transports (stdio/SSE/streamable-HTTP): **[docs/self-run.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/self-run.md)**.

## Building on top of this server

For **integration authors** only — if you use the server directly, nothing here applies to you.

If your product drives this server (a plugin, an agent, a wrapper CLI), it can identify itself so its usage is attributable in Qase analytics, independently of which AI host is connected:

```bash
QASE_MCP_INTEGRATION=quality-supervisor/1.4.0   # <name>/<version>, version optional
```

The name must be on the allowlist in [`src/utils/integration-marker.ts`](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/src/utils/integration-marker.ts) — add yours in a PR. Anything unlisted or malformed is ignored, and the API call still succeeds. HTTP transports also accept the marker per request (`X-Qase-Integration` header or `?integration=`). Details: **[docs/self-run.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/self-run.md#integration-marker-for-integration-authors)**.

## Upgrading

**From 2.x to 3.0.0:** no tool was renamed and no argument changed, so prompts and automation keep working. What changed is the protocol underneath — the server speaks MCP 2026-07-28, sessions are gone, every tool is listed from the first request, and deleting takes two round trips. Self-hosting more than one replica now requires `QASE_MCP_REQUEST_STATE_KEY`.

**From v1 to v2:** v2 consolidated 83 v1 tools into **29 task-oriented tools** (30 total, including a discovery tool), and has since grown to 40 (42 total). Tool names and response shapes have changed.

Both upgrades, with the complete v1 → v2 tool mapping table and before/after examples: **[docs/migration.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/migration.md)**.

## Tools

42 tools across 6 groups (40 task-oriented tools plus two meta tools: `qase_discover_tools` to search the catalogue and `qase_tool_help` to read a tool's full documentation). All of them are listed from the first request:

| Group | Count | Description |
| --- | --- | --- |
| Read | 2 | Fetch any entity by type/ID, or bootstrap full project context in one call |
| QQL | 2 | Search across cases, runs, results, defects, and plans with Qase Query Language |
| Write | 32 | Create, update, and delete cases (single or up to 100 at once), runs, results, defects, suites, milestones, plans, shared steps, environments, and attachments; link cases and runs to Jira issues; propose and manage test case reviews |
| Composite | 3 | Multi-step workflows in one call: CI reporting, defect triage, regression run setup |
| Escape hatch | 1 | Direct REST API access for any endpoint not covered by the tools above |
| Meta | 2 | `qase_discover_tools` — search the catalogue by what you are trying to do; `qase_tool_help` — the full documentation of one tool, on demand |

Full tool-by-tool reference with parameters: **[docs/tools.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/tools.md)**.

## Documentation

- **[docs/connect.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/connect.md)** — connect to the hosted Qase MCP (Claude, Cursor, Codex, other clients)
- **[docs/self-run.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/self-run.md)** — install and run the server yourself (config, clients, transports)
- **[docs/tools.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/tools.md)** — full tool reference, groups, and the discovery model
- **[docs/troubleshooting.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/troubleshooting.md)** — auth, OAuth/connector, and SSL issues
- **[docs/migration.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/docs/migration.md)** — upgrade guides: 2.x → 3.0.0, and the v1 → v2 tool mapping

## Contributing

Contributions are welcome! See [CONTRIBUTING.md](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/CONTRIBUTING.md) for development setup, testing, and linting guidelines.

## License

MIT License — see [LICENSE](https://github.com/qase-tms/qase-mcp-server/blob/HEAD/LICENSE) for details.

## Support

- **Documentation**: https://docs.qase.io/en/articles/14984302-qase-mcp-server
- **Email**: support@qase.io
- **GitHub Issues**: https://github.com/qase-tms/qase-mcp-server/issues

## Links

- **Qase Platform**: https://qase.io
- **Qase Documentation**: https://help.qase.io
- **API Documentation**: https://developers.qase.io
- **MCP Protocol**: https://modelcontextprotocol.io
- **Issue Tracker**: https://github.com/qase-tms/qase-mcp-server/issues