Skip to main content
Glama
qase-tms

Qase MCP Server

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

Triage failure into defect

qase_triage_defect

Create a defect from a test failure by providing title, actual result, and severity. Use for triaging failed tests into actionable defects.

Instructions

Create a defect from a test failure, with the failure context written into it. Requires title, actual_result and severity — the API rejects a defect missing any of the three. Note: the API offers no way to attach existing runs or results to a defect. The runs and results seen on a defect in the UI are populated by the test runner when it reports a result as a defect, so there is nothing to pass here for that — reference the failing results inside actual_result instead, and do not expect a link to appear. For a defect unrelated to a test failure use qase_defect_upsert. Cost: one API call, about 0.5s. Triaging a whole run means one call per defect, so cluster identical failures and file one defect per distinct cause rather than one per failed test.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesProject code (2-10 uppercase letters, numbers, or underscores)
tagsNoTag names, e.g. ["regression", "payments"]
titleYesDefect title
severityYesRequired by the API
attachmentsNoAttachment hashes from qase_attachment_upload
descriptionNoExtra context beyond the observed behavior
custom_fieldNoCustom field values keyed by field ID, e.g. { "12": "value" }
actual_resultYesObserved behavior. Required by the API

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
defectNoFull defect entity
defect_idYesCreated defect ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.5.1
    • addedInput schema / properties / custom_field / description
      Added value: +"Custom field values keyed by field ID, e.g. { \"12\": \"value\" }"
    • addedInput schema / properties / description / description
      Added value: +"Extra context beyond the observed behavior"
    • addedInput schema / properties / tags / description
      Added value: +"Tag names, e.g. [\"regression\", \"payments\"]"
  2. Changed1 schema field changedv2.2.1
    • addedInput schema / properties / attachments / description
      Added value: +"Attachment hashes from qase_attachment_upload"
  3. Changed7 schema fields changedv2.1.1
    • changedInput schema / properties / actual_result / description
      Previous value: -"Observed behavior"New value: +"Observed behavior. Required by the API"
    • removedInput schema / properties / failed_result_ids
      Removed value: -{
-  "description": "Result hashes to link to this defect (from the run)",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
    • removedInput schema / properties / run_id
      Removed value: -{
-  "description": "Run containing the failed results",
-  "exclusiveMinimum": 0,
-  "type": "integer"
-}
    • addedInput schema / properties / severity / description
      Added value: +"Required by the API"
    • changedInput schema / required
      Previous value: -[
-  "code",
-  "title"
-]New value: +[
+  "code",
+  "title",
+  "severity",
+  "actual_result"
+]
    • removedOutput schema / properties / linked_results
      Removed value: -{
-  "description": "Number of linked result hashes",
-  "type": "integer"
-}
    • changedOutput schema / required
      Previous value: -[
-  "defect_id",
-  "linked_results"
-]New value: +[
+  "defect_id"
+]
  4. Addedv2.0.0

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining API rejection behavior for missing required fields, the impossibility of attaching existing runs/results, why no link will appear, and the cost profile (about 0.5s per call, one call per defect). This gives the agent crucial execution expectations. There is no contradiction with the annotations.

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?

The description is dense but every sentence earns its place: purpose, required fields, a key API limitation, alternative tool, cost, and triage strategy. It is front-loaded with the core purpose and stays focused despite covering a complex behavioral caveat.

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?

Given the tool's complexity, 8 parameters, and output schema, the description covers the essential operational context: when to use it, what the API rejects, what to expect in the UI, how to handle failure context, and how to batch triage efficiently. The output schema exists, so not restating return values is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful guidance beyond the schema, especially for actual_result: 'reference the failing results inside actual_result instead' and 'do not expect a link to appear'. It also reinforces that title, actual_result, and severity are mandatory, which complements the schema's required list.

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?

The description states a specific action and resource: 'Create a defect from a test failure' and clarifies the distinguishing scope, including what the tool is not for by pointing to qase_defect_upsert for unrelated defects. This clearly separates it from sibling tools.

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?

The description gives explicit when-to-use guidance: use for test failures, and for unrelated defects use qase_defect_upsert. It also provides practical usage advice for batch triage: cluster identical failures and file one defect per distinct cause rather than one per failed test.

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