Skip to main content
Glama
qase-tms

Qase MCP Server

Official
by qase-tms

Bulk create case reviews

qase_review_bulk_create

Open multiple test case reviews in one API call to propose several test case changes, with all-or-nothing validation and separate per-review results.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesProject code, e.g. DEMO
reviewsYesReviews to open. Validated as a whole: if any item is invalid, NOTHING is created. Once valid, each item is processed individually and reported separately.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare destructiveHint=false. The description adds real behavioral context beyond that: the one-API-call cost model regardless of batch size, and the API's lack of approve/merge/decline endpoints. It doesn't restate the atomic all-or-nothing validation (that lives in the schema), so it complements rather than duplicates structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight paragraph with the core purpose and sibling relationship front-loaded. Every clause carries information; density is high but not padded.

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?

For a mutation tool with no output schema, it covers cost, field inheritance from the single-create sibling, and API limitations. It leaves return-value/reporting format and permission requirements implicit, which is a minor gap rather than a blocking one.

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 both parameters thoroughly. The description's only added semantics is the case_id edit-vs-create distinction, which the schema also states ('Omit for a new-case draft'). Baseline 3 is correct 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 (bulk create case reviews) and explicitly frames itself as 'the batch form of qase_review_create.' An agent can distinguish it from the single-create sibling without opening either schema.

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

Usage Guidelines4/5

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

Gives a clear selecting condition ('for proposing more than one change') and routes to alternatives: qase_review_create for the single case and qase_review_list to read status. It also rules out approving/merging/declining as UI-only. No explicit when-not-to-use beyond the batch-size condition, but coverage is strong.

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