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 a quality gate report to evaluate project health against gate criteria, with optional scoping by release and cycle for release readiness insights.

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.

  • 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.
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').
Install Server

TDQS

A4.3/5.0
Behavior4/5

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

The description notes that the tool forwards the request to the backend analytics engine and returns results unchanged: 'The response is returned exactly as received from the backend — no transformation is applied.' This goes beyond the annotations by clarifying the pass-through behavior and expected output. Annotations already cover read-only, idempotent, and non-destructive behavior, so extra depth is not required.

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 description is well-structured with clear headings for parameters, use cases, examples, and hints, and opens with a concise summary sentence. However, it is verbose and repeats schema field descriptions almost verbatim, making it longer than necessary. Several hints also restate information already present in the parameter list.

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?

For an 8-parameter operation with no output schema, this description is exceptionally complete: it documents every parameter, gives multiple examples, includes expected output, states pagination defaults, and names the prerequisite fetch-config tool. An agent has everything needed to call this tool correctly.

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 description coverage is 100%, so the baseline is 3. The description adds value through concrete examples with actual project/release/cycle IDs, expected output shapes, and hints that clarify required vs optional parameters. It also explains the relationship between releaseId and cycleIds scoping, which goes beyond the schema's individual field descriptions.

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 first sentence states a specific verb and resource: 'Execute a quality gate report by forwarding the request to the backend analytics engine and returning the results.' It clearly distinguishes the action from sibling tools like qmetry_fetch_quality_gate_configuration, which discovers gates, and qmetry_export_html_report, which exports a report. The use cases reinforce the purpose by describing release readiness and gate assessment scenarios.

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?

Use cases explicitly describe when to use the tool, such as generating a release readiness report or evaluating project health against gate criteria. Hint 8 adds a clear prerequisite workflow: call 'Fetch Quality Gate Configuration' first to discover available gates and report parameters. It does not explicitly exclude sibling tools, but the integration guidance is strong enough.

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

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