# Qase Test Management (npm · @qase/mcp-server)

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

- Trust score: 76/100 (medium)
- Change this week: +51
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mcp.qase.io`: 38/100, [markdown](https://verifymcp.io/servers/io-qase-mcp-server/mcp.md), [page](https://verifymcp.io/servers/io-qase-mcp-server/mcp)
- npm · `@qase/mcp-server`: 76/100 (this document), [markdown](https://verifymcp.io/servers/io-qase-mcp-server/qase-mcp-server.md), [page](https://verifymcp.io/servers/io-qase-mcp-server/qase-mcp-server)

## Channel facts

- Registry: `npm`
- Package: `@qase/mcp-server`
- Version: `2.0.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Supply Chain Security**: 87/100
  - No malware found by supply-chain analysis.
  - Only part of the dependency tree could be resolved (250 of 313), so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Only part of the dependency tree could be resolved (250 of 313), so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 97/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to qase-tms/qase-mcp-server).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 10 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 80/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1938 tokens (~149/item across 13 items; 13 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 90/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 64% of tool parameters carry a description.
  - Structured output schemas are declared (46% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### Claude

```bash
claude mcp add io-qase-mcp-server -- npx -y @qase/mcp-server
```

### Codex

```bash
codex mcp add io-qase-mcp-server -- npx -y @qase/mcp-server
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "io-qase-mcp-server": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@qase/mcp-server"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add io-qase-mcp-server --command npx --arg -y --arg @qase/mcp-server
```

### Hermes

```yaml
mcp_servers:
  io-qase-mcp-server:
    command: "npx"
    args: ["-y", "@qase/mcp-server"]
```

### Other

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

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 76, +2)

No change was recorded against any check on this day. Supply Chain Security went from 83 to 87.

### 2026-08-02 (score 74, +69)

- [security improvement] Install scripts: unverified → pass
- [security improvement] Provenance: unverified → pass
- [security improvement] Known CVEs: unverified → partial
- [security improvement] Malware scan: unverified → pass
- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [security] The attested source repository moved: qase-tms/qase-mcp-server
- [functional improvement] Maintenance: unverified → pass
- [functional improvement] Dependency health: unverified → partial
- [functional improvement] License: unverified → pass
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Schema quality: unverified → excellent
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] Schema quality: unverified → 100
- [functional] Licence: MIT

### 2026-08-01 (score 5, −19)

- [functional regression] Schema quality: 100 → unverified
- [functional regression] Tool coverage: 100 → unverified

### 2026-07-31 (score 24, +18)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 6, −22)

- [security regression] Malware scan: pass → unverified
- [functional regression] Security disclosure: unverified → fail
- [functional regression] Dependency health: partial → unverified

### 2026-07-29 (score 28, +4)

- [functional regression] Security disclosure: fail → unverified
- [functional improvement] Dependency health: unverified → partial

### 2026-07-28 (score 24, −1)

- [functional regression] Security disclosure: unverified → fail
- [functional regression] Dependency health: partial → unverified

### 2026-07-26 (score 25)

First indexed and scored.

## MCP tools (13)

### `qase_project_context` (~90 tokens)

Get full project context in one call: project details, suites tree, milestones, environments, custom fields, and users. Cached for 5 minutes. Use this as the first call when starting work with a project — it seeds all the metadata the LLM needs without making 6 separate list calls.

Input parameters:

- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)

Output parameters:

- `custom_fields` (object): Custom fields list
- `environments` (object): Environments list
- `milestones` (object): Milestones list
- `project` (object): Project details
- `suites` (object): Suites list with entities array
- `users` (object): Team members list

### `qase_get` (~149 tokens)

Get any Qase entity by type and ID. Supports field projection via the `fields` parameter. For project-scoped entities (case, suite, run, result, plan, defect, milestone, environment, shared_step, shared_parameter, configuration), `code` is required. For global entities (user, author, attachment, custom_field), `code` can be omitted.

Input parameters:

- `code` (string): Project code (required for most entities)
- `entity` (string, required): Entity type to fetch
- `fields` (array): Optional field projection — only return these top-level fields. Pass ["*"] for all fields.
- `id` (required): Entity ID (number) or hash (string)

### `qql_search` (~161 tokens)

Search entities using Qase Query Language (QQL) with powerful filtering and cross-project queries

Input parameters:

- `limit` (integer): Maximum number of results to return (default: 10, max: 100)
- `offset` (integer): Number of results to skip for pagination
- `query` (string, required): QQL query expression. Examples: - entity = "case" and project = "DEMO" and status = "Actual" - entity = "defect" and severity = "blocker" and status = "open" - entity = "result" and status = "failed"…

Output parameters:

- `entities` (array): Matching entities
- `total` (integer): Total matching entities

### `qql_help` (~40 tokens)

Get help and examples for Qase Query Language (QQL) syntax

Input parameters:

- `topic` (string): Specific help topic, or omit for general overview

### `qase_case_upsert` (~341 tokens)

Create or update a test case. If `id` is provided, updates the existing case; if omitted, creates a new one. Enum fields (priority, severity, type, etc.) accept both labels ("high", "blocker") and numeric IDs — the server normalizes automatically.

Input parameters:

- `attachments` (array)
- `automation` (string): Automation status (label, slug, or numeric ID: 0=Manual / is-not-automated, 1=To be automated, 2=Automated)
- `behavior` (string): Behavior label or numeric ID
- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)
- `custom_field` (object)
- `description` (string)
- `id` (integer): Case ID — if provided, updates the case; if omitted, creates a new one
- `is_flaky` (boolean)
- `layer` (string): Layer label or numeric ID
- `milestone_id` (integer)
- `postconditions` (string)
- `preconditions` (string)
- `priority` (string): Priority label or numeric ID (0=not set, 1=high, 2=medium, 3=low)
- `severity` (string): Severity label or numeric ID
- `status` (string): Status label or numeric ID
- `steps` (array)
- `steps_type` (string)
- `suite_id` (integer)
- `tags` (array)
- `title` (string, required): Test case title
- `type` (string): Type label or numeric ID

### `qase_run_upsert` (~188 tokens)

Create or update a test run. If `id` is provided, updates; if omitted, creates.

Input parameters:

- `cases` (array): Case IDs to include
- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)
- `custom_field` (object)
- `description` (string)
- `end_time` (string): RFC3339 end time
- `environment_id` (integer)
- `id` (integer): Run ID — if provided, this is an update (note: Qase API has limited run update support)
- `is_autotest` (boolean)
- `milestone_id` (integer)
- `plan_id` (integer): Test plan to base run on
- `start_time` (string): RFC3339 start time
- `tags` (array)
- `title` (string, required): Run title

### `qase_result_record` (~100 tokens)

Record one or more test results into a run. Accepts an array of results — a single entry uses the single-result API, multiple entries use bulk. Each result must include a status; case_id is recommended.

Input parameters:

- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)
- `results` (array, required): One or more results to record
- `run_id` (integer, required): Run ID to record results into

### `qase_defect_upsert` (~157 tokens)

Create or update a defect. If `id` is provided, updates (including status changes and resolve). If omitted, creates a new defect. Set `status: "resolved"` to resolve an existing defect.

Input parameters:

- `actual_result` (string)
- `attachments` (array)
- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)
- `custom_field` (object)
- `id` (integer): Defect ID — if provided, updates; if omitted, creates
- `severity` (string)
- `status` (string): Set to "resolved" to resolve the defect
- `tags` (array)
- `title` (string, required): Defect title

### `qase_ci_report` (~153 tokens)

Report CI/CD test results in one call: creates a run, records all results, and optionally completes the run. Replaces the 3-4 step manual workflow of create_run → bulk_create_results → complete_run. Designed for CI pipeline integration.

Input parameters:

- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)
- `complete` (boolean): Complete the run after recording results (default: true)
- `environment_id` (integer)
- `is_autotest` (boolean): Mark as automated run (default: true)
- `results` (array, required): Test results to record
- `title` (string, required): Run title (e.g., "CI Build #1234")

Output parameters:

- `results_recorded` (integer): Number of results recorded
- `run_id` (integer): Created run ID
- `run_status` (string)

### `qase_triage_defect` (~152 tokens)

Create a defect from a test failure and optionally link it to failed results. Streamlines the triage workflow: create defect → link to failing tests.

Input parameters:

- `actual_result` (string): Observed behavior
- `attachments` (array)
- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)
- `custom_field` (object)
- `description` (string)
- `failed_result_ids` (array): Result hashes to link to this defect (from the run)
- `run_id` (integer): Run containing the failed results
- `severity` (string)
- `tags` (array)
- `title` (string, required): Defect title

Output parameters:

- `defect` (object): Full defect entity
- `defect_id` (integer): Created defect ID
- `linked_results` (integer): Number of linked result hashes

### `qase_regression_run` (~155 tokens)

Set up a regression test run in one call. Accepts case selection by suite IDs, explicit case IDs, or plan ID. Creates the run and adds all matching cases. Replaces the multi-step workflow of find cases → create run → add cases.

Input parameters:

- `code` (string, required): Project code (2-10 uppercase letters, numbers, or underscores)
- `description` (string)
- `environment_id` (integer)
- `include_cases` (array): Explicit case IDs to include
- `milestone_id` (integer)
- `plan_id` (integer): Create run from an existing test plan
- `suite_ids` (array): Include cases from these suites
- `title` (string, required): Run title

Output parameters:

- `cases_added` (integer): Number of cases added to the run
- `run` (object): Full run entity
- `run_id` (integer): Created run ID

### `qase_discover_tools` (~122 tokens)

Search for and activate additional Qase tools. By default, only core tools are visible. Use this to find tools for specific needs: deletions, milestone management, attachments, etc. Found tools are automatically activated and become available for use.

Input parameters:

- `activate` (boolean): If true (default), found tools are activated and become available for use
- `category` (string): Filter by tool category
- `query` (string): Search query to find tools by name or description. Examples: "delete", "milestone", "attachment", "suite"

Output parameters:

- `activated` (integer): Number of newly activated tools
- `found` (integer): Number of matching tools
- `tools` (array)

### `qase_api` (~130 tokens)

Direct Qase REST API call for endpoints not covered by other tools. Pass the HTTP method, path (starting with /v1/), and optional body/query. See https://developers.qase.io for API reference. Use this as an escape hatch when the dedicated tools do not cover your use case.

Input parameters:

- `body` (object): Request body for POST/PUT/PATCH
- `method` (string): HTTP method
- `path` (string, required): API path starting with /v1/ (e.g., "/v1/project/DEMO/run")
- `query` (object): Query parameters

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/io-qase-mcp-server/qase-mcp-server#diagnostics

## Score history

- 2026-08-03: 76
- 2026-08-02: 74
- 2026-08-01: 5
- 2026-07-31: 24
- 2026-07-30: 6
- 2026-07-29: 28
- 2026-07-28: 24
- 2026-07-26: 25

## Links

- npm package: https://www.npmjs.com/package/@qase/mcp-server
- Socket report: https://socket.dev/npm/package/@qase/mcp-server
- Repository: https://github.com/qase-tms/qase-mcp-server
- Website: https://qase.io/
- Changelog RSS feed: https://verifymcp.io/servers/io-qase-mcp-server/qase-mcp-server/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/io-qase-mcp-server/qase-mcp-server/changelog.json
- HTML version of this page: https://verifymcp.io/servers/io-qase-mcp-server/qase-mcp-server