qmetry_create_test_case

Create a new test case in QMetry with steps, metadata, and release/cycle mapping. Parameters: - tcFolderID (string) *required* - steps (array) - name (string) *required* - priority (number) - component (array) - testcaseOwner (number) - testCaseState (number) - testCaseType (number) - estimatedTime (number) - testingType (number) - description (string) - associateRelCyc (boolean) - releaseCycleMapping (array) Output Description: JSON object containing the new test case ID, summary, and creation metadata. Use Cases: 1. Create a basic test case with just a name and folder 2. Add detailed steps with custom fields (UDFs) to a test case 3. Associate test case with specific release/cycle for planning 4. Set priority, owner, component, and other metadata using valid IDs from project info 5. Create test cases for automation or manual testing types 6. Add test case to a specific folder using tcFolderID 7. Include estimated execution time and description 8. Map test case to multiple cycles/releases Examples: 1. Create a test case in the root folder (auto-resolved) json { "name": "Login Test Case" } Expected Output: Test case created in the root test case folder with ID and summary details 2. Create a simple test case in folder 102653 json { "tcFolderID": "102653", "name": "Login Test Case" } Expected Output: Test case created with ID and summary details 3. Create a test case with steps and metadata json { "tcFolderID": "102653", "name": "Test Case 1", "steps": [ { "orderId": 1, "description": "First Step", "inputData": "First Data", "expectedOutcome": "First Outcome", "UDF": { "customField1": "Custom Field Data A", "customField2": "Custom Field Data B" } } ], "priority": 2025268, "component": [ 2025328 ], "testcaseOwner": 1467, "testCaseState": 2025271, "testCaseType": 2025282, "estimatedTime": 10, "description": "Description", "testingType": 2025275, "associateRelCyc": true, "releaseCycleMapping": [ { "release": 14239, "cycle": [ 21395 ], "version": 1 } ] } Expected Output: Test case created with steps and metadata Hints: 1. If tcFolderID is not provided, it will be auto-resolved to the root test case folder using project info (rootFolders.TC.id). 2. To get valid values for priority, owner, component, etc., call the project info tool and use the returned customListObjs IDs. 3. If the user provides a priority name (e.g. 'Blocker'), fetch project info, find the matching priority in customListObjs.priority[index].name, and use its ID in the payload. If the name is not found, skip the priority field (it is not required) and show a user-friendly message: 'Test case created without priority, as given priority is not available in the current project.' 4. If the user provides a component name, fetch project info, find the matching component in customListObjs.component[index].name, and use its ID in the payload. If the name is not found, skip the component field (it is not required) and show a user-friendly message: 'Test case created without component, as given component is not available in the current project.' 5. If the user provides an owner name, fetch project info, find the matching owner in customListObjs.owner[index].name, and use its ID in the payload as testcaseOwner. If the name is not found, skip the testcaseOwner field (it is not required) and show a user-friendly message: 'Test case created without owner, as given owner is not available in the current project.' 6. If the user provides a test case state name, fetch project info, find the matching state in customListObjs.testCaseState[index].name, and use its ID in the payload as testCaseState. If the name is not found, skip the testCaseState field (it is not required) and show a user-friendly message: 'Test case created without test case state, as given state is not available in the current project.' 7. If the user provides a test case type name, fetch project info, find the matching type in customListObjs.testCaseType[index].name, and use its ID in the payload as testCaseType. If the name is not found, skip the testCaseType field (it is not required) and show a user-friendly message: 'Test case created without test case type, as given type is not available in the current project.' 8. If the user provides a testing type name, fetch project info, find the matching type in customListObjs.testingType[index].name, and use its ID in the payload as testingType. If the name is not found, skip the testingType field (it is not required) and show a user-friendly message: 'Test case created without testing type, as given testing type is not available in the current project.' 9. Example: If user says 'Create test case with title "High priority test case" and set priority to "Blocker"', first call project info, map 'Blocker' to its ID, and use that ID for the priority field in the create payload. If user says 'set priority to "Urgent"' and 'Urgent' is not found, skip the priority field and show: 'Test case created without priority, as given priority is not available in the current project.' 10. tcFolderID is required; use the root folder ID from project info or a specific folder. 11. Steps are optional but recommended for manual test cases. 12. If the user provides a prompt like 'create test case with steps as step 1 - Go to login page, step 2 - give credential, step 3 - go to test case page, step 4 - create test case', LLM should parse each step and convert it into the steps payload array, mapping each step to an object with orderId, description, and optionally inputData and expectedOutcome. 13. Example mapping: 'step 1 - Go to login page' → { orderId: 1, description: 'Go to login page' }. 14. LLM should increment orderId for each step, use the step text as description, and optionally infer inputData/expectedOutcome if provided in the prompt. 15. Demo steps payload: steps: [ { orderId: 1, description: 'First Step', inputData: 'First Data', expectedOutcome: 'First Outcome', UDF: { customField1: 'Custom Field Data A', customField2: 'Custom Field Data B' } }, ... ] 16. UDF fields in steps must match your QMetry custom field configuration. 17. Release/cycle mapping is optional but useful for planning. 18. If the user wants to link or associate a release and cycle to the test case, set associateRelCyc: true in the payload. 19. If the user provides a release ID, map it from projects.releases[index].releaseID in the project info response, and use that ID in releaseCycleMapping. 20. If the user provides both release and cycle IDs, validate both against the current project's releases and cycles; if valid, use them in releaseCycleMapping. 21. When adding releaseCycleMapping, always include the 'version' field (usually set to 1) in each mapping object. The correct format is: { release: <releaseID>, cycle: [<cycleID>], version: 1 }. If 'version' is missing, the request will fail. 22. If the user provides a release name, map it to its ID from project info; if a cycle name is provided, map it to its ID from the associated release's builds list. 23. Example payload: releaseCycleMapping: [ { release: <releaseID>, cycle: [<cycleID>], version: 1 } ] 24. 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 case created without release/cycle association, as given release/cycle is not available in the current project.' 25. All IDs (priority, owner, etc.) must be valid for your QMetry instance. 26. If a custom field is mandatory, include it in the UDF object. 27. Estimated time is in minutes. 28. Description and testingType are optional but recommended for clarity. 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_test_case accepts 12 parameters: name, steps, priority, component, tcFolderID, description, testingType, testCaseType, estimatedTime, testCaseState, testcaseOwner, associateRelCyc. Required: name, tcFolderID. 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_test_case: 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_test_case 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_test_case 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_test_case. 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_test_case 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.