Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QTM4J: Link Test Cases to Test Cycle

qtm4j_link_test_cases_to_test_cycle

Link test cases to a QTM4J test cycle by test case keys or filter criteria, with automatic key resolution and options for assignees, environments, and execution settings.

Instructions

Link test cases to a QTM4J test cycle by test case keys or filter criteria. Test case keys are resolved to internal IDs and latest versions automatically.

Toolset: Test Cycles

Parameters:

  • cycleKey (string) required: Test Cycle key (e.g., 'SCRUM-TR-1'). Resolved to the internal cycle UID automatically.

  • testCaseKeys (array): Test case keys to link (e.g., ['SCRUM-TC-1', 'SCRUM-TC-2']). Resolved to internal IDs and latest versions automatically. Provide this OR filter — not both.

  • filter (object): Filter criteria to select test cases to link. projectId is auto-filled from the active project context.

  • sort (string): Sort order in 'field:asc|desc' format (e.g., 'createdOn:desc'). Default is 'createdOn:desc'.

  • assignee (string): Jira account ID of the assignee for the linked executions.

  • environmentId (number): Environment ID from 'Get all environments in a project'.

  • buildId (number): Build ID from 'Get all builds in a project'.

  • actualTime (string): Actual time spent in HH:mm format (e.g., '02:30').

  • startNewExecution (boolean): Start a new execution for linked test cases. Default is false.

  • executionPlannedDate (string): Planned execution date in yyyy-MM-dd format (e.g., '2023-12-31').

  • qiGenerated (boolean): Flag indicating AI-generated test cases. Default is false.

Output Description: Confirmation with the cycle key and linked: true. Warnings included if any test cases could not be resolved or linked.

Use Cases: 1. Add specific test cases to a test cycle by key 2. Populate a test cycle with test cases matching a filter (e.g., all High priority test cases) 3. Link test cases from a specific folder to a test cycle 4. Add test cases to a cycle with a specific assignee or environment

Examples:

  1. Link two test cases by key

{
  "cycleKey": "SCRUM-TR-1",
  "testCaseKeys": [
    "SCRUM-TC-10",
    "SCRUM-TC-11"
  ]
}

Expected Output: Test cases linked to test cycle

  1. Link test cases matching a filter with assignee

{
  "cycleKey": "SCRUM-TR-1",
  "filter": {
    "priority": [
      "High"
    ],
    "status": [
      "To Do"
    ]
  },
  "assignee": "5b10a2844c20165700ede21f",
  "startNewExecution": true
}

Expected Output: Filtered test cases linked to cycle with assignee

  1. Link test cases in a folder to a cycle with planned date

{
  "cycleKey": "SCRUM-TR-5",
  "filter": {
    "folderId": 42,
    "withChild": true
  },
  "executionPlannedDate": "2024-03-31",
  "sort": "key:asc"
}

Expected Output: Folder test cases linked to cycle with planned date

Hints: 1. PREREQUISITE: set_project_context must be called before this tool. NEVER auto-select a project. 2. CYCLE KEY FORMAT: '{PROJECT_KEY}-TR-{id}' — e.g. 'SCRUM-TR-1'. Resolved to internal UID automatically. 3. TEST CASE KEY FORMAT: '{PROJECT_KEY}-TC-{number}' — e.g. 'SCRUM-TC-145'. 4. Provide either testCaseKeys or filter — not both. 5. projectId in filter is auto-filled from the active project context — do not set it manually. 6. filter.excludeCycleId excludes test cases already in another cycle. 7. startNewExecution: true creates a fresh execution record for each linked test case. 8. executionPlannedDate must be in yyyy-MM-dd format (e.g., '2024-03-31'). 9. actualTime must be in HH:mm format (e.g., '02:30'). 10. If a test case key cannot be resolved, it is reported in warnings and others are still linked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort order in 'field:asc|desc' format (e.g., 'createdOn:desc'). Default is 'createdOn:desc'.
filterNoFilter criteria to select test cases to link. projectId is auto-filled from the active project context.
buildIdNoBuild ID from 'Get all builds in a project'.
assigneeNoJira account ID of the assignee for the linked executions.
cycleKeyYesTest Cycle key (e.g., 'SCRUM-TR-1'). Resolved to the internal cycle UID automatically.
actualTimeNoActual time spent in HH:mm format (e.g., '02:30').
qiGeneratedNoFlag indicating AI-generated test cases. Default is false.
testCaseKeysNoTest case keys to link (e.g., ['SCRUM-TC-1', 'SCRUM-TC-2']). Resolved to internal IDs and latest versions automatically. Provide this OR filter — not both.
environmentIdNoEnvironment ID from 'Get all environments in a project'.
startNewExecutionNoStart a new execution for linked test cases. Default is false.
executionPlannedDateNoPlanned execution date in yyyy-MM-dd format (e.g., '2023-12-31').

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
linkedNo
cycleKeyYes
unlinkedNo
Install Server

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations, the description discloses that keys are resolved automatically, unresolved test cases are reported in warnings while others are still linked, and startNewExecution controls whether fresh executions are created. It also clarifies that projectId in filter must not be set manually. These are meaningful behavioral details not present in structured annotations.

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 its length is justified by 11 parameters, a complex filter object, prerequisites, examples, and key format hints. It is well front-loaded and organized into sections, though some hints repeat information already present in the parameter list.

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?

The description is highly complete for a complex mutation tool: it names the mandatory prerequisite, explains both input modes, gives key formats, provides warnings behavior, describes the output, and includes realistic examples. Since an output schema exists, not detailing every return field is acceptable.

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?

Although the schema already documents every parameter (100% coverage), the description adds essential semantics: automatic resolution to internal IDs, mutual exclusivity between testCaseKeys and filter, format constraints for dates and times, and guidance on how filter fields like excludeCycleId or projectId behave. This goes well beyond the schema definitions.

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 first sentence states a specific action and resource: 'Link test cases to a QTM4J test cycle by test case keys or filter criteria.' It clearly separates this from sibling tools like qtm4j_link_requirements_to_test_cycle by specifying test cases and the test cycle as the target.

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 gives clear operational guidance: set_project_context must be called first, testCaseKeys and filter are mutually exclusive, and projectId is auto-filled. It provides concrete use cases and examples. It does not explicitly state 'when not to use this tool' or name alternatives, but the context is strong enough for an agent to select it appropriately.

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