MCP Server and Quality Assurance
- A connected AI assistant can now build a complete set of QA records on its own. Previously it could create a test case but not give it any steps, create a user story but not attach acceptance criteria, and create a test cycle but not put anything in it, so every record made this way had to be finished by hand in the console.
- Test steps can now be listed, added, edited, reordered, duplicated, and deleted, and a test case can be created with all of its steps in a single request.
- Acceptance criteria can be supplied when a user story is created or updated, and each criterion comes back with its own identifier and its coverage, so an assistant can link a test and then confirm the link took effect.
- Tests can be linked to a user story or to one individual acceptance criterion, in both directions. Linking at the criterion rather than the story is what makes partial coverage visible in the traceability matrix, and it is the practice we recommend.
- Cycles can now be populated. Adding test cases creates the test runs, a cycle can be cloned, and its progress can be read back. Each run accepts an environment and a priority, Pass, Fail, and Blocked results for every step, comments, and links to any defects it uncovered.
- Adding test cases to a cycle now takes an optional environment that is applied to every test run it creates. This works the same way through the API as it does over MCP, so a cycle no longer has to be set up one run at a time. Existing integrations, including the console, are unaffected.
- Test case folders and test cycle folders can now be read as a tree, created, renamed, moved, and deleted, so records created this way can be filed rather than piling up unfiled. Deleting a folder that still holds records or subfolders is refused unless you explicitly ask for it, and when you do the records move to the top level instead of being deleted along with it.
- Fixed the MCP test cycle tool accepting three settings and then quietly ignoring them. An environment, a planned start date, and a planned end date were all accepted, the response reported success, and none of the three was stored, so a cycle looked correctly set up when it was not. A misnamed setting is now refused with the list of the ones that are accepted, and cycle dates and the folder are stored as asked. An environment belongs to an individual test run rather than to the cycle, so that is where it is now set.
- Fixed the same fault in the test environment tool, which advertised a browser, an operating system, and a device, none of which exist, while leaving out whether the environment is active.
Security
- Custom object types are now strictly separated between accounts. One part of the custom objects area took the account to work with from the request instead of from your signed-in session, so a signed-in user could have read the field definitions of another account’s custom object types, or added a new object type into another account. Every part of that area now uses your own account, taken from your session, and ignores anything sent in the request. No entry data was reachable this way, and nothing changes about how custom objects work for you. Reported to us externally with a clear, reproducible proof of concept.