Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

QMetry: Create Cycle

qmetry_create_cycle

Create new test cycles within QMetry releases to organize test execution by sprint, phase, or iteration.

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")

  • baseUrl (string): The base URL for the QMetry instance (must be a valid URL)

  • 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
baseUrlNoThe base URL for the QMetry instance (must be a valid URL)
projectKeyNoProject key - unique identifier for the projectdefault
Behavior4/5

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

Annotations are minimal (readOnlyHint=false, etc.), so the description carries the burden. It discloses that the tool creates a cycle mutation, requires releaseID, uses date formats dependent on instance config, and supports locking/archiving. No contradictions with annotations. Could mention idempotency or effects on other entities.

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 well-structured with sections (Toolset, Parameters, Output, Use Cases, Examples, Hints) but is overly verbose, especially the Hints section which repeats information and has 40 numbered points. Could be more concise while preserving key 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?

Given the complexity (hierarchy, dependencies, multiple optional fields), the description covers all necessary aspects: prerequisites, workflow for release ID resolution, date format warning, differentiation from other tools, and expected output format. No output schema exists, but output description suffices.

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 input schema already has descriptions for all parameters (67% coverage according to context, but actually all have descriptions). The description adds extra context: explains that releaseID is required, how to get it from FETCH_RELEASES_CYCLES, date format caveats, and optionality of projectID and baseUrl.

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 cycle within an existing release' with a specific verb (create) and resource (cycle), and distinguishes from sibling tools like qmetry_create_release by explicitly noting that this tool creates a cycle in an EXISTING release, not a release with cycle.

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 provides extensive usage guidance, including when to use (e.g., 'Create a new test cycle for a sprint within an existing release'), when not to use (hint #40-41 suggest using CREATE_RELEASE for combined release+cycle creation), a workflow for resolving release names, and explicit prerequisites (release must exist).

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