Skip to main content
Glama
qase-tms

Qase MCP Server

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

Update case review

qase_review_update
Idempotent

Update an open Qase review by ID: change proposed test case fields or reviewers. Changing case fields resets approvals; updating only reviewers keeps existing approvals.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesReview ID
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
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
reviewersNoReplaces the current reviewer list; an empty array removes everyone. Omit to leave it unchanged. Author UUIDs or emails. Changing ONLY reviewers keeps existing approvals.
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?

Goes beyond the annotations by disclosing a real side effect — changing the proposal resets all existing approvals while editing only `reviewers` preserves them — plus cost and runtime. Minor tension worth noting: an operation that silently discards approvals while `destructiveHint: false` is declared; the description resolves it for the agent, but the annotation pair is not fully aligned with the behavior.

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 clauses, front-loaded with the purpose, then the destructive caveat, then the capability boundary, then cost. Every sentence carries actionable information and nothing is padded.

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 no output schema, the description supplies the two things an agent cannot infer from the schema — the approval-reset side effect and the fact that approve/merge/decline live only in the UI — so a caller has everything needed to invoke it safely.

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% and the schema itself already documents the reviewers-replacement/reset semantics, so the description largely restates what the parameter docstrings provide. Baseline 3 is appropriate; it adds no syntax or format detail beyond the schema.

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 ('Update an open review') plus the exact editable surface (proposed case fields, reviewers, or both) keyed by review ID. This clearly separates it from qase_review_create, qase_review_delete and 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?

Explicitly routes the agent: approvals/merging/declining are UI-only and not callable here, and status is read via qase_review_list. It also gives the decision rule between editing the proposal versus only `reviewers`, which is exactly the when/when-not guidance this dimension rewards.

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