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://testma...
Single-target operation; Admin/system-level operation
Part of the SmartBear MCP MCP server. Enforce policies on this tool with Intercept, the open-source MCP proxy.
AI agents use qmetry_create_cycle to create or modify resources in SmartBear MCP. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.
Without a policy, an AI agent could call qmetry_create_cycle repeatedly, creating or modifying resources faster than any human could review. Intercept's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach SmartBear MCP.
Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.
tools:
qmetry_create_cycle:
rules:
- action: allow
rate_limit:
max: 30
window: 60 See the full SmartBear MCP policy for all 147 tools.
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.
Add a rule in your Intercept YAML policy under the tools section for qmetry_create_cycle. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the SmartBear MCP MCP server.
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 Intercept 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 Intercept 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 MCP server (@smartbear/mcp). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Open source. One binary. Zero dependencies.
npx -y @policylayer/intercept