Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Linked Issues of Test Case Run

qmetry_fetch_linked_issues_of_test_case_run
Read-onlyIdempotent

Fetch issues linked to a QMetry test case run for defect tracking and gap analysis. Filter by type, status, or priority to trace test failures and build traceability reports.

Instructions

Get issues that are linked (or not linked) to a specific test case run in QMetry

Toolset: Issues

Parameters:

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

  • entityId (number) required: Id of Test case run (required for fetching linked issues). CRITICAL: the parameter name is 'entityId' — do NOT use 'tcRunId', 'testCaseRunId', 'runId', or other variants. Accepts a string or number. NOTE: To get the entityId - Call API 'Execution/Fetch Testcase Run ID' From the response, get value of following attribute -> data[].tcRunID

  • getLinked (boolean): True to get only those issues that are linked with this Test case Run, False to get those issues which are not linked with this Test case Run. Default value true (get linked issues). (default: true)

  • getColumns (boolean): Whether to get column information in response. (default: true)

  • istcrFlag (boolean): Set True for test case run operations (default: true)

  • 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 issues array containing issue details, priorities, status, owner information, and linkage metadata

Use Cases: 1. Get all issues linked to a specific test case run for defect tracking 2. Find issues that are NOT linked to a test case run (gap analysis) 3. Generate defect reports and traceability matrix for test case runs 4. Monitor issue resolution progress for specific test case executions 5. Analyze test execution quality by examining linked defects 6. Filter issues by type, priority, status, or owner for test case runs 7. Audit issue-test case run relationships for compliance 8. Track defect lifecycle in relation to test execution results 9. Quality assurance - ensure proper issue tracking for failed test runs 10. Impact analysis - see which issues affect specific test executions

Examples:

  1. Get all issues linked to test case run ID 1121218

{
  "entityId": 1121218,
  "getColumns": true,
  "getLinked": true
}

Expected Output: List of issues linked to the test case run with issue details, status, and metadata

  1. Get issues NOT linked to test case run (gap analysis)

{
  "entityId": 1121218,
  "getColumns": true,
  "getLinked": false
}

Expected Output: List of issues that are NOT linked to test case run for gap analysis

  1. Filter linked issues by issue type and status

{
  "entityId": 1121218,
  "getColumns": true,
  "getLinked": true,
  "filter": "[{\"type\":\"list\",\"value\":[1],\"field\":\"typeAlias\"},{\"type\":\"list\",\"value\":[1,2],\"field\":\"stateAlias\"}]"
}

Expected Output: Bug type issues in Open or In Progress status

  1. Search linked issues by name and priority

{
  "entityId": 1121218,
  "getColumns": true,
  "getLinked": true,
  "filter": "[{\"type\":\"string\",\"value\":\"login\",\"field\":\"name\"},{\"type\":\"list\",\"value\":[1],\"field\":\"priorityAlias\"}]"
}

Expected Output: High priority issues containing 'login' in their name

  1. Filter issues by date range and entity key

{
  "entityId": 1121218,
  "getColumns": true,
  "getLinked": true,
  "filter": "[{\"value\":\"2024-01-01\",\"type\":\"date\",\"field\":\"createdDate\",\"comparison\":\"gt\"},{\"value\":\"2024-12-31\",\"type\":\"date\",\"field\":\"createdDate\",\"comparison\":\"lt\"},{\"type\":\"string\",\"value\":\"BUG-001,BUG-002\",\"field\":\"entityKeyId\"}]"
}

Expected Output: Specific issues created within date range

  1. Filter issues by owner and created system

{
  "entityId": 1121218,
  "getColumns": true,
  "getLinked": true,
  "filter": "[{\"type\":\"list\",\"value\":[123],\"field\":\"dfOwner\"},{\"type\":\"list\",\"value\":[\"QMetry\"],\"field\":\"createdSystem\"}]"
}

Expected Output: Issues owned by specific user and created in QMetry

Hints: 1. WORKFLOW CRITICAL: NEVER use user-provided IDs directly as entityId! 2. ALWAYS fetch execution data first to get proper tcRunID values! 3. 4. WHEN USER ASKS: 'fetch linked issues of test suite [ID]' OR 'linked issues of test run [ID]': 5. STEP 1: Identify what type of ID the user provided 6. STEP 2A: If Test Suite ID → fetch executions by test suite → get tsRunID → fetch test runs → get tcRunID 7. STEP 2B: If Test Run ID → fetch test case runs by test suite run → get tcRunID 8. STEP 2C: If Test Case ID → fetch test case executions → get tcRunID 9. STEP 3: Use tcRunID as entityId for this tool 10. 11. ID HIERARCHY: Test Suite → Test Suite Runs → Test Case Runs (tcRunID = entityId) 12. ID HIERARCHY: Test Case → Test Case Executions (tcRunID = entityId) 13. 14. CRITICAL: entityId parameter is REQUIRED - this is the Test Case Run numeric ID (tcRunID) 15. HOW TO GET entityId: 16. 1. Call appropriate execution APIs to get test case runs 17. 2. From the response, extract data[].tcRunID 18. 3. Use tcRunID as entityId for this tool 19. 4. Example: tcRunID 1121218 becomes entityId: 1121218 20. 21. getLinked=true (default): Returns issues that ARE linked to the test case run 22. getLinked=false: Returns issues that are NOT linked to the test case run (useful for gap analysis) 23. istcrFlag=true (default): Set to true for test case run operations 24. getColumns=true (default): Include column metadata in response 25. 26. FILTER CAPABILITIES: Support extensive filtering by issue properties 27. FILTER FIELDS: name (string), typeAlias (list), stateAlias (list), entityKeyId (string), createdDate (date with comparison), createdByAlias (list), updatedDate (date with comparison), createdSystem (list), updatedByAlias (list), dfOwner (list), priorityAlias (list), linkedTcrCount (numeric), linkedRqCount (numeric), attachmentCount (numeric), componentAlias (list), environmentText (string), affectedRelease (list) 28. ISSUE TYPE IDs: Typically 1=Bug, 2=Enhancement, 3=Task (verify with your QMetry instance) 29. ISSUE STATE IDs: Typically 1=Open, 2=In Progress, 3=Resolved, 4=Closed (verify with your QMetry instance) 30. ISSUE PRIORITY IDs: Typically 1=High, 2=Medium, 3=Low (verify with your QMetry instance) 31. DATE FILTERING: Use 'gt' (greater than) and 'lt' (less than) comparisons for date fields 32. ENTITY KEY SEARCH: Use comma-separated values for multiple issue keys 33. CREATED SYSTEM: Use 'QMetry' or 'JIRA' to filter by creation system 34. OWNER IDs: Use numeric user IDs from QMetry user management 35. COMPONENT/LABEL IDs: Use numeric IDs for component/label filtering 36. ENVIRONMENT TEXT: Filter by environment description text 37. AFFECTED RELEASE: Use release IDs for filtering by affected releases 38. LINKED COUNT FILTERS: Use numeric values for linkedTcrCount, linkedRqCount, attachmentCount 39. Multiple filter conditions are combined with AND logic 40. Use pagination for large result sets (start, page, limit parameters) 41. This tool is essential for defect tracking and traceability audits 42. Critical for understanding test execution quality and issue relationships 43. Use for compliance reporting and issue lifecycle management 44. Helps establish relationships between test failures and reported issues 45. Essential for impact analysis when test case runs change or fail

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
entityIdYesId of Test case run (required for fetching linked issues). CRITICAL: the parameter name is 'entityId' — do NOT use 'tcRunId', 'testCaseRunId', 'runId', or other variants. Accepts a string or number. NOTE: To get the entityId - Call API 'Execution/Fetch Testcase Run ID' From the response, get value of following attribute -> data[<index>].tcRunID
getLinkedNoTrue to get only those issues that are linked with this Test case Run, False to get those issues which are not linked with this Test case Run. Default value true (get linked issues).
istcrFlagNoSet True for test case run operations
getColumnsNoWhether to get column information in response.
projectKeyNoProject key - unique identifier for the projectdefault
Install Server

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict these. It adds valuable behavioral detail: getLinked toggles linked vs. unlinked issues, entityId must be sourced from a prior execution API response, filter conditions are ANDed, and the response is an issues array. It does not discuss error cases or how getColumns affects the response shape.

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 highly repetitive and overlong for a simple read-only fetch tool. The first sentence is clear and front-loaded, but the use-case list is largely filler, and the Hints section repeats the same entityId workflow and filter guidance multiple times.

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 a 9-parameter tool with no output schema, this description is exceptionally complete: it documents output as a JSON object with issues, all parameters through the schema plus examples, pagination, filter fields, default behaviors, and the critical ID-provenance workflow. An agent has enough context to call this tool correctly.

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?

Schema coverage is 100%, so a baseline of 3 applies, but the description substantially exceeds that baseline. It explains how to obtain entityId from data[<index>].tcRunID, documents getLinked semantics, enumerates filterable fields and comparison operators, and provides six worked JSON examples with valid filter syntax. The only minor wrinkle is saying entityId accepts a string or number while the schema types it as number.

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 specific verb and resource: 'Get issues that are linked (or not linked) to a specific test case run in QMetry.' This clearly distinguishes the tool's scope from nearby QMetry tools that fetch issues for test cases, requirements, or suites.

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 gives strong usage context: getLinked=true versus false for gap analysis, extensive use cases, and critical workflow prerequisites such as 'NEVER use user-provided IDs directly as entityId' and 'ALWAYS fetch execution data first.' It does not explicitly name alternative sibling tools or say when not to use this tool over them, so it stops short of a 5.

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