qmetry_create_cycle

Create a new cycle within an existing release in QMetry for test execution planning 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) (default: "https://testmanagement.qmetry.com") - 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 json { "cycle": { "name": "Sprint 2", "releaseID": 12345 } } Expected Output: Cycle 'Sprint 2' created successfully in release ID 12345 2. Create a cycle with description and dates json { "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 3. Create a locked cycle to prevent modifications json { "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 4. Create a cycle with all details including project ID and dates json { "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[<index>].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[<index>].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. It is categorised as a Write tool in the SmartBear MCP MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

qmetry_create_cycle accepts 3 parameters: cycle, baseUrl, projectKey. Required: cycle. The full parameter table on this page comes from the server's own tool schema.

Register the SmartBear MCP server in PolicyLayer and add a rule for qmetry_create_cycle: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches SmartBear MCP. Nothing to install.

qmetry_create_cycle is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Yes. Add a rate_limit block to the qmetry_create_cycle rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for qmetry_create_cycle. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

qmetry_create_cycle is provided by the SmartBear MCP server (SmartBear/smartbear-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.