Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Issues Linked to Test Case

qmetry_fetch_issues_linked_to_test_case
Read-onlyIdempotent

Fetch issues linked or unlinked to a test case to track defects, perform gap analysis, and audit traceability.

Instructions

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

Toolset: Issues

Parameters:

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

  • tcID (number) required: Test Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters.

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

  • 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, and linkage information

Use Cases: 1. Get all issues linked to a specific test case for defect tracking 2. Find issues that are NOT linked to a test case (gap analysis) 3. Generate traceability reports between test cases and issues 4. Filter issues by type, priority, status, or owner 5. Monitor issue resolution progress for specific test cases 6. Audit issue-test case relationships for compliance 7. Filter issues by summary content or execution version 8. Get issue details for test execution planning 9. Track linkage level (Test Case vs Test Step level) 10. Quality assurance - ensure proper issue tracking

Examples:

  1. Get all issues linked to test case ID 4495658 (default behavior)

{
  "tcID": 4495658
}

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

  1. Get all issues linked to test case ID 4495658 (explicit)

{
  "tcID": 4495658,
  "getLinked": true
}

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

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

{
  "tcID": 4495658,
  "getLinked": false
}

Expected Output: List of issues that are NOT linked to the test case

  1. Get linked issues with pagination

{
  "tcID": 4495658,
  "getLinked": true,
  "limit": 25,
  "page": 1
}

Expected Output: Paginated list of issues linked to the test case

  1. Filter linked issues by summary content (using default getLinked=true)

{
  "tcID": 4495658,
  "filter": "[{\"value\":\"login\",\"type\":\"string\",\"field\":\"summary\"}]"
}

Expected Output: Issues linked to test case that contain 'login' in their summary

  1. Filter linked issues by status and priority

{
  "tcID": 4495658,
  "getLinked": true,
  "filter": "[{\"value\":[1,2],\"type\":\"list\",\"field\":\"issueState\"},{\"value\":[1],\"type\":\"list\",\"field\":\"issuePriority\"}]"
}

Expected Output: High priority issues in Open or In Progress status

  1. Filter issues by execution version

{
  "tcID": 4495658,
  "getLinked": true,
  "filter": "[{\"value\":\"2\",\"type\":\"string\",\"field\":\"executedVersion\"}]"
}

Expected Output: Issues linked to version 2 of the test case execution

Hints: 1. CRITICAL: tcID parameter is REQUIRED - this is the Test Case numeric ID 2. getLinked parameter is OPTIONAL - defaults to true if not provided 3. HOW TO GET tcID: 4. 1. Call FETCH_TEST_CASES with filter on entityKeyId to resolve test case key to numeric ID 5. 2. From response, use data[index].tcID field 6. 3. Example: MAC-TC-1684 → tcID: 4495658 7. getLinked=true (default): Returns issues that ARE linked to the test case 8. getLinked=false: Returns issues that are NOT linked to the test case (useful for gap analysis) 9. If getLinked is not specified, it defaults to true (linked issues) 10. FILTER CAPABILITIES: Extensive filtering by issue properties 11. FILTER FIELDS: summary (string), executedVersion (string), linkageLevel (string), issueType (list), issuePriority (list), issueState (list), owner (list) 12. LINKAGE LEVEL: 'Test Case' for test case level links, 'Test Step' for step level links 13. ISSUE TYPE IDs: Typically 1=Bug, 2=Enhancement, 3=Task (verify with your QMetry instance) 14. ISSUE PRIORITY IDs: Typically 1=High, 2=Medium, 3=Low (verify with your QMetry instance) 15. ISSUE STATUS IDs: Typically 1=Open, 2=In Progress, 3=Resolved, 4=Closed (verify with your QMetry instance) 16. OWNER IDs: Use numeric user IDs from QMetry user management 17. Multiple filter conditions are combined with AND logic 18. Use pagination for large issue result sets (start, page, limit parameters) 19. This tool is essential for defect tracking and traceability audits 20. Helps establish relationships between test failures and reported issues 21. Critical for impact analysis when test cases change 22. Use for compliance reporting and quality metrics

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
tcIDYesTest Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters.
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
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).
projectKeyNoProject key - unique identifier for the projectdefault
Install Server

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: filter conditions combine with AND logic, linkageLevel distinguishes 'Test Case' vs 'Test Step', and filter ID mappings for issueType/issuePriority/issueState are disclosed. It does not contradict the annotations.

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?

Sections (Parameters, Output, Use Cases, Examples, Hints) make it navigable and the critical tcID/getLinked facts are usefully front-loaded and repeated. But it is over-long and redundant: hints 1-2 and 7-9 restate the parameter section, six of the ten use cases say essentially 'traceability/compliance', and the numbered sub-list for 'HOW TO GET tcID' is malformed. Several closing hints ('essential for defect tracking', 'critical for impact analysis') are filler that does not help an agent invoke the tool.

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?

For a 7-parameter tool with no output schema and non-trivial filter JSON syntax, coverage is strong: return shape is described (issues array with priorities, status, linkage info), filter syntax is shown in three examples, ID mappings are given, and pagination is demonstrated. Minor gaps remain: the interaction between the start and page pagination parameters is never clarified, and error behavior (invalid tcID, empty results) is not addressed.

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%, giving a baseline of 3, but the description adds real value beyond the schema: the CRITICAL naming warning for tcID, a step-by-step procedure to resolve MAC-TC-1684 → tcID via FETCH_TEST_CASES, the list of valid filter field names (summary, executedVersion, linkageLevel, issueType, issuePriority, issueState, owner), and the numeric ID-to-label mappings used inside filter values.

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?

Opens with a specific verb+resource: 'Get issues that are linked (or not linked) to a specific test case in QMetry'. The linked/not-linked duality is stated up front, and the tcID hints explicitly distinguish this from entity-key lookups and from the sibling qmetry_fetch_linked_issues_of_test_case_run by scoping to a test case, not a test case run.

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?

Provides 10 concrete use cases (defect tracking, gap analysis, traceability audits) and seven worked examples covering the getLinked=true/false distinction, pagination, and filtering. Also gives a resolution procedure referencing sibling FETCH_TEST_CASES to obtain tcID. However, it never explicitly excludes the near-sibling qmetry_fetch_linked_issues_of_test_case_run or states when that alternative should be chosen instead.

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