Skip to main content
Glama
SmartBear MCP server

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Executions by Test Suite

qmetry_fetch_executions_by_test_suite
Read-onlyIdempotent

Fetch QMetry test executions for a specific test suite, with filters for release, cycle, platform, and automation status plus pagination for reporting and analysis.

Instructions

Get executions for a given test suite in QMetry

Toolset: Test Suites

Parameters:

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

  • tsID (number) required: Test Suite numeric ID. CRITICAL: the parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', 'suiteId', or other variants. Accepts a string or number. NOTE: To get the tsID - Call API 'Testsuite/Fetch Testsuite' From the response, get value of following attribute -> data[].id

  • tsFolderID (number): Test Suite folder ID. CRITICAL: the parameter name is 'tsFolderID' — do NOT use 'testSuiteFolderId', 'folderId', 'folderID', or other variants. Accepts a string or number. Get from project info response → rootFolders.TS.id. Use FETCH_PROJECT_INFO tool first if not provided by user.

  • gridName (string): Grid Name to be displayed (default 'TESTEXECUTIONLIST')

  • viewId (number): ViewId for test execution - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TE.viewId automatically.

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

  • filter (string): Filter criteria as JSON string (default '[]') (default: "[]")

Output Description: JSON object with executions array containing execution details, status, platforms, releases, and execution metadata. Each execution entry may include 'linkedDfCount' (defects linked to the test execution) and 'linkedStepDfCount' (defects linked to the test step executions) - report both when linked defects are asked about.

Use Cases: 1. Get all executions for a specific test suite for reporting purposes 2. Analyze test execution results and trends within a test suite 3. Filter executions by release, cycle, platform, or automation status 4. Monitor test suite execution performance across different environments 5. Generate execution reports for specific test suites 6. Track execution history and patterns for test suite optimization 7. Validate test suite execution coverage across releases and cycles 8. Audit test execution data for compliance and quality assurance 9. Export execution data for external reporting and analytics

Examples:

  1. Get all executions for test suite ID 194955

{
  "tsID": 194955
}

Expected Output: List of executions for the test suite with execution details, status, and metadata

  1. Get executions with test suite folder and view ID

{
  "tsID": 194955,
  "tsFolderID": 126554,
  "viewId": 41799
}

Expected Output: Executions filtered by test suite folder and specific view configuration

  1. Filter executions by release and cycle

{
  "tsID": 194955,
  "filter": "[{\"type\":\"list\",\"value\":[55178],\"field\":\"releaseID\"},{\"type\":\"list\",\"value\":[111577],\"field\":\"cycleID\"}]"
}

Expected Output: Executions filtered by specific release (55178) and cycle (111577)

  1. Filter executions by platform and automation status

{
  "tsID": 194955,
  "filter": "[{\"type\":\"list\",\"value\":[12345],\"field\":\"platformID\"},{\"type\":\"boolean\",\"value\":true,\"field\":\"isAutomatedFlag\"}]"
}

Expected Output: Automated executions filtered by specific platform (12345)

  1. Get only active (non-archived) executions

{
  "tsID": 194955,
  "filter": "[{\"value\":[0],\"type\":\"list\",\"field\":\"isArchived\"}]"
}

Expected Output: Active executions that are not archived

  1. Get executions with custom pagination and grid name

{
  "tsID": 194955,
  "gridName": "TESTEXECUTIONLIST",
  "page": 1,
  "limit": 25
}

Expected Output: Paginated list of executions with 25 items per page using specific grid configuration

Hints: 1. !MOST IMPORTANT HOW TO GET viewId: 2. CRITICAL: Always resolve and use the correct test execution viewId for the current project when calling this tool. 3. The viewId parameter must be fetched from the active project's info (latestViews.TEL.viewId). 4. Each QMetry project may have a different test execution list viewId, so using a stale or incorrect viewId will result in incomplete or invalid executions list data by test suite id. 5. Usage workflow: 6. 1. Fetch project info for the current project (Admin/Get info Service). 7. 2. Extract latestViews.TEL.viewId from the response. 8. 3. Use this viewId in the Fetch Test Case Runs by Test Suite Run API call. 9. Example: 10. { 11. tsID: 1533730, 12. viewId: 94194, 13. gridName: 'TESTEXECUTIONLIST' 14. } 15. CRITICAL: tsID parameter is REQUIRED - this is the Test Suite numeric ID 16. HOW TO GET tsID: 17. 1. Call API 'Testsuite/Fetch Testsuite' to get available test suites 18. 2. From the response, get value of following attribute -> data[].id 19. 3. Example: Test Suite 'Regression Suite' might have ID 194955 20. HOW TO GET tsFolderID (optional): 21. 1. Call API 'Testsuite/List of folders' to get test suite folders 22. 2. From the response, get value of following attribute -> data[].id 23. 3. Example: Test Suite folder might have ID 126554 24. FILTER CAPABILITIES: Extensive filtering by execution properties 25. FILTER FIELDS: releaseID (list), cycleID (list), platformID (list), isAutomatedFlag (boolean), isArchived (list) 26. RELEASE/CYCLE FILTERING: Use numeric IDs in list format (get from FETCH_RELEASES_AND_CYCLES) 27. PLATFORM FILTERING: Use numeric platform IDs (get from FETCH_PLATFORMS) 28. AUTOMATION STATUS: Use boolean true/false for isAutomatedFlag field 29. ARCHIVE STATUS: 0=Active executions, 1=Archived executions 30. GRID NAME: Default is 'TESTEXECUTIONLIST' - used for execution list display configuration 31. VIEW ID: Optional numeric identifier for specific execution view configurations 32. Multiple filter conditions are combined with AND logic 33. Use pagination for large execution result sets (start, page, limit parameters) 34. This tool is essential for test execution analysis and reporting 35. Critical for monitoring test suite performance and execution trends 36. Use for compliance reporting and execution audit trails 37. Essential for test execution planning and resource optimization 38. LINKED DEFECTS/ISSUES: Each execution record can expose TWO separate defect counts - 'linkedDfCount' is the count of defects/issues linked to the TEST EXECUTION itself, and 'linkedStepDfCount' is the count of defects/issues linked to that execution's TEST STEP executions. Whenever asked about linked defects/issues for an execution, report BOTH counts (linkedDfCount and linkedStepDfCount) - do not report only one.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
tsIDYesTest Suite numeric ID. CRITICAL: the parameter name is 'tsID' — do NOT use 'testSuiteId', 'testSuiteID', 'suiteId', or other variants. Accepts a string or number. NOTE: To get the tsID - Call API 'Testsuite/Fetch Testsuite' From the response, get value of following attribute -> data[<index>].id
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
viewIdNoViewId for test execution - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TE.viewId automatically.
gridNameNoGrid Name to be displayed (default 'TESTEXECUTIONLIST')
projectKeyNoProject key - unique identifier for the projectdefault
tsFolderIDNoTest Suite folder ID. CRITICAL: the parameter name is 'tsFolderID' — do NOT use 'testSuiteFolderId', 'folderId', 'folderID', or other variants. Accepts a string or number. Get from project info response → rootFolders.TS.id. Use FETCH_PROJECT_INFO tool first if not provided by user.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields 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"
      -}
    • changedInput schema / properties / viewId / description
      Previous value: -"ViewId for test execution - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TE.viewId automatically. Manual viewId only needed if you want to override the automatic resolution."New value: +"ViewId for test execution - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific viewId. System will fetch project info using the projectKey and extract latestViews.TE.viewId automatically."
  2. 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"
  3. First observedv0.27.1

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful behavior such as required tsID, filter AND-combination semantics, pagination, and linked defect counts, but it also contains conflicting viewId guidance—first saying the system auto-resolves it, then insisting it must be fetched from latestViews.TE or latestViews.TEL. That internal contradiction lowers confidence.

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

Conciseness2/5

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

The description is heavily overlong, with duplicated parameter descriptions, repeated use-case/hint content, many redundant examples, and contradictory viewId instructions. While the opening identifies the tool, the volume and duplication make it less usable than a tightly front-loaded definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter tool with no output schema, the description does provide output details, filter semantics, and acquisition guidance for required IDs. However, the conflicting viewId instructions and lack of sibling differentiation leave meaningful gaps for correct invocation.

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 would be 3. The description still adds meaningful semantics beyond the schema: filter field names and value types (releaseID, cycleID, platformID, isAutomatedFlag, isArchived), how to source related IDs, and concrete examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: get executions for a given test suite. It does not, however, distinguish this tool from closely related siblings such as qmetry_fetch_test_case_runs_by_test_suite_run or qmetry_fetch_test_case_executions, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Nine use cases are listed, implying this tool is for execution reporting, trend analysis, filtering, and audit scenarios. There is no explicit when-not guidance and no comparison to the very similar sibling tools, so selection between them remains ambiguous.

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