Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Issue Executions

qmetry_fetch_issue_executions
Read-onlyIdempotent

Retrieve all test case executions linked to a QMetry defect, presented as a unified table with test suite details, release, cycle, platform, execution status, and custom UDF fields.

Instructions

Get test case executions linked to a QMetry-native (non-Jira) defect/issue. ALWAYS present results as a unified table: Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label columns…>. NEVER show a separate type+value UDF breakdown — always combine identification fields and UDF values in one table per execution row.

Toolset: Issues

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)

  • linkedAssetId (number) required: Numeric defect ID of the QMetry issue. CRITICAL: parameter name is 'linkedAssetId' — do NOT use 'issueId', 'defectId', 'id', or other variants. Accepts a string or number. To get this ID, call the Fetch Defects or Issues tool and use data[].id from the response.

  • start (number): Start index for pagination - defaults to 0 (default: 0)

  • page (number): Page number to return (starts from 1) (default: 1)

  • limit (number): Number of records (default 10). (default: 10)

  • platformID (string): Platform ID to filter executions by environment/platform

  • filter (string): JSON filter string. Supported fields: tcName (string), linkageLevel (string), executedVersion (string), runStatusName (list of status names), platformID (list of numeric IDs), executionCreatedByLoginAlias (list of usernames), isTestSuiteArchived (list: [1] active, [0] archived, [1,0] both). Example: '[{"type":"string","value":"login","field":"tcName"}]' (default: "[]")

Output Description: JSON object with 'data' array of execution records, 'hasTcRunUdf' boolean flag, and 'total' count. Each execution record ALWAYS contains these mandatory identification fields: 'tsEntityKey' (Test Suite Key, e.g. 'MAC-TS-42'), 'tsName' (Test Suite Name), 'releaseName' (Release), 'cycleName' (Cycle), 'platformName' (Platform/environment), 'executedVersion' (Executed Version of the test case), 'runStatusName' (Execution Status label), 'tcRunID' (numeric Test Run ID), 'tcName' (Test Case Name), 'tcEntityKey' (Test Case Key), and 'testRunUdfs' (array of objects each with name, label, fieldID, fieldType, value — use 'label' for display headers, null if not set). ALL project-defined UDF fields are always included, even those with no value. When hasTcRunUdf is false, a 'testRunUdfNote' field provides a professional explanation instead.

Use Cases: 1. Get all test executions linked to a specific defect 2. Audit which test cases were run against a given issue 3. Filter executions by run status (failed, passed, etc.) for an issue 4. Filter executions by platform/environment for an issue 5. Filter executions by tester/executor for an issue 6. Show archived and active test suite executions for an issue 7. View UDF (custom field) values on executions linked to an issue 8. Track test coverage and execution progress for a defect

Examples:

  1. Get all executions linked to issue ID 9598240

{
  "linkedAssetId": 9598240
}

Expected Output: Present as ONE unified table — never as a separate type+value UDF breakdown. Example: | Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | Tested By | Environments UDF | Execution Type | | MAC-TS-42 | Regression Suite | R1 | Sprint1 | Chrome | 1 | Failed | varis | chrome, edge, safari | Functional | | MAC-TS-43 | Login Suite | R1 | Sprint1 | Firefox | 2 | Blocked | john | firefox | Regression | Columns in order: Test Suite Key (tsEntityKey) | Test Suite Name (tsName) | Release (releaseName) | Cycle (cycleName) | Platform (platformName) | Executed Version (executedVersion) | Execution Status (runStatusName) | then one column per UDF label. Use the UDF 'label' as column header. Show null UDF values as '-'.

  1. Get executions with pagination (page 1, 20 records)

{
  "linkedAssetId": 9598240,
  "page": 1,
  "start": 0,
  "limit": 20
}

Expected Output: First 20 executions linked to the issue

  1. Filter executions by run status (failed or passed)

{
  "linkedAssetId": 9509016,
  "filter": "[{\"type\":\"list\",\"field\":\"runStatusName\",\"value\":[\"failed\",\"passed\"]}]",
  "page": 1,
  "start": 0,
  "limit": 20
}

Expected Output: Executions with failed or passed status for the issue

  1. Filter executions by test case name

{
  "linkedAssetId": 9509016,
  "filter": "[{\"type\":\"string\",\"value\":\"login\",\"field\":\"tcName\"}]",
  "page": 1,
  "start": 0,
  "limit": 20
}

Expected Output: Executions where test case name contains 'login'

  1. Filter by platform, status, and tester

{
  "linkedAssetId": 9509016,
  "filter": "[{\"type\":\"list\",\"field\":\"runStatusName\",\"value\":[\"failed\"]},{\"type\":\"list\",\"field\":\"platformID\",\"value\":[100145]},{\"type\":\"list\",\"field\":\"executionCreatedByLoginAlias\",\"value\":[\"Varis Khan\"]}]",
  "page": 1,
  "start": 0,
  "limit": 20
}

Expected Output: Failed executions on platform 100145 created by Varis Khan

  1. Filter by status and include archived test suite executions

{
  "linkedAssetId": 9509016,
  "filter": "[{\"type\":\"list\",\"field\":\"runStatusName\",\"value\":[\"failed\",\"passed\"]},{\"value\":[1,0],\"type\":\"list\",\"field\":\"isTestSuiteArchived\"}]",
  "page": 1,
  "start": 0,
  "limit": 20
}

Expected Output: Executions with failed/passed status including archived test suites

  1. Filter by execution version and linkage level

{
  "linkedAssetId": 9509016,
  "filter": "[{\"type\":\"string\",\"value\":\"1\",\"field\":\"executedVersion\"},{\"type\":\"string\",\"value\":\"Test Case\",\"field\":\"linkageLevel\"}]",
  "page": 1,
  "start": 0,
  "limit": 20
}

Expected Output: Executions at Test Case linkage level for version 1

Hints: 1. === MANDATORY RESPONSE FORMAT — READ THIS BEFORE RENDERING ANY OUTPUT === 2. 3. PIVOT RULE — CRITICAL: 4. The 'testRunUdfs' field on each execution is an array of { name, label, fieldID, fieldType, value }. 5. You MUST pivot this array into TABLE COLUMNS — do NOT render it as rows. 6. → Each testRunUdfs[i].label = a column header in the unified table 7. → Each testRunUdfs[i].value = the cell value for that execution's row 8. → testRunUdfs[i].fieldType = INTERNAL METADATA — NEVER show this as a column 9. → testRunUdfs[i].fieldID = INTERNAL METADATA — NEVER show this as a column 10. 11. FORBIDDEN PATTERNS — NEVER do any of these: 12. ❌ Do NOT render a separate sub-table (UDF Label | Type | Value) per execution 13. ❌ Do NOT show 'Type' or 'fieldType' as a visible column 14. ❌ Do NOT group output by tcRunID with individual breakdowns beneath each 15. ❌ Do NOT show raw UDF field keys (e.g. 'TRString', '8260LUP') as headers — use 'label' 16. 17. REQUIRED OUTPUT — ONE unified table, all executions as rows: 18. | Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label 1> | <UDF Label 2> | ... | 19. |----------------|-----------------|---------|-------|----------|------------------|------------------|---------------|---------------|-----| 20. | MAC-TS-42 | Login Suite | R1 | S1 | Chrome | v1 | Failed | varis | chrome, edge | ... | 21. 22. MANDATORY COLUMNS (always first, in this order): 23. 1. Test Suite Key → tsEntityKey (e.g. 'MAC-TS-42') 24. 2. Test Suite Name → tsName (test suite display name) 25. 3. Release → releaseName 26. 4. Cycle → cycleName 27. 5. Platform → platformName 28. 6. Executed Version → executedVersion 29. 7. Execution Status → runStatusName 30. 8. Tested By → executionCreatedByLoginAlias/testedBy when present 31. 9+. One column per UDF field — use testRunUdfs[i].label as header, testRunUdfs[i].value as cell. 32. 33. Null UDF values → show as '-'. If hasTcRunUdf is false, show columns 1-8 only. 34. ISSUE EXECUTION UDF SOURCE — CRITICAL: 35. Do NOT call 'Fetch Test Run UDF Values' for issue execution UDFs. 36. Do NOT create or use another issue-specific UDF fetch tool. 37. Use this tool's response directly: it calls /rest/execution/getExecutionsForIssue for execution rows, parses each row's udfjson for saved UDF values, and uses Test Run UDF metadata to include all configured UDF labels with null/empty values. 38. === END MANDATORY RESPONSE FORMAT === 39. 40. CRITICAL: linkedAssetId is REQUIRED - this is the numeric defect ID from QMetry (not entity key like VKT-IS-5) 41. HOW TO GET linkedAssetId: Call Fetch Defects or Issues tool → use data[].id from the response 42. AUTO-RESOLVE: If user provides an issue entity key (e.g. VKT-IS-5, MAC-IS-10), first call Fetch Defects or Issues with that entity key as filter, extract data[].id, then use it as linkedAssetId 43. AUTO-RESOLVE FILTER EXAMPLE: to resolve VKT-IS-5 → use filter '[{"type":"string","value":"VKT-IS-5","field":"entityKeyId"}]' in Fetch Defects or Issues tool 44. This tool supports QMetry-native issues only — do NOT use for Jira-integrated projects 45. API SOURCE: Execution rows and saved UDF values come from /rest/execution/getExecutionsForIssue. The udfjson field contains saved Test Run UDF values, e.g. Tested_By, execution_type, Country_mcp_udf, environments_udf. 46. METADATA SOURCE: This tool also calls Test Run UDF metadata once to get all available labels, fieldIDs, field types, and empty fields. Merge metadata fields with udfjson values by UDF name. 47. RESPONSE FIELDS: hasTcRunUdf=true means executions have UDF data; each execution includes a 'testRunUdfs' array with ALL project-defined UDF fields 48. ALL UDF FIELDS: ALL project-defined Test Run UDF fields are returned for every execution — including fields not yet set (value: null) 49. Each element in testRunUdfs: { name, label, fieldID, fieldType, value } — use fieldID when calling 'Bulk Update Test Run UDFs' 50. EXAMPLE testRunUdfs: [{ "name": "TRString", "label": "TR String", "fieldID": 229241, "fieldType": "STRING", "value": "test" }, { "name": "dateField", "label": "Date", "fieldID": 229255, "fieldType": "DATETIMEPICKER", "value": null }] 51. FILTER FIELDS: 52. - tcName (string): filter by test case name substring 53. - linkageLevel (string): 'Test Case' or 'Test Step' 54. - executedVersion (string): version number as string e.g. '1' 55. - runStatusName (list): e.g. ["failed","passed","in progress"] 56. - platformID (list): numeric platform IDs e.g. [100145]. Get from FETCH_PLATFORMS tool 57. - executionCreatedByLoginAlias (list): usernames/login aliases e.g. ["john.doe"] 58. - isTestSuiteArchived (list): [1] active only, [0] archived only, [1,0] both 59. FILTER FORMAT: JSON string array — '[{"type":"list","field":"runStatusName","value":["failed"]}]' 60. Multiple filter conditions are combined with AND logic 61. Use pagination (page, start, limit) for large result sets 62. Get platform IDs using the FETCH_PLATFORMS tool before filtering by platformID 63. Execution status names are case-sensitive — use lowercase: 'failed', 'passed', 'in progress', 'blocked', 'not run' 64. hasTcRunUdf: false → No Test Run UDFs configured; testRunUdfs will not appear; a 'testRunUdfNote' field explains this.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoJSON filter string. Supported fields: tcName (string), linkageLevel (string), executedVersion (string), runStatusName (list of status names), platformID (list of numeric IDs), executionCreatedByLoginAlias (list of usernames), isTestSuiteArchived (list: [1] active, [0] archived, [1,0] both). Example: '[{"type":"string","value":"login","field":"tcName"}]'[]
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
platformIDNoPlatform ID to filter executions by environment/platform
projectKeyNoProject key - unique identifier for the projectdefault
linkedAssetIdYesNumeric defect ID of the QMetry issue. CRITICAL: parameter name is 'linkedAssetId' — do NOT use 'issueId', 'defectId', 'id', or other variants. Accepts a string or number. To get this ID, call the Fetch Defects or Issues tool and use data[<index>].id from the response.
Behavior5/5

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

The description extensively details behavioral traits not fully captured by annotations, including response format (pivot UDF arrays into columns), mandatory columns, UDF handling, pagination, filter capabilities, and source API endpoints. It does not contradict any annotation (readOnlyHint, idempotentHint, destructiveHint are all consistent).

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 very long (60+ lines) and contains repeated instructions (e.g., formatting rules stated multiple times in different sections). While well-organized with headers and examples, it could be trimmed to deliver the same value more succinctly. The first sentence effectively conveys purpose, but subsequent sections are verbose.

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?

The description thoroughly covers output format, filter options, UDF handling, pagination, and provides multiple examples. It also explains the API source and prerequisites. However, it lacks explicit error handling or rate limit information, which would be beneficial for a tool with many parameters and complex usage.

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

Parameters5/5

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

The description adds significant meaning beyond the schema by explaining how to obtain linkedAssetId via another tool, giving exact filter syntax with examples, warning against incorrect parameter names, and describing the default behavior for each parameter. With 100% schema coverage, it still enhances understanding.

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 opens with a clear verb and resource: 'Get test case executions linked to a QMetry-native (non-Jira) defect/issue.' It specifies the scope (QMetry-native, not Jira) and distinguishes from siblings like qmetry_fetch_test_case_executions which focuses on test case runs rather than issue-linked executions.

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 description explicitly states when not to use the tool ('do NOT use for Jira-integrated projects'), provides prerequisites (calling Fetch Defects or Issues to get linkedAssetId), and includes use cases. However, it does not explicitly contrast with similar QMetry tools like qmetry_fetch_test_case_executions, leaving some ambiguity about when to choose one over the other.

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