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

Retrieve issues linked or not linked to a specific test case for defect tracking and traceability analysis.

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

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

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description need not repeat these. The description adds context about the getLinked parameter behavior and filter capabilities, but does not disclose authentication requirements, rate limits, or potential side effects beyond what annotations imply.

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?

The description is very long with multiple sections (Parameters, Output Description, Use Cases, Examples, Hints). While well-organized, it contains redundant information (e.g., some examples repeat similar patterns) and could be trimmed. The structure helps but conciseness suffers.

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?

Given the tool's complexity (8 parameters, array filtering, no output schema), the description is comprehensive. It explains how to obtain the required tcID, pagination, filter syntax, linkage levels, and includes 7 diverse examples. No output schema is present, but the output description is sufficient.

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% (all 8 parameters have descriptions), so baseline is 3. The description adds significant value beyond schema: explains CRITICAL naming of tcID, provides examples for complex filter JSON, and details default behaviors. This compensates for the lack of enums or nested objects.

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 clearly states it fetches issues linked or not linked to a specific test case. The verb 'Get' and resource 'issues linked to test case' are specific. It distinguishes from sibling tools like qmetry_fetch_linked_issues_of_test_case_run by focusing on test case (not run) and including the 'getLinked' boolean for flexibility.

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 a comprehensive 'Use Cases' section listing 10 scenarios, giving clear context for when to use the tool. However, it does not explicitly state when not to use it or compare to alternatives like qmetry_fetch_issues (not linked to test case) or qmetry_fetch_linked_issues_of_test_case_run.

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