Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Create Test Suite

qmetry_create_test_suite

Create a test suite in QMetry with metadata and optional release/cycle mapping for test planning.

Instructions

Create a new test suite in QMetry with metadata and release/cycle mapping.

Toolset: Test Suites

Parameters:

  • parentFolderId (string): Test Suite parent folder ID - 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 target a specific sub-folder.

  • name (string) required

  • isAutomatedFlag (boolean)

  • description (string)

  • testsuiteOwner (number)

  • testSuiteState (number)

  • associateRelCyc (boolean)

  • releaseCycleMapping (array)

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

Use Cases: 1. Create a basic test suite with just a name and folder 2. Add detailed metadata like description to a test suite 3. Associate test suite with specific release/cycle for planning 4. Set testsuiteOwner, testSuiteState, and other metadata using valid IDs from project info 5. Create test suites for isAutomatedFlag true or false for automated or manual types, default is false 6. Add test suite to a specific folder using parentFolderId 7. Map test suite to multiple cycles/releases and build ID

Examples:

  1. Create a test suite in the root folder (auto-resolved)

{
  "name": "Demo Test Suite"
}

Expected Output: Test suite created in the root test suite folder with ID and summary details

  1. Create a simple test suite in folder 102653

{
  "parentFolderId": "102653",
  "name": "Login Test Suite"
}

Expected Output: Test suite created with ID and summary details

  1. Create a test suite with some details and metadata

{
  "parentFolderId": "113557",
  "isAutomatedFlag": false,
  "name": "Testsuite Summary",
  "description": "desc",
  "testsuiteOwner": 6963,
  "testSuiteState": 505035,
  "associateRelCyc": true,
  "releaseCycleMapping": [
    {
      "buildID": 18411,
      "releaseId": 10286
    }
  ]
}

Expected Output: Test suite created with details and metadata. Example uses: parentFolderId=113557 (MAC root TS folder from rootFolders.TS.id), testsuiteOwner=6963 (umang.savaliya from customListObjs.owner[index].id), testSuiteState=505035 (New from customListObjs.testSuiteState[index].id), releaseId=10286 (Air release from projects[index].releases[index].releaseID), buildID=18411 (Air Q1-19 cycle from projects[index].releases[index].builds[index].buildID)

Hints: 1. If parentFolderId is not provided, it will be auto-resolved to the root test suite folder using project info (rootFolders.TS.id). 2. To get valid values for testsuiteOwner, testSuiteState, 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 (testsuiteOwner), fetch project info, find the matching owner in customListObjs.owner[index].name or customListObjs.owner[index].uniqueLabel, 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 created 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(testSuiteState), 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 created without test suite state, as given state is not available in the current project.' 7. parentFolderId is required; use the root folder ID from project info (rootFolders.TS.id) or a specific folder. 8. Release/cycle mapping is optional but useful for planning. 9. If the user wants to link or associate a release and cycle to the test suite, set associateRelCyc: true in the payload. 10. CRITICAL: For releaseCycleMapping.releaseId - Call API 'Release/List' (or use project info projects[].releases[].releaseID), from the response get value from data[].releaseID or projects[].releases[].releaseID. Match the release by name. 11. CRITICAL: For releaseCycleMapping.buildID - Call API 'Cycle/List' (or use project info projects[].releases[].builds[].buildID), from the response get value from data[].buildID or projects[].releases[].builds[].buildID. Match the build/cycle by name. 12. If the user provides a release name, map it to its ID from projects[].releases[].releaseID in the project info response, and use that ID as releaseId in releaseCycleMapping. 13. If the user provides a build/cycle name, map it to its ID from projects[].releases[].builds[].buildID in the project info response, and use that ID as buildID in releaseCycleMapping. 14. Example payload: releaseCycleMapping: [ { releaseId: , buildID: } ] 15. Example: For 'Air' release and 'Air Q1-19' cycle in MAC project, use releaseId: 10286 and buildID: 18411 16. LLM should ensure that provided release/cycle names or IDs exist in the current project before using them in the payload. If not found, skip and show a user-friendly message: 'Test suite created without release/cycle association, as given release/cycle is not available in the current project.' 17. All IDs (testSuiteState from customListObjs.testSuiteState[index].id, testsuiteOwner from customListObjs.owner[index].id, releaseId from projects.releases[index].releaseID, buildID from projects.releases.builds[index].buildID) must be valid for your QMetry instance. 18. If a custom field is mandatory, include it in the UDF object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
descriptionNo
parentFolderIdNoTest Suite parent folder ID - 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 target a specific sub-folder.
testSuiteStateNo
testsuiteOwnerNo
associateRelCycNo
isAutomatedFlagNo
releaseCycleMappingNo
Behavior5/5

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

The description thoroughly discloses behavioral traits: automatic resolution of parentFolderId, need to call external APIs for IDs, handling of missing owners/states with user-friendly messages, and the optionality of release/cycle mapping. Annotations are minimal, so the description carries full burden and meets it excellently.

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 well-structured with clear sections (Toolset, Parameters, Use Cases, Examples, Hints), but it is overly verbose, especially in the Hints section where some points repeat information from earlier sections. Despite this, the structure aids readability and the verbosity is justified by the parameter complexity.

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 tool's complexity (8 parameters, external dependencies for IDs, optional release/cycle mapping), the description is comprehensive. It covers all parameters, provides multiple examples, and explains expected outputs despite no output schema. All use cases are addressed.

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?

Only 13% of parameters have schema descriptions, but the description compensates fully by explaining each parameter's role, how to obtain valid values (e.g., using customListObjs for testsuiteOwner), and when to omit fields. This goes far beyond what the schema provides.

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 'Create a new test suite in QMetry' with a specific verb and resource. It implicitly distinguishes from sibling tools like update_test_suite by focusing on creation, and mentions metadata and release/cycle mapping, leaving no ambiguity about the tool's action.

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 a dedicated 'Use Cases' section listing seven scenarios, and the 'Hints' section gives detailed prerequisites (e.g., calling FETCH_PROJECT_INFO) and fallback behaviors. However, it does not explicitly contrast with alternative tools like update or fetch, relying on the tool's name and purpose for differentiation.

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