Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QTM4J: Update Test Case

qtm4j_update_test_case
Idempotent

Update an existing QTM4J test case by key to modify priority, status, summary, assignee, estimated time, labels, or components. Labels and components support add/delete with auto-resolved names.

Instructions

Update an existing test case in QTM4J. Supports auto-resolving human-readable names for priority, status, labels, and components. Labels and components support add/delete operations.

Toolset: Test Cases

Parameters:

  • key (string) required: Test case key in the format '{PROJECT_KEY}-TC-{number}', e.g. 'SCRUM-TC-145'. Automatically resolved to the internal ID and latest version.

  • versionNo (number): Test case version number to update. Defaults to the latest version if omitted.

  • summary (string): Updated test case summary/title.

  • description (string): Updated test case description.

  • precondition (string): Updated precondition — conditions that must be true before the test is executed.

  • priority (string): Priority name (e.g., 'High', 'Medium', 'Low'). Auto-resolved to ID. Use values from set_project_context response.

  • status (string): Status name (e.g., 'To Do', 'In Progress', 'Done'). Auto-resolved to ID. Use values from set_project_context response.

  • assignee (string): Assignee Jira account ID (e.g., '5b10a2844c20165700ede21f').

  • estimatedTime (string): Estimated time in HH:MM:SS format (e.g., '02:30:00').

  • labels (object): Labels to add or remove by name. Each name is auto-resolved to its ID.

  • components (object): Components to add or remove by name. Each name is auto-resolved to its ID.

Output Description: Confirmation object with the test case key, versionNo updated, and updated: true. Warnings are included if any field names could not be resolved.

Use Cases: 1. Change the priority of a test case (e.g., escalate to 'High') 2. Update the status of a test case after review 3. Add new labels or remove outdated ones without affecting other labels 4. Add or remove components from a test case 5. Update summary, description, or precondition text 6. Reassign a test case to a different team member 7. Set or update the estimated time for a test case 8. Batch-update metadata as part of sprint planning

Examples:

  1. Change the priority of a test case

{
  "key": "SCRUM-TC-145",
  "priority": "High"
}

Expected Output: Test case updated with new priority

  1. Add a label and remove an old one

{
  "key": "SCRUM-TC-145",
  "labels": {
    "add": [
      "Release_2"
    ],
    "delete": [
      "Release_1"
    ]
  }
}

Expected Output: Test case updated — Release_2 added, Release_1 removed

  1. Update summary, status, and add a component

{
  "key": "SCRUM-TC-32",
  "summary": "Verify login with MFA enabled",
  "status": "In Progress",
  "components": {
    "add": [
      "Auth"
    ]
  }
}

Expected Output: Test case summary and status updated, Auth component added

  1. Update a specific version

{
  "key": "SCRUM-TC-85",
  "versionNo": 2,
  "assignee": "5b10a2844c20165700ede21f",
  "estimatedTime": "01:30:00"
}

Expected Output: Version 2 of test case updated with new assignee and estimated time

Hints: 1. PREREQUISITE: set_project_context must be called before this tool. NEVER auto-select a project. 2. KEY FORMAT: '{PROJECT_KEY}-TC-{number}' — e.g. 'SCRUM-TC-145'. 3. Priority and status values come from set_project_context. Use NLP to map user intent to available names. 4. If priority or status name is not found, the field is skipped with a warning and other fields are still updated. 5. Labels and components use add/delete — you can add and delete in a single call. Names are auto-resolved. 6. To delete ALL current entries of any add/delete field: first call search_test_cases with filter.searchText set to the test case key and include the relevant field in the fields list, extract all current names from the response, then pass them in the delete array of this tool. 7. Only provide the fields you want to change. Omitted fields remain unchanged on the server. 8. estimatedTime must be in HH:MM:SS format (e.g., '02:30:00'). 9. versionNo defaults to the latest version. Use search_test_cases to find available versions if needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesTest case key in the format '{PROJECT_KEY}-TC-{number}', e.g. 'SCRUM-TC-145'. Automatically resolved to the internal ID and latest version.
labelsNoLabels to add or remove by name. Each name is auto-resolved to its ID.
statusNoStatus name (e.g., 'To Do', 'In Progress', 'Done'). Auto-resolved to ID. Use values from set_project_context response.
summaryNoUpdated test case summary/title.
assigneeNoAssignee Jira account ID (e.g., '5b10a2844c20165700ede21f').
priorityNoPriority name (e.g., 'High', 'Medium', 'Low'). Auto-resolved to ID. Use values from set_project_context response.
versionNoNoTest case version number to update. Defaults to the latest version if omitted.
componentsNoComponents to add or remove by name. Each name is auto-resolved to its ID.
descriptionNoUpdated test case description.
preconditionNoUpdated precondition — conditions that must be true before the test is executed.
estimatedTimeNoEstimated time in HH:MM:SS format (e.g., '02:30:00').

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesTest case key that was updated
updatedYesConfirms the update was applied
versionNoYesVersion number that was updated
Install Server

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool as non-read-only and non-destructive and idempotent; the description goes beyond them by explaining key auto-resolution, warning-and-skip behavior for unresolvable names, add/delete semantics, and that omitted fields remain unchanged on the server. This gives the agent a faithful model of the side effects and failure behavior.

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?

Despite its length, the description is organized into scannable sections (Parameters, Output Description, Use Cases, Examples, Hints) and the core purpose is front-loaded in the first sentence. The length is justified by the tool's 11 parameters, nested objects, and edge-case behavior.

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 complex mutation tool, the description covers prerequisites, output shape, warning behavior, version handling, and deletion workflow via search_test_cases, plus realistic examples. Nothing essential for selecting and invoking it correctly appears to be missing.

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?

Even though schema coverage is 100%, the description adds meaning through concrete examples (e.g., 'SCRUM-TC-145', add/delete label JSON, version-specific updates) and operational hints (only changed fields should be passed, unknown names are skipped with a warning, format constraints). These are meaningful beyond the schema's property descriptions.

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 statement ('Update an existing test case in QTM4J') and further defines its scope with auto-resolution and add/delete support. This clearly distinguishes it from siblings like qtm4j_create_test_case and qtm4j_search_test_cases by focusing on updating an existing entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit use cases (e.g., change priority, update status, add labels) and a prerequisite (set_project_context must be called first; never auto-select a project). It also gives alternative flow guidance, such as calling search_test_cases before deleting all current entries, making when-to-use and preconditions explicit.

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