Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Create Cycle

qmetry_create_cycle

Create a new test cycle in an existing release to organize testing by sprints, phases, or iterations. Provide a cycle name and release ID to enable test execution planning.

Instructions

Create a new cycle within an existing release in QMetry for test execution planning

Toolset: Projects

Parameters:

  • projectKey (string): Project key - unique identifier for the project (default: "default")

  • cycle (object) required

Output Description: JSON object containing the created cycle ID, cycle details, and association with the release

Use Cases: 1. Create a new test cycle for a sprint within an existing release 2. Add additional testing phases to an existing release 3. Set up regression testing cycles for a specific release 4. Organize test execution by sprints, phases, or iterations 5. Create cycles with specific date ranges for milestone tracking 6. Establish test execution phases within release planning

Examples:

  1. Create a basic cycle with just a name in a release

{
  "cycle": {
    "name": "Sprint 2",
    "releaseID": 12345
  }
}

Expected Output: Cycle 'Sprint 2' created successfully in release ID 12345

  1. Create a cycle with description and dates

{
  "cycle": {
    "name": "Regression Testing Cycle",
    "description": "Full regression testing for release 2.0",
    "startDate": "15-01-2024",
    "targetDate": "31-01-2024",
    "releaseID": 12345
  }
}

Expected Output: Cycle 'Regression Testing Cycle' created with start date 15-01-2024 and target date 31-01-2024 in release 12345

  1. Create a locked cycle to prevent modifications

{
  "cycle": {
    "name": "Final QA Cycle",
    "description": "Locked cycle for final QA testing",
    "isLocked": true,
    "isArchived": false,
    "releaseID": 12345
  }
}

Expected Output: Locked cycle 'Final QA Cycle' created in release 12345 to prevent modifications

  1. Create a cycle with all details including project ID and dates

{
  "cycle": {
    "name": "Sprint 3 - Feature Testing",
    "description": "Testing new features for Sprint 3",
    "startDate": "01-02-2024",
    "targetDate": "15-02-2024",
    "isLocked": false,
    "isArchived": false,
    "projectID": 67890,
    "releaseID": 12345
  }
}

Expected Output: Cycle 'Sprint 3 - Feature Testing' created with dates and project context in release 12345

Hints: 1. CRITICAL: cycle.releaseID is REQUIRED - must provide the release ID to associate this cycle with 2. CRITICAL: cycle.name is REQUIRED - must provide a name for the cycle 3. HOW TO GET releaseID: 4. 1. Call FETCH_RELEASES_CYCLES tool to get all releases and their IDs 5. 2. From the response, get value from projects.releases[].releaseID 6. 3. Use that numeric releaseID in the cycle.releaseID parameter 7. Example: Release 'Q1 2024' might have releaseID: 12345 8. CRITICAL WORKFLOW - IF USER PROVIDES RELEASE NAME: 9. 1. User says: 'Create cycle Sprint 2 in release Q1 2024' 10. 2. You MUST first call FETCH_RELEASES_CYCLES tool to get all releases 11. 3. Search the response for release with name 'Q1 2024' 12. 4. Extract projects.releases[].releaseID from matching release 13. 5. Use that releaseID in cycle.releaseID parameter 14. 6. If release name not found, inform user and list available releases 15. Example workflow: 16. - User request: 'Create cycle Sprint 2 in Release 2.0' 17. - Step 1: Call FETCH_RELEASES_CYCLES 18. - Step 2: Find release where name = 'Release 2.0', get its releaseID (e.g., 12345) 19. - Step 3: Call CREATE_CYCLE with cycle.releaseID = 12345 20. RELEASE NAME RESOLUTION: 21. - NEVER assume or guess release IDs - always fetch from API 22. - Release names are user-defined strings (e.g., 'Q1 2024', 'Release 2.0', 'Sprint 15') 23. - Release IDs are numeric identifiers assigned by QMetry (e.g., 12345, 67890) 24. - Match release names case-insensitively when searching 25. - If multiple releases match the name, ask user to clarify or use the most recent one 26. - FETCH_RELEASES_CYCLES returns: projects.releases[] array with name and releaseID fields 27. Date format depends on QMetry instance configuration: DD-MM-YYYY or MM-DD-YYYY 28. Check your QMetry instance settings to determine the correct date format 29. If dates are in wrong format, QMetry will return an error - verify format with admin 30. projectID is optional in the cycle object - it will be auto-resolved from the project key if not provided 31. To explicitly set projectID, first call FETCH_PROJECT_INFO to get the numeric project ID 32. cycle.isLocked defaults to false if not provided - set to true to prevent modifications 33. cycle.isArchived defaults to false if not provided - set to true to archive immediately (rare) 34. Use descriptive cycle names like 'Sprint 2', 'Regression Cycle', 'Alpha Testing' for better organization 35. startDate and targetDate help with sprint planning and milestone tracking 36. Cycle hierarchy: Project → Release → Cycle → Test Execution 37. After creating a cycle, you can associate test suites and test cases with it 38. Use FETCH_RELEASES_CYCLES tool after creation to verify the cycle was created successfully 39. DIFFERENCE FROM CREATE_RELEASE: This tool creates a cycle in an EXISTING release, while CREATE_RELEASE can create a release with an optional cycle 40. If you need to create both a release and a cycle together, use CREATE_RELEASE tool instead 41. If release doesn't exist yet, create it first with CREATE_RELEASE, then add more cycles with this tool

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cycleYes
projectKeyNoProject key - unique identifier for the projectdefault
Install Server

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only indicate a non-readonly, non-destructive write. The description adds critical behavioral context: releaseID and name are required, date format depends on instance configuration, isLocked/isArchived defaults, projectID auto-resolution, and verification via FETCH_RELEASES_CYCLES. No contradiction with annotations.

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 definition is well-structured with headings, examples, and numbered hints, but is verbose and repetitious: the release-name resolution workflow is restated multiple times. It could be edited down without losing information.

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 nested-object creation tool with no output schema, the description covers required fields, ID resolution workflow, date format pitfalls, defaults, output shape, and sibling-tool routing. An agent has enough context to invoke it correctly in realistic release/cycle workflows.

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?

The description compensates for the schema's missing top-level cycle documentation with detailed examples and hints on resolving releaseID, auto-resolving projectID, and applying defaults. However, examples and hints use fields (description, isLocked, isArchived) that are absent from the input schema, which could confuse strict schema-validating agents.

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 opening sentence states a specific action and resource: 'Create a new cycle within an existing release in QMetry'. It is distinguished from the sibling CREATE_RELEASE tool in the hints, so the agent can immediately identify the operation.

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?

Use cases enumerate concrete scenarios, and hints explicitly say when to prefer CREATE_RELEASE, when to create the release first, and when to call FETCH_RELEASES_CYCLES to resolve a release name. This is explicit when/when-not guidance with named alternatives.

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