qmetry_fetch_test_case_runs_by_test_suite_run

// WHEN AI AGENTS USE THIS TOOL

AI agents call qmetry_fetch_test_case_runs_by_test_suite_run to retrieve information from SmartBear MCP without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.

// WHY ENFORCE A POLICY ON QMETRY_FETCH_TEST_CASE_RUNS_BY_TEST_SUITE_RUN

Even though qmetry_fetch_test_case_runs_by_test_suite_run only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.

// RECOMMENDED POLICY

Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.

smartbear-mcp.yaml

tools:
  qmetry_fetch_test_case_runs_by_test_suite_run:
    rules:
      - action: allow

See the full SmartBear MCP policy for all 147 tools.

// DETAILS

Tool Name qmetry_fetch_test_case_runs_by_test_suite_run

Category Read

MCP Server SmartBear MCP MCP Server

Risk Level Low

// MORE SMARTBEAR MCP TOOLS

Destructive collaborator_delete_collaborator_remote_system_configuration Destructive reflect_cancel_suite_execution Destructive reflect_delete_previous_step Destructive swagger_delete_portal_product Destructive swagger_delete_table_of_contents Execute collaborator_reviewservice_action Execute contract-testing_can_i_deploy Execute qmetry_link_issues_to_testcase_run

View all 147 tools →

// RELATED READING

// FAQ

What does the qmetry_fetch_test_case_runs_by_test_suite_run tool do? +

Get test case runs under a specific test suite run execution in QMetry **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) (default: "https://testmanagement.qmetry.com") - tsrunID (string) *required*: Test Suite Run ID (required for fetching test case runs). This is the string identifier for the test suite run execution. NOTE: To get the tsrunID - Call API 'Execution/Fetch Executions' From the response, get value of following attribute -> data[<index>].tsRunID - viewId (any) *required* - 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) **Output Description:** JSON object with test case runs array containing detailed execution information, status, tester details, and run metadata **Use Cases:** 1. Get all test case runs under a specific test suite run execution 2. Analyze individual test case execution results and status 3. Monitor test case run performance and execution trends 4. Generate detailed test execution reports for specific runs 5. Track test case run history and execution patterns 6. Validate test case run coverage and execution completeness 7. Audit test case run data for compliance and quality assurance 8. Export detailed test case run data for external reporting 9. Retrieve paginated test case run results for large test suite executions **Examples:** 1. Get all test case runs for test suite run ID '107021' ```json { "tsrunID": "107021", "viewId": 6887 } ``` Expected Output: List of test case runs with execution details, status, and metadata 2. Get test case runs with linked defects ```json { "tsrunID": "107021", "viewId": 6887, "page": 1, "limit": 25 } ``` Expected Output: Paginated list of test case runs with 25 items per page 3. Get test case runs for test suite run ID '2362144' ```json { "tsrunID": "2362144", "viewId": 104123, "start": 0, "page": 1, "limit": 25 } ``` Expected Output: Test case runs from the specified test suite run execution **Hints:** 1. CRITICAL WORKFLOW FOR FETCHING ALL EXECUTIONS OF A TEST SUITE: 2. When user asks to: 3. - 'fetch all executions' 4. - 'get all test runs' 5. - 'fetch all tcRunIDs for test suite X' 6. - 'update status for all executions of test suite X' 7. STEP 1: First call FETCH_EXECUTIONS_BY_TESTSUITE tool with the test suite ID (tsID, not entityKey) 8. - This returns ALL execution records for that test suite (could be 3, 5, 9, or any number) 9. - Extract ALL tsRunID values from the response data array 10. - Example response: data: [{tsRunID: '2739237', ...}, {tsRunID: '2739236', ...}, {tsRunID: '2739235', ...}] 11. STEP 2: For EACH tsRunID from Step 1, call this tool (FETCH_TEST_CASE_RUNS_BY_TESTSUITE_RUN) 12. - This returns all test case runs (tcRunID values) for that specific execution 13. - Repeat for ALL tsRunID values discovered in Step 1 14. STEP 3: Collect all tcRunID values from all executions 15. - Now you have the complete list of test case runs across ALL executions 16. - Use these for bulk status updates or other operations 17. CRITICAL ERROR TO AVOID: 18. - NEVER assume or hard-code only 2-3 execution IDs 19. - NEVER skip Step 1 - always discover ALL executions first 20. - NEVER fetch tcRunIDs for only some executions - get ALL of them 21. - If there are 9 executions, you must fetch tcRunIDs for all 9, not just 2 22. EXAMPLE WORKFLOW: 23. User: 'Fetch all test case runs for test suite VKMCP-TS-21' 24. Step 1: Call FETCH_EXECUTIONS_BY_TESTSUITE with tsID (resolved from VKMCP-TS-21) 25. Result: Found 9 executions with tsRunIDs: 2739237, 2739236, 2739235, 2739234, 2739233, 2739232, 2739231, 2739230, 2739229 26. Step 2: Call this tool 9 times (once for each tsRunID) 27. Call 1: tsrunID='2739237' -> returns 54 tcRunIDs 28. Call 2: tsrunID='2739236' -> returns 54 tcRunIDs 29. ... (repeat for all 9) 30. Step 3: Total collected: 9 executions × 54 test cases = 486 total tcRunIDs 31. 32. PERFORMANCE CONSIDERATIONS FOR LARGE TEST RUNS: 33. When dealing with large numbers of test case runs (500+, 1000+), follow these guidelines: 34. 1. ALWAYS inform the user about the scale BEFORE starting operations: 35. Example: 'Found 9 executions with approximately 486 test case runs. This will require fetching data from all 9 executions and may take a moment.' 36. 2. For bulk status updates on 1000+ test case runs: 37. - NEVER attempt to update all 1000+ in a single operation 38. - Break into smaller batches of 10-20 test case runs per update 39. - Inform user: 'Found 1000 test case runs. Will process in batches of 20 to ensure reliability and performance.' 40. - Show progress: 'Processing batch 1/50 (20 test runs)...', 'Batch 2/50...' 41. 3. Recommended batch sizes: 42. - For status updates: 10-20 test case runs per batch 43. - For fetching data: Can handle larger batches (50-100) 44. - Adjust based on API response times and timeout limits 45. 4. Always provide progress updates for long-running operations: 46. - Before: 'Processing 1000 test runs in 50 batches of 20...' 47. - During: 'Completed 200/1000 test runs (10 batches)...' 48. - After: 'Successfully updated all 1000 test case runs.' 49. 5. Error handling for batch operations: 50. - If a batch fails, report which batch and continue with remaining 51. - Provide summary at the end: 'Completed 48/50 batches. 2 batches failed (batch 23, 45).' 52. - Allow user to retry failed batches specifically 53. EXAMPLE LARGE-SCALE WORKFLOW: 54. User: 'Update status to Failed for all test runs in VKMCP-TS-21' 55. Step 1: Discover all executions (9 found) 56. Step 2: Fetch all tcRunIDs (486 total) 57. Step 3: Inform user: 'Found 486 test case runs across 9 executions. Will update in 25 batches of 20 runs each.' 58. Step 4: Process in batches with progress updates 59. Step 5: Report completion: 'Successfully updated all 486 test case runs to Failed status.' 60. 61. CRITICAL: tsrunID and viewId parameters are REQUIRED 62. tsrunID is a STRING identifier for the test suite run execution 63. viewId is a NUMERIC identifier for the test execution view 64. !MOST IMPORTANT HOW TO GET tsrunID: 65. 1. Call API 'Execution/Fetch Executions' (FETCH_EXECUTIONS_BY_TESTSUITE) to get ALL available executions 66. 2. From the response, get value of following attribute -> data[<index>].tsRunID for EVERY execution 67. 3. Example: Test Suite might have multiple executions with IDs '107021', '107022', '107023', etc. 68. 4. NEVER assume there are only 2-3 executions - always fetch to discover the actual count 69. !MOST IMPORTANT HOW TO GET viewId: 70. CRITICAL: Always resolve and use the correct test execution viewId for the current project when calling this tool. 71. The viewId parameter must be fetched from the active project's info (latestViews.TE.viewId). 72. Each QMetry project may have a different test execution viewId, so using a stale or incorrect viewId will result in incomplete or invalid test case run data. 73. Usage workflow: 74. 1. Fetch project info for the current project (Admin/Get info Service). 75. 2. Extract latestViews.TE.viewId from the response. 76. 3. Use this viewId in the Fetch Test Case Runs by Test Suite Run API call. 77. Example: 78. { 79. tsrunID: "2362144", 80. viewId: 104123, 81. start: 0, 82. page: 1, 83. limit: 25 84. } 85. This ensures the tool fetches the proper execution runs data for the selected project context. 86. SIMPLIFIED PAYLOAD: API only accepts essential parameters 87. SUPPORTED PARAMETERS: start, page, limit, tsrunID, viewId 88. REMOVED PARAMETERS: filter, sort, showTcWithDefects, udfFilter (cause API errors) 89. PAGINATION: Use start, page, and limit for result pagination 90. API REQUIREMENT: Must use exact payload structure that works in Postman 91. PAYLOAD FORMAT: {"start": 0, "page": 1, "limit": 10, "tsrunID": "2362144", "viewId": 104123} 92. Use pagination for large result sets (start, page, limit parameters) 93. This tool is essential for detailed test execution analysis and reporting 94. Critical for monitoring individual test case execution performance 95. Use for compliance reporting and execution audit trails 96. Essential for test execution quality assurance and trend analysis. It is categorised as a Read tool in the SmartBear MCP MCP Server, which means it retrieves data without modifying state.

How do I enforce a policy on qmetry_fetch_test_case_runs_by_test_suite_run? +

Add a rule in your Intercept YAML policy under the tools section for qmetry_fetch_test_case_runs_by_test_suite_run. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the SmartBear MCP MCP server.

What risk level is qmetry_fetch_test_case_runs_by_test_suite_run? +

qmetry_fetch_test_case_runs_by_test_suite_run is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Can I rate-limit qmetry_fetch_test_case_runs_by_test_suite_run? +

Yes. Add a rate_limit block to the qmetry_fetch_test_case_runs_by_test_suite_run rule in your Intercept policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block qmetry_fetch_test_case_runs_by_test_suite_run completely? +

Set action: deny in the Intercept policy for qmetry_fetch_test_case_runs_by_test_suite_run. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides qmetry_fetch_test_case_runs_by_test_suite_run? +

qmetry_fetch_test_case_runs_by_test_suite_run is provided by the SmartBear MCP MCP server (@smartbear/mcp). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.

qmetry_fetch_test_case_runs_by_test_suite_run

Enforce policies on SmartBear MCP