Skip to main content
Glama
Sign In
SmartBear MCP server

SmartBear MCP server

Official
by SmartBear
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

QMetry: Execute Quality Gate Report

qmetry_execute_quality_gate_report
Read-onlyIdempotent

Executes quality gate reports for projects, releases, cycles, or external issue keys and returns backend analytics results for release-readiness and gate assessments.

Instructions

Execute a quality gate report by forwarding the request to the backend analytics engine and returning the results.

Toolset: AI Agent

Parameters:

  • projectKey (string): Project key - unique identifier for the project (default: "default")

  • reportName (string) required: Report name identifier (e.g. 'RR' for Release Readiness).

  • gateIdentifier (string) required: Gate identifier to execute the report against (e.g. 'GATE1').

  • projectId (number) required: Numeric project ID for the report scope.

  • releaseId (number): Optional release ID to scope the report to a specific release.

  • cycleIds (array): Optional array of cycle IDs to scope the report to specific cycles.

  • extKeys (array): Optional array of external issue keys (e.g. Jira keys like 'PROJ-123') to scope the report to specific external requirements.

  • page (number): Optional page number for paginated report results.

  • limit (number): Maximum number of records to return per page. Defaults to 100 if not specified. (default: 100)

Use Cases: 1. Generate a release readiness report for a specific project, release, and cycle 2. Execute a quality gate assessment to evaluate project health against gate criteria 3. Run a gate report scoped to specific cycles within a release 4. Run a gate report scoped to specific external (e.g. Jira) issue keys 5. Produce analytics data for quality gate evaluation and decision-making

Examples:

  1. Execute a release readiness report for project 45851, release 90698, cycle 129140

{
  "reportName": "RR",
  "gateIdentifier": "GATE1",
  "projectId": 45851,
  "releaseId": 90698,
  "cycleIds": [
    129140
  ]
}

Expected Output: { "data": [...], "total": 0, "success": true, "page": {} }

  1. Execute a gate report scoped to specific external issue keys

{
  "reportName": "RR",
  "gateIdentifier": "GATE1",
  "projectId": 45851,
  "releaseId": 90698,
  "extKeys": [
    "PROJ-101",
    "PROJ-102"
  ]
}

Expected Output: { "data": [...], "total": 0, "success": true, "page": {} }

  1. Execute a gate report without release/cycle scoping

{
  "reportName": "RR",
  "gateIdentifier": "GATE1",
  "projectId": 45851
}

Expected Output: { "data": [...], "total": 0, "success": true, "page": {} }

Hints: 1. REQUIRED: 'reportName' identifies the report type (e.g. 'RR' for Release Readiness). 2. REQUIRED: 'gateIdentifier' identifies which gate to evaluate (e.g. 'GATE1'). 3. REQUIRED: 'projectId' must be a valid numeric project ID. 4. OPTIONAL: 'releaseId' scopes the report to a specific release. 5. OPTIONAL: 'cycleIds' scopes the report to specific test cycles within the release. 6. OPTIONAL: 'extKeys' scopes the report to specific external issue keys (e.g. Jira keys like 'PROJ-123'). 7. OPTIONAL: 'page' specifies the page number for paginated report results. 8. OPTIONAL: 'limit' sets the maximum number of records per page (defaults to 100). 9. Call 'Fetch Quality Gate Configuration' first to discover available gates and report parameters. 10. The response is returned exactly as received from the backend — no transformation is applied.

Input Schema

NameRequiredDescriptionDefault
pageNoOptional page number for paginated report results.
limitNoMaximum number of records to return per page. Defaults to 100 if not specified.
extKeysNoOptional array of external issue keys (e.g. Jira keys like 'PROJ-123') to scope the report to specific external requirements.
cycleIdsNoOptional array of cycle IDs to scope the report to specific cycles.
projectIdYesNumeric project ID for the report scope.
releaseIdNoOptional release ID to scope the report to a specific release.
projectKeyNoProject key - unique identifier for the projectdefault
reportNameYesReport name identifier (e.g. 'RR' for Release Readiness).
gateIdentifierYesGate identifier to execute the report against (e.g. 'GATE1').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.43.0
    • addedInput schema / properties / extKeys
      Added value: +{
+  "description": "Optional array of external issue keys (e.g. Jira keys like 'PROJ-123') to scope the report to specific external requirements.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. Changed1 schema field changedv0.40.0
    • removedInput schema / properties / baseUrl
      Removed value: -{
-  "description": "The base URL for the QMetry instance (must be a valid URL)",
-  "format": "uri",
-  "type": "string"
-}
  3. Changed1 schema field changedv0.37.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. Addedv0.34.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description does add real behavior: the call is a passthrough to a backend analytics engine with 'no transformation is applied,' and pagination defaults to 100 per page. It says nothing about permissions, error/failure modes, or whether repeated execution could be expensive, which remains a gap for an analytics-execution tool.

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

Conciseness3/5

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

The purpose sentence is well front-loaded, but the body repeats the same nine parameters three times (parameter list, hints, and schema-within-schema), and the hints section is essentially a restatement of the required/optional flags already encoded in the schema. The three worked examples earn their space; the duplicated parameter prose does not.

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?

With no output schema, the description usefully supplies an expected response shape ({ data, total, success, page }), the pagination defaults, and a prerequisite sibling call — enough for an agent to invoke this correctly. The only shortfall is the absence of failure/empty-result behavior for a report that may return no gated data.

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 alone already documents all nine parameters; the description reproduces that list nearly verbatim. The examples do add some meaning — showing how releaseId/cycleIds/extKeys narrow scope in combination, and that extKeys take Jira-style keys like 'PROJ-101' — which lifts it slightly, but most of the content is redundant with 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 ('Execute a quality gate report') plus the mechanism ('forwarding the request to the backend analytics engine and returning the results'). It also names the sibling qmetry_fetch_quality_gate_configuration as the discovery step, so an agent can separate executing a gate from configuring one 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?

Five enumerated use cases and hint 9 ('Call Fetch Quality Gate Configuration first to discover available gates') give clear when-to-use and prerequisite guidance. What's missing is any exclusion — nothing says when not to execute a gate report, or what to do if the gate identifier is unknown/invalid.

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