Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Fetch Requirements Linked to Test Case

qmetry_fetch_requirements_linked_to_test_case
Read-onlyIdempotent

Get linked or unlinked requirements for a test case to perform traceability analysis, verify test coverage, and identify gaps in requirement-test associations.

Instructions

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

Toolset: Requirements

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 requirements that are linked with this test case, false to get requirements which are not linked with this test case. Defaults to true (get linked requirements). (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)

  • rqFolderPath (string): Folder path for requirements - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression". (default: "")

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

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

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

Examples:

  1. Get all requirements linked to test case ID 594294

{
  "tcID": 594294
}

Expected Output: List of requirements that are linked to test case MAC-TC-1684

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

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

Expected Output: List of requirements that are NOT linked to test case MAC-TC-1684

  1. Get linked requirements from specific folder

{
  "tcID": 594294,
  "rqFolderPath": "/CodeSnippets"
}

Expected Output: Linked requirements located in the '/CodeSnippets' folder

  1. Search linked requirements by entity key

{
  "tcID": 594294,
  "filter": "[{\"type\":\"string\",\"value\":\"MAC-RQ-730,MAC-RQ-731\",\"field\":\"entityKeyId\"}]"
}

Expected Output: Linked requirements matching specific entity keys

  1. Filter linked requirements by status

{
  "tcID": 594294,
  "filter": "[{\"type\":\"list\",\"value\":[1,2],\"field\":\"requirementStateAlias\"}]"
}

Expected Output: Linked requirements with Open or Approved status

  1. Filter linked requirements by priority

{
  "tcID": 594294,
  "filter": "[{\"type\":\"list\",\"value\":[1],\"field\":\"priorityAlias\"}]"
}

Expected Output: Linked requirements with High priority

  1. Filter linked requirements by archive status

{
  "tcID": 594294,
  "filter": "[{\"type\":\"list\",\"value\":[0],\"field\":\"isArchived\"}]"
}

Expected Output: Active (non-archived) linked requirements

  1. Search linked requirements by name content

{
  "tcID": 594294,
  "filter": "[{\"type\":\"string\",\"value\":\"authentication\",\"field\":\"name\"}]"
}

Expected Output: Linked requirements with 'authentication' in their name

  1. Filter linked requirements by test case version

{
  "tcID": 594294,
  "filter": "[{\"type\":\"string\",\"value\":\"1\",\"field\":\"tcVersion\"}]"
}

Expected Output: Requirements linked to version 1 of the test case

  1. Filter linked requirements by release and cycle

{
  "tcID": 594294,
  "filter": "[{\"type\":\"list\",\"value\":[55178],\"field\":\"release\"},{\"type\":\"list\",\"value\":[111577],\"field\":\"cycle\"}]"
}

Expected Output: Linked requirements in Release 8.12 and Cycle 8.12.1

Hints: 1. This API requires a numeric tcID parameter, not entity key 2. If user provides entityKey (e.g., MAC-TC-1684), first call FETCH_TEST_CASES with filter on entityKeyId to resolve the numeric tcID 3. After resolving entityKey → tcID, call this tool with the resolved numeric tcID 4. TRACEABILITY WORKFLOW: Use this tool to establish test case-requirement traceability matrix 5. getLinked=true (default): Returns requirements that ARE linked to the test case 6. getLinked=false: Returns requirements that are NOT linked to the test case (useful for gap analysis) 7. rqFolderPath: Use empty string '' for root folder or specific path like '/CodeSnippets' 8. FILTER CAPABILITIES: Support same filters as regular requirement listing 9. FILTER FIELDS: name, entityKeyId, requirementStateAlias, priorityAlias, createdByAlias, tcVersion, release, cycle, isArchived, componentAlias 10. Multiple filter conditions are combined with AND logic 11. For entity key search, use comma-separated values: 'MAC-RQ-1,MAC-RQ-2,MAC-RQ-3' 12. This tool is crucial for compliance, traceability audits, and impact analysis 13. Pagination supported for large result sets (start, page, limit parameters) 14. Use this tool to verify that test cases properly cover requirements 15. Essential for requirement validation and test case completeness analysis

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 requirements that are linked with this test case, false to get requirements which are not linked with this test case. Defaults to true (get linked requirements).
projectKeyNoProject key - unique identifier for the projectdefault
rqFolderPathNoFolder path for requirements - SYSTEM AUTOMATICALLY SETS TO ROOT. Leave empty unless you want specific folder. System will automatically use empty string "" (root directory). Only specify if user wants specific folder like "Automation/Regression".
Behavior4/5

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

Annotations already mark it as readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by explaining the output format (JSON with requirements, traceability, pagination) and the behavior of key parameters like getLinked and rqFolderPath. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-organized into sections (description, parameters, output, use cases, examples, hints). Each section contributes value. A slight reduction in verbosity could improve conciseness, but the structure is clear and front-loaded.

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 9 parameters, no output schema, and no enums, the description covers all necessary aspects: parameter behaviors, prerequisites (entity key resolution), many use cases, and examples. It is thorough enough for an AI agent to use 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%, but the description adds crucial context beyond the schema: it warns about the exact parameter name 'tcID', explains the difference between numeric ID and entity key, details rqFolderPath automatic root setting, and provides many filter examples. This significantly enhances understanding.

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 requirements linked or not linked to a specific test case, using a specific verb ('Get') and resource. It distinguishes from siblings like qmetry_fetch_requirements (general listing) and qmetry_fetch_test_cases_linked_to_requirement (reverse direction) through its precise purpose.

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 guidance including 10 use cases, 15 hints, and prerequisites (e.g., resolve entity key to numeric tcID). It implicitly differentiates from other tools but does not explicitly state when NOT to use it.

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