Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QTM4J: Update Test Case

qtm4j_update_test_case
Idempotent

Update an existing test case by modifying priority, status, summary, or other fields. Add or remove labels and components 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
Behavior5/5

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

Annotations indicate idempotent, non-destructive, and non-read-only. The description adds detail on partial updates (omitted fields unchanged), auto-resolution warnings, and output format. No contradictions found.

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?

Description is well-structured with summary, parameters, output, use cases, examples, and hints. It is front-loaded and each section serves a clear purpose. No unnecessary text.

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 the complexity (11 parameters, nested objects, auto-resolution), the description covers prerequisites, examples, output specs, and edge cases. It is fully sufficient for correct invocation.

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 significant context: key format, source of priority/status values, add/delete structure for labels/components, and estimatedTime format. This goes well beyond 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 explicitly states 'Update an existing test case in QTM4J' with clear verb+resource. It distinguishes from create tools and provides detailed auto-resolution behavior for names, making the purpose unmistakable.

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?

The description includes explicit prerequisites (set_project_context must be called first), key format rules, hints about partial updates, and when to use add/delete for labels and components. Use cases and examples guide the agent comprehensively.

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