Skip to main content
Glama
qase-tms

Qase MCP Server

Official
by qase-tms
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

Build regression run

qase_regression_run

Create and start a Qase test run from a suite, test plan, or case IDs in one step, resolving cases automatically. Use for regression runs that need to be opened, not closed.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesProject code, e.g. DEMO
titleYesRun title
plan_idNoCreate run from an existing test plan
suite_idsNoInclude cases from these suites
descriptionNoWhat this regression run covers
milestone_idNoID of the milestone the run belongs to
include_casesNoExplicit case IDs to include
environment_idNoID of the environment the run executes against

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / code / description
      Previous value: -"Project code (2-10 uppercase letters, numbers, or underscores)"New value: +"Project code, e.g. DEMO"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "cases_added": {
-      "description": "Number of cases added to the run",
-      "type": "integer"
-    },
-    "run": {
-      "description": "Full run entity",
-      "type": "object"
-    },
-    "run_id": {
-      "description": "Created run ID",
-      "type": "integer"
-    }
-  },
-  "required": [
-    "run_id",
-    "cases_added"
-  ],
-  "type": "object"
-}New value: +null
  2. Changed3 schema fields changedv2.5.1
    • addedInput schema / properties / description / description
      Added value: +"What this regression run covers"
    • addedInput schema / properties / environment_id / description
      Added value: +"ID of the environment the run executes against"
    • addedInput schema / properties / milestone_id / description
      Added value: +"ID of the milestone the run belongs to"
  3. Addedv2.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Only destructiveHint=false is annotated, so the description carries most of the burden, and it does add real context: it resolves cases itself, it is an open-only operation, and it costs two API calls (~1s). It stops short of stating whether it is idempotent on repeated calls or what happens if the run title collides, which are the remaining relevant traits for a create tool.

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?

Three sentences, zero filler: the core action, the negative scope with its two routing alternatives, then the cost note. The most decision-relevant content (what it builds) is front-loaded.

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

Completeness4/5

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

With 8 parameters, no output schema, and minimal annotations, the description supplies the operational context an agent needs — what it does, what it does not do, and latency. It is near-complete, missing only guidance on combining or prioritizing the case-source 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 description coverage is 100%, so the baseline is 3. The description's framing of three case sources loosely maps to plan_id/suite_ids/include_cases but adds no mutual-exclusivity rules, precedence between the modes, or fallback behavior when more than one source is supplied.

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?

States a specific verb and resource ('Build and start a test run') and enumerates the three accepted case sources — suite, plan, or explicit case IDs — in one step. An agent can distinguish it from qase_run_upsert and qase_ci_report without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly scopes the tool as an opener, not a closer ('it opens a run, it does not close one'), and names both alternatives with the condition that selects them: qase_ci_report for a finished pipeline, qase_run_upsert for hand assembly. Nothing is left to inference.

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

Deploy Server

Other Tools