Skip to main content
Glama
qase-tms

Qase MCP Server

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

Call Qase API

qase_api

Call any Qase REST endpoint directly when no dedicated tool exists. Send method, path, optional body or query for cases not covered by specialized tools.

Instructions

Call any Qase REST endpoint directly, for the few things no dedicated tool covers: method, a /v1/… path on the configured host, optional body or query. Prefer a dedicated tool where one exists — they normalize enums and validate before spending a call. JSON only; uploads go through qase_attachment_upload. A DELETE asks for confirmation like the dedicated delete tools. Cost: one API call, 0.3-1.5s.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoRequest body for POST/PUT/PATCH
pathYesAPI path starting with a version segment (e.g., "/v1/project/DEMO/run")
queryNoQuery parameters
methodNoHTTP methodGET

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.0.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / body / propertyNames
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / query / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. Changed3 schema fields changedv2.7.4
    • changedInput schema / properties / path / description
      Previous value: -"API path starting with /v1/ (e.g., \"/v1/project/DEMO/run\")"New value: +"API path starting with a version segment (e.g., \"/v1/project/DEMO/run\")"
    • removedInput schema / properties / path / minLength
      Removed value: -1
    • addedInput schema / properties / path / pattern
      Added value: +"^\\/v\\d+\\/\\S*$"
  3. Addedv2.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations carry only destructiveHint=false, so the description does real work: it discloses JSON-only payloads, that DELETE triggers a confirmation prompt like the dedicated delete tools, and an expected cost/latency (one API call, 0.3-1.5s). It stops short of covering auth expectations or how errors from arbitrary endpoints surface, which for an unbounded passthrough tool would be useful.

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 what the tool is and the routing rule, then the constraints (JSON, uploads, DELETE confirmation) and finally the cost. No sentence is redundant.

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 an unbounded REST passthrough with no output schema, the definition covers routing, format, confirmation behavior and cost. The remaining gap is error/response handling for arbitrary endpoints (e.g., how non-2xx responses are surfaced), which a generic caller would benefit from knowing.

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, but the description adds genuinely new meaning by noting that dedicated tools 'normalize enums and validate' while this one does not — implying callers must supply raw, unvalidated values. It also clarifies the path is 'on the configured host' and that body/query are optional.

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 (call) and resource (any Qase REST endpoint) and immediately positions itself as the escape hatch 'for the few things no dedicated tool covers'. It is unmistakable against siblings like qase_get or the dedicated *_upsert/*_delete 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?

Gives an explicit when-to-use rule ('only where no dedicated tool covers it'), an explicit preference ('Prefer a dedicated tool where one exists') with the reason (they normalize enums and validate before spending a call), and a named exclusion/alternative (uploads go through qase_attachment_upload).

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