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 or not linked to a specific test case run in QMetry for defect tracking, gap analysis, and traceability.

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

  • baseUrl (string): The base URL for the QMetry instance (must be a valid URL)

  • 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 '[]')[]
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
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
Behavior5/5

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

Annotations already indicate readonly and idempotent behavior. The description adds behavioral details: it fetches linked or unlinked issues, explains pagination, filtering capabilities, and output structure (JSON with issues array). No contradictions.

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 excessively long with many use cases, examples, and hints. While structured, it is not concise; the core purpose could be conveyed in fewer words. The length may overwhelm the agent.

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?

Despite lacking an output schema, the description thoroughly explains the output format, includes 6 examples covering different scenarios, details parameter usage, and provides comprehensive workflow hints. It covers all necessary aspects for an agent to use the tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the description adds minimal new semantics beyond what is already in the schema. It repeats parameter descriptions and adds examples, but does not clarify nuances like the format of filter strings beyond what is shown.

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 clearly states the tool gets issues linked or not linked to a test case run in QMetry. The title reinforces this. It distinguishes the tool from siblings like qmetry_fetch_issues_linked_to_test_case by focusing on test case runs.

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 provides extensive workflow guidance, including steps to obtain the correct entity ID, ID hierarchy, and when to use the tool for defect tracking or gap analysis. However, it does not explicitly compare to alternatives or state when not to use this tool, which would elevate clarity.

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