Skip to main content
Glama
qase-tms

Qase MCP Server

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

Create case review

qase_review_create

Open a test case review to propose edits to an existing case or draft a new one; pass case_id for changes, omit it for new cases.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesProject code, e.g. DEMO
tagsNoTag names, e.g. ["smoke", "billing"]
typeNoType label or numeric ID
layerNoLayer label or numeric ID
stepsNoOrdered test steps; omit for a case without steps
titleNoTest case title
statusNoStatus label or numeric ID
case_idNoTest case to propose changes to. With it, an "edit" review is created and only the fields being changed need to be sent. Without it, a "create" review is opened for a brand-new case draft and `title` is required.
behaviorNoBehavior label or numeric ID
is_flakyNoIs flaky: 0=No, 1=Yes; a boolean works too.
priorityNoPriority label or numeric ID (0=not set, 1=high, 2=medium, 3=low)
severityNoSeverity label or numeric ID
suite_idNoID of the suite that holds the case
reviewersNoReviewers: AUTHOR UUIDs (see qase_get { entity: "author" }) or emails, which resolve to them. Not user IDs. The token owner authors the review and cannot review their own review. Omit to assign them later in the UI.
automationNoAutomation: 0=Manual, 1=To be automated, 2=Automated (label or ID)
steps_typeNoStep style: "classic" action/expected, or "gherkin" scenario text
attachmentsNoHashes from qase_attachment_upload
descriptionNoFree-form description of what the case covers
custom_fieldNoCustom fields by ID, e.g. { "12": "value" }
milestone_idNoID of the milestone the case belongs to
preconditionsNoState the system must be in before the steps run
postconditionsNoState to restore or verify after the steps run

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare destructiveHint=false, so the description carries real weight here: it discloses that approval/merge/decline are UI-only (a non-obvious capability gap that prevents futile calls) and gives a latency/call-cost estimate. It stops short of describing the review's resulting state (draft vs pending) or permission requirements beyond what the schema states.

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?

Four tight sentences, front-loaded with purpose and the case_id decision, then alternatives, then the API limitation. No filler and no repetition of schema content.

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

Completeness5/5

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

For a 22-parameter mutation tool with nested step objects and no output schema, the description covers routing, the edit/create branch, alternatives, cost, and the API's missing lifecycle endpoints. Nothing an agent needs to decide and call correctly is absent.

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 schema already documents all 22 parameters, including the edit-vs-create meaning of case_id. The description reinforces the case_id branch but adds no syntax, format, or default detail beyond the schema — the baseline 3 applies when the schema does the heavy lifting.

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 ('Open a test case review') and frames it memorably as 'the pull-request flow for cases', which immediately distinguishes it from case creation. It also names the two sibling tools an agent might confuse it with (qase_review_bulk_create, qase_review_list).

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?

Gives an explicit branch condition: pass `case_id` to edit, omit it to create, and 'send only the fields that change' for edits. It routes bulk work to qase_review_bulk_create and status checks to qase_review_list, and warns that approve/merge/decline have no API surface.

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