Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Test Cases Linked to Requirement

qmetry_fetch_test_cases_linked_to_requirement
Read-onlyIdempotent

Get test cases linked (or unlinked) to a requirement to verify coverage, find gaps, and assess impact of changes. Filter by release, cycle, folder, or criteria for targeted analysis.

Instructions

Get test cases that are linked (or not linked) to a specific requirement in QMetry

Toolset: Requirements

Parameters:

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

  • rqID (number) required: Requirement numeric ID (required for fetching specific requirement details). This is the internal numeric identifier, not the entity key like 'MAC-RQ-730'. You can get this ID from requirement search results or by using filters.

  • getLinked (boolean): True to get only test cases that are linked with this requirement, false to get test cases which are not linked with this requirement. Defaults to true (get linked test cases). (default: true)

  • showEntityWithReleaseCycle (boolean): True to list only test cases which have given release and cycle, false for all test cases regardless of release/cycle association. Defaults to false (show all). (default: false)

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

  • tcFolderPath (string): Folder path to get test cases under specific folder. Use empty string "" for root folder or specify path like "/Sample Template". (default: "")

  • releaseID (string): Filter test cases by release ID. Accepts a string or number. Get release IDs from FETCH_RELEASES_AND_CYCLES tool.

  • cycleID (string): Filter test cases by cycle ID. Accepts a string or number. Get cycle IDs from FETCH_RELEASES_AND_CYCLES tool.

  • filter (string): Filter criteria as JSON string (default '[]') (default: "[]")

  • getSubEntities (boolean): Allow filter of sub-entities for requirement. (default: true)

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

Output Description: JSON object with test cases array, traceability information, and pagination metadata

Use Cases: 1. Get all test cases linked to a specific requirement for traceability analysis 2. Find test cases that are NOT linked to a requirement (gap analysis) 3. Verify requirement coverage by checking linked test cases 4. Impact analysis - see which test cases are affected when a requirement changes 5. Generate traceability matrix between requirements and test cases 6. Filter linked test cases by release, cycle, or other criteria 7. Audit requirement-test case relationships for compliance 8. Identify orphaned test cases or requirements without proper links 9. Plan test execution based on requirement-test case associations 10. Quality assurance - ensure all requirements have adequate test coverage

Examples:

  1. Get all test cases linked to requirement ID 4791316

{
  "rqID": 4791316
}

Expected Output: List of test cases that are linked to requirement MAC-RQ-1011

  1. Get test cases NOT linked to requirement (gap analysis)

{
  "rqID": 4791316,
  "getLinked": false
}

Expected Output: List of test cases that are NOT linked to requirement MAC-RQ-1011

  1. Get linked test cases filtered by specific release

{
  "rqID": 4791316,
  "releaseID": "55178"
}

Expected Output: Linked test cases associated with Release 8.12 (ID: 55178)

  1. Get linked test cases filtered by release and cycle

{
  "rqID": 4791316,
  "releaseID": "55178",
  "cycleID": "111577",
  "showEntityWithReleaseCycle": true
}

Expected Output: Linked test cases in Release 8.12 and Cycle 8.12.1

  1. Get linked test cases from specific folder

{
  "rqID": 4791316,
  "tcFolderPath": "/Sample Template"
}

Expected Output: Linked test cases located in the '/Sample Template' folder

  1. Search linked test cases by entity key

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"string\",\"value\":\"MAC-TC-1684,MAC-TC-1685\",\"field\":\"entityKeyId\"}]"
}

Expected Output: Linked test cases matching specific entity keys

  1. Filter linked test cases by priority

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"list\",\"value\":[1,2],\"field\":\"priorityAlias\"}]"
}

Expected Output: Linked test cases with High or Medium priority

  1. Filter linked test cases by status

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"list\",\"value\":[1,2],\"field\":\"testCaseStateAlias\"}]"
}

Expected Output: Linked test cases with Active or Review status

  1. Filter linked test cases by test case type

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"list\",\"value\":[1],\"field\":\"testCaseTypeAlias\"}]"
}

Expected Output: Linked functional test cases

  1. Filter linked test cases by testing type (automation)

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"list\",\"value\":[2],\"field\":\"testingTypeAlias\"}]"
}

Expected Output: Linked automated test cases

  1. Get only parameterized linked test cases

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"list\",\"value\":[1],\"field\":\"isParameterized\"}]"
}

Expected Output: Linked test cases that are parameterized (data-driven)

  1. Filter linked test cases by archive status

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"list\",\"value\":[0],\"field\":\"isArchived\"}]"
}

Expected Output: Active (non-archived) linked test cases

  1. Search linked test cases by summary content

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"string\",\"value\":\"login\",\"field\":\"summary\"}]"
}

Expected Output: Linked test cases with 'login' in their summary

  1. Filter linked test cases by requirement version

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"string\",\"value\":\"1\",\"field\":\"rqVersion\"}]"
}

Expected Output: Test cases linked to version 1 of the requirement

  1. Complex filter: Active, high priority, automated test cases

{
  "rqID": 4791316,
  "filter": "[{\"type\":\"list\",\"value\":[0],\"field\":\"isArchived\"},{\"type\":\"list\",\"value\":[1],\"field\":\"priorityAlias\"},{\"type\":\"list\",\"value\":[2],\"field\":\"testingTypeAlias\"}]"
}

Expected Output: Active, high priority, automated test cases linked to requirement

Hints: 1. This API requires a numeric rqID parameter, not entity key 2. If user provides entityKey (e.g., MAC-RQ-1011), first call FETCH_REQUIREMENTS with filter on entityKeyId to resolve the numeric rqID 3. After resolving entityKey → rqID, call this tool with the resolved numeric rqID 4. TRACEABILITY WORKFLOW: Use this tool to establish requirement-test case traceability matrix 5. getLinked=true (default): Returns test cases that ARE linked to the requirement 6. getLinked=false: Returns test cases that are NOT linked to the requirement (useful for gap analysis) 7. showEntityWithReleaseCycle=true: Only show test cases that have the specified release and cycle 8. showEntityWithReleaseCycle=false (default): Show all test cases regardless of release/cycle 9. RELEASE/CYCLE FILTERING: Use string IDs, not numeric (e.g., releaseID: '55178', cycleID: '111577') 10. Get release/cycle IDs from FETCH_RELEASES_AND_CYCLES tool before filtering 11. tcFolderPath: Use empty string '' for root folder or specific path like '/Sample Template' 12. FILTER CAPABILITIES: Support same filters as regular test case listing 13. FILTER FIELDS: summary, rqVersion, priorityAlias, testCaseStateAlias, createdByAlias, testCaseTypeAlias, testingTypeAlias, release, cycle, isArchived, isParameterized, componentAlias, entityKeyId 14. PRIORITY IDs: Typically 1=High, 2=Medium, 3=Low (verify with your QMetry instance) 15. STATUS IDs: Typically 1=Active, 2=Review, 3=Deprecated (verify with your QMetry instance) 16. TYPE IDs: Typically 1=Functional, 2=Integration, 3=System (verify with your QMetry instance) 17. TESTING TYPE IDs: Typically 1=Manual, 2=Automated (verify with your QMetry instance) 18. PARAMETERIZED: 1=Yes (parameterized), 0=No (non-parameterized) 19. ARCHIVED: 1=Archived, 0=Active (non-archived) 20. Multiple filter conditions are combined with AND logic 21. For entity key search, use comma-separated values: 'MAC-TC-1,MAC-TC-2,MAC-TC-3' 22. This tool is crucial for compliance, traceability audits, and impact analysis 23. Use getColumns=true to get column metadata for better result interpretation 24. Pagination supported for large result sets (start, page, limit parameters)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number to return (starts from 1)
rqIDYesRequirement numeric ID (required for fetching specific requirement details). This is the internal numeric identifier, not the entity key like 'MAC-RQ-730'. You can get this ID from requirement search results or by using filters.
limitNoNumber of records (default 10).
startNoStart index for pagination - defaults to 0
filterNoFilter criteria as JSON string (default '[]')[]
cycleIDNoFilter test cases by cycle ID. Accepts a string or number. Get cycle IDs from FETCH_RELEASES_AND_CYCLES tool.
getLinkedNoTrue to get only test cases that are linked with this requirement, false to get test cases which are not linked with this requirement. Defaults to true (get linked test cases).
releaseIDNoFilter test cases by release ID. Accepts a string or number. Get release IDs from FETCH_RELEASES_AND_CYCLES tool.
getColumnsNoTrue to get column information in response.
projectKeyNoProject key - unique identifier for the projectdefault
tcFolderPathNoFolder path to get test cases under specific folder. Use empty string "" for root folder or specify path like "/Sample Template".
getSubEntitiesNoAllow filter of sub-entities for requirement.
showEntityWithReleaseCycleNoTrue to list only test cases which have given release and cycle, false for all test cases regardless of release/cycle association. Defaults to false (show all).
Install Server

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description adds substantial non-obvious behavior: getLinked flips between linked and unlinked test cases, showEntityWithReleaseCycle restricts results, filter conditions combine with AND, and pagination is supported. It also documents typical filter ID mappings and default values. No contradiction with 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?

The description is well-structured with clear headings and front-loads the core purpose, but it is very long: 10 use cases, 15 examples, and 24 hints contain substantial repetition of the parameter documentation. Useful for a complex tool, yet several examples and hints could be consolidated.

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 13-parameter read-only tool with no output schema, the description provides an output summary, default behaviors, detailed filter capabilities, pagination guidance, and prerequisite dependencies like numeric rqID resolution and release/cycle ID lookup. An agent has nearly everything needed to call this tool correctly.

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%, so the baseline is 3, but the description adds genuine value with concrete filter JSON examples for entityKeyId, priorityAlias, testCaseStateAlias, isArchived, and other fields. Hints additionally clarify that releaseID/cycleID should come from FETCH_RELEASES_AND_CYCLES and that rqID is not the entity key. The parameter table itself is redundant, but examples and hints exceed the baseline.

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?

States a specific verb/resource pair: 'Get test cases that are linked (or not linked) to a specific requirement in QMetry' and labels the Toolset as 'Requirements', which differentiates it from sibling tools that fetch requirements linked to test cases or test-suite-related links. The emphasis on numeric rqID over entity key further clarifies what the tool targets.

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 clear contextual guidance: use FETCH_REQUIREMENTS to resolve an entityKey to numeric rqID, get release/cycle IDs from FETCH_RELEASES_AND_CYCLES before filtering, and use getLinked=false for gap analysis. It enumerates use cases like traceability and impact analysis, though it doesn't explicitly name exclusion scenarios or direct alternatives.

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