Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QTM4J: Get Linked Test Cases for Requirement

qtm4j_get_linked_test_cases_for_requirement
Read-onlyIdempotent

Retrieve test cases linked to a Jira requirement to check coverage or audit traceability. Filter by status, priority, or other criteria for release readiness.

Instructions

Retrieve the test cases linked to a Jira requirement in QTM4J. Requirement key is resolved to internal ID automatically.

Toolset: Requirements

Parameters:

  • requirementKey (string) required: Jira requirement key (e.g., 'SCRUM-1'). Resolved to the internal Jira issue ID automatically.

  • filter (object): Optional filter to narrow down the linked test cases. projectId is auto-filled from the active project context.

  • fields (string): Comma-separated field names to include in each result. Allowed: summary, priority, status, estimatedTime, executed, description, assignee, reporter, labels, components, fixVersions, sprint, isAutomated, folder, updated, created, seqNo, flakyScore, passRateScore.

  • maxResults (number): Maximum results per page (1-100). Default: 50.

  • startAt (number): Zero-indexed offset for pagination. Default: 0.

  • sort (string): Sort in 'field:asc|desc' format. Allowed fields: key, summary, created, updated, estimatedTime, status, priority, latestVersionNo, seqNo, flakyScore, passRateScore.

Output Description: Paginated response with total, startAt, maxResults, and data array of linked test case objects.

Use Cases: 1. Check which test cases cover a Jira story or bug 2. Audit requirement traceability — find all test cases for a given requirement 3. Filter linked test cases by status or priority before a release 4. Retrieve test case keys to use in update or link operations

Examples:

  1. Get all test cases linked to a requirement

{
  "requirementKey": "SCRUM-1"
}

Expected Output: Paginated list of linked test cases

  1. Get high priority linked test cases

{
  "requirementKey": "SCRUM-5",
  "filter": {
    "priority": [
      "High"
    ]
  },
  "fields": "key,summary,status,priority",
  "sort": "key:asc"
}

Expected Output: Filtered high-priority test cases linked to requirement

  1. Paginate through linked test cases

{
  "requirementKey": "SCRUM-1",
  "maxResults": 20,
  "startAt": 20
}

Expected Output: Second page of linked test cases

Hints: 1. PREREQUISITE: set_project_context must be called before this tool. NEVER auto-select a project. 2. REQUIREMENT KEY FORMAT: '{PROJECT_KEY}-{number}' — e.g. 'SCRUM-1'. 3. projectId in filter is auto-filled from the active project context — do not set it manually. 4. Use the fields param to limit response size — only request fields you need. 5. Paginate using startAt — increment by maxResults until startAt >= total. 6. filter.testCaseStatus can be 'active', 'archived', or 'deleted' to filter by archive state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort in 'field:asc|desc' format. Allowed fields: key, summary, created, updated, estimatedTime, status, priority, latestVersionNo, seqNo, flakyScore, passRateScore.
fieldsNoComma-separated field names to include in each result. Allowed: summary, priority, status, estimatedTime, executed, description, assignee, reporter, labels, components, fixVersions, sprint, isAutomated, folder, updated, created, seqNo, flakyScore, passRateScore.
filterNoOptional filter to narrow down the linked test cases. projectId is auto-filled from the active project context.
startAtNoZero-indexed offset for pagination. Default: 0.
maxResultsNoMaximum results per page (1-100). Default: 50.
requirementKeyYesJira requirement key (e.g., 'SCRUM-1'). Resolved to the internal Jira issue ID automatically.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesTest cases on this page
totalYesTotal test cases matching the filter (across all pages)
startAtYesOffset of this page
maxResultsYesPage size used for this response
Install Server

TDQS

A4.7/5.0
Behavior5/5

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

While annotations already mark the operation as readOnly, idempotent, and non-destructive, the description adds meaningful behavioral context: the requirement key is automatically resolved to an internal ID, projectId is auto-filled from active project context, pagination follows a specific startAt/maxResults pattern, and the tool depends on a prior project context setup. This goes well beyond 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.

Conciseness5/5

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

The description is long but exceptionally well structured: a one-sentence summary, Toolset label, parameter breakdown, output description, use cases, examples, and hints. Each section earns its place, and the core purpose is front-loaded in the first sentence.

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 tool with six parameters, nested filters, an output schema, and notable prerequisites, the description is complete. It covers when to use it, how to satisfy the project context prerequisite, key format, filtering, pagination, field selection, and example invocations. Nothing an agent needs to call this correctly is missing.

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. The description adds extra value by reinforcing auto-resolution of requirementKey, warning not to set projectId manually, documenting pagination defaults, and giving worked examples that show how filter and sort compose. It is not a full semantic manual, but it meaningfully supplements the schema.

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 opens with a specific verb+resource pair: 'Retrieve the test cases linked to a Jira requirement in QTM4J.' This clearly identifies the operation and differentiates it from sibling tools like qtm4j_link_test_cases_to_requirement and qtm4j_get_linked_requirements, which are conceptually different operations.

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 clear use cases, a stated prerequisite ('set_project_context must be called before this tool'), and a warning ('NEVER auto-select a project'). It does not explicitly name when not to use this tool versus a sibling, but the context is strong enough for an agent to select it correctly.

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