Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Update Test Suite

qmetry_update_test_suite

Update a QMetry test suite using its numeric ID or entity key, automatically resolving folder and project info to change name, description, owner, or state.

Instructions

Update an existing QMetry test suite by id(testsuite numeric id), with auto-resolution from entityKey.

Toolset: Test Suites

Parameters:

  • id (number) required: Id of Test Suite to be updated (required)

  • TsFolderID (number): Folder ID where Test Suite resides - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific folder ID. System will fetch project info using the projectKey and extract rootFolders.TS.id automatically. Manual folder ID only needed if you want to override the automatic resolution.

  • entityKey (string) required: Entity Key of Test Suite to be updated (required)

  • name (string): Name of the Test Suite

  • description (string): Description of the Test Suite

  • testsuiteOwner (number): Owner ID of the Test Suite

  • testSuiteState (number): State of the Test Suite

Output Description: JSON object containing the new test suite ID, summary, and creation metadata.

Use Cases: 1. Update test suite summary (name) 2. Change owner, or state of a test suite 3. Bulk update using entityKey auto-resolution 4. Modify test suite description

Examples:

  1. Update test suite summary (updated name)

{
  "id": 1505898,
  "entityKey": "VT-TS-7",
  "TsFolderID": 1644087,
  "name": "MAC Test11"
}

Expected Output: Test suite summary updated. Only 'name' field changed. Field IDs auto-resolved from project info. id(test suite numeric id) resolved from entityKey. TsFolderID auto-resolved. from the project info. info on rootFolders.TS.id.

  1. Update state to Open and owner of the test suite

{
  "id": 1505898,
  "entityKey": "VT-TS-7",
  "TsFolderID": 1644087,
  "testSuiteState": 505036,
  "testsuiteOwner": 6963
}

Expected Output: State and owner updated. Example uses: testSuiteState=505036 (Open from customListObjs.testSuiteState[index].id), testsuiteOwner=6963 (umang.savaliya from customListObjs.owner[index].id). Field IDs auto-resolved from project info. id(test suite numeric id) resolved from entityKey. TsFolderID auto-resolved from the project info rootFolders.TS.id.

  1. Update only description of the test suite

{
  "id": 1505898,
  "entityKey": "VT-TS-7",
  "TsFolderID": 1644087,
  "description": "Updated description for the test suite."
}

Expected Output: description updated only. Field IDs auto-resolved from project info. id(test suite numeric id) resolved from entityKey. TsFolderID auto-resolved. from the project info. info on rootFolders.TS.id.

Hints: 1. If user provides entityKey (e.g., MAC-TS-7), first call Fetch Test Suites with a filter on entityKeyId to resolve the id (test suite numeric id) and TsFolderID from rootFolders.TS.id. 2. To get valid values for owner, state, etc., call the 'Admin/Get info Service' API (FETCH_PROJECT_INFO tool) and use the returned customListObjs IDs. 3. CRITICAL: For testsuiteOwner mapping - Call API 'Admin/Get info Service', from the response get value from customListObjs.owner[].id. Match the user by customListObjs.owner[].name. 4. If the user provides an owner name, fetch project info, find the matching user in customListObjs.owner[index].name, and use its ID in the payload as testsuiteOwner. If the name is not found, skip the testsuiteOwner field (it is not required) and show a user-friendly message: 'Test suite updated without owner, as given owner is not available in the current project.' 5. CRITICAL: For testSuiteState mapping - Call API 'Admin/Get info Service', from the response get value from customListObjs.testSuiteState[].id. Match the state by customListObjs.testSuiteState[].name. 6. If the user provides a test suite state name, fetch project info, find the matching state in customListObjs.testSuiteState[index].name, and use its ID in the payload as testSuiteState. If the name is not found, skip the testSuiteState field (it is not required) and show a user-friendly message: 'Test suite updated without test suite state, as given state is not available in the current project.' 7. If either owner or state is not found in project info, the update for that field will be skipped and a user-friendly message will be shown to the user. 8. UDF fields in steps must match your QMetry custom field configuration. 9. All IDs (testSuiteState from customListObjs.testSuiteState[index].id, testsuiteOwner from customListObjs.owner[index].id) must be valid for your QMetry instance. 10. If a custom field is mandatory, include it in the UDF object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesId of Test Suite to be updated (required)
nameNoName of the Test Suite
entityKeyYesEntity Key of Test Suite to be updated (required)
TsFolderIDNoFolder ID where Test Suite resides - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific folder ID. System will fetch project info using the projectKey and extract rootFolders.TS.id automatically. Manual folder ID only needed if you want to override the automatic resolution.
descriptionNoDescription of the Test Suite
testSuiteStateNoState of the Test Suite
testsuiteOwnerNoOwner ID of the Test Suite
Behavior4/5

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

Annotations indicate readOnlyHint=false, consistent with update behavior. The description adds details on auto-resolution of TsFolderID and entityKey, and the fallback behavior when owner/state are not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is lengthy with many hints and examples. While informative, it could be more concise. The main purpose is front-loaded, but the extra details make it less succinct.

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 (7 parameters, no output schema), the description is very complete. It covers parameters, auto-resolution, mapping, fallback behaviors, and includes examples with expected outputs.

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 baseline is 3. The description adds significant value by explaining auto-resolution for TsFolderID, how to map testsuiteOwner and testSuiteState from project info, and the use of customListObjs.

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 'Update an existing QMetry test suite by id' and provides explicit use cases (e.g., update summary, change owner/state). It distinguishes from sibling tools like qmetry_create_test_suite and qmetry_fetch_test_suites.

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 includes hints on when to use this tool, such as resolving IDs via entityKey and using fetch_qmetry_project_info for valid owner/state values. It does not explicitly state when not to use it, but the context is clear.

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