Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Execute Quality Gate Report

qmetry_execute_quality_gate_report
Read-onlyIdempotent

Execute quality gate reports for release readiness by running specified gates against project, release, or cycle scopes. Get analytics results to assess project health and make data-driven decisions.

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")

  • baseUrl (string): The base URL for the QMetry instance (must be a valid URL)

  • 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.

  • 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. 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 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: 'page' specifies the page number for paginated report results. 7. OPTIONAL: 'limit' sets the maximum number of records per page (defaults to 100). 8. Call 'Fetch Quality Gate Configuration' first to discover available gates and report parameters. 9. The response is returned exactly as received from the backend — no transformation is applied.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoOptional page number for paginated report results.
limitNoMaximum number of records to return per page. Defaults to 100 if not specified.
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
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').
Behavior5/5

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

The annotations provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds important behavioral context: it 'forwards the request' to a backend engine, is non-transforming ('response is returned exactly as received'), and includes a prerequisite call to fetch configuration. It also discloses pagination behavior (limit defaults to 100) and expected output structure in examples. This significantly exceeds what annotations alone convey.

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 well-structured with clear sections: purpose sentence, toolset, parameter list, use cases, examples, and hints. Every section serves a distinct purpose—no redundancy beyond reasonable repetition. The examples and hints are concise and actionable, making the length justified despite the tool's complexity.

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?

The tool has 9 parameters, no output schema, and moderate complexity. The description covers purpose, all parameters with required/optional hints, use cases, examples with expected output format, and even a prerequisite call. It is fully self-contained for an agent to know how to invoke the tool, what to expect, and how to prepare. Given the rich annotations, this is complete.

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 value by labeling required parameters with '*required*', providing concrete examples (e.g., projectId: 45851), and clarifying use cases for each optional parameter. However, much of the parameter text mirrors the schema descriptions, so the added meaning is moderate rather than extensive.

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 clearly states the tool's function: 'Execute a quality gate report by forwarding the request to the backend analytics engine and returning the results.' This specific verb+resource combination distinguishes it from sibling tools like fetch_quality_gate_configuration (which fetches configuration) and export_html_report (which exports). The title and use cases further reinforce the unique purpose.

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?

The 'Use Cases' section lists four concrete scenarios for when to use the tool, and Hint #8 explicitly instructs to 'Call Fetch Quality Gate Configuration first' to discover gates, which is an alternative/prerequisite. However, it does not explicitly state when not to use this tool or mention other alternatives like export_html_report, so it falls just short of full alternatives coverage.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SmartBear/smartbear-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server