report_case_result
Record per-step pass/fail and case status for a manual test execution, updating group status and execution progress automatically.
Instructions
Record the result of running one case inside a Manual Test Execution: set per-step pass/fail and/or the case status, atomically and idempotently. Target the case by executionCaseId (from get_execution_cases) OR by executionId + caseId (numeric; if the case is in several groups, pass groupId or use executionCaseId). A Test Collection is NOT an Execution, and the trap has a name: the per-case rows get_test_collection returns carry a field called executionId, which is the id of the row inside that Collection and is rejected here with Execution case not found. To record results against a Collection, add it to an Execution with add_collections_to_execution and use the rows get_execution_cases gives you. status: an explicit value (passed/failed/blocked/in_testing/not_executed), or "auto" to derive it from the steps (failed then blocked then in_testing then passed), or omit it to leave the case status unchanged (e.g. when only writing one step). steps[].status is one of not_executed/passed/failed/blocked/skipped; index is the 0-based position in the case steps. The containing source group's status auto-rolls from its cases' results, where EXECUTED means anything other than not_executed - so a case parked in_testing counts as executed, and the same is true of the completionRate get_execution reports. A group whose every case is in_testing therefore reads completed, and the execution reads 100 percent complete, while the work is still going on. The rule: all not_executed -> not_started, some executed -> in_progress, all executed -> blocked if the group contains a blocked case, else completed (test_run_status has no failed; failures show via the group's counters). An explicit set_execution_source_status override lasts until the next report on that group recomputes it. The status of the EXECUTION itself does not roll at all: it stays wherever it was until you move it with update_execution, so an execution whose cases have all been run can still read not_executed. Returns the case status, the group status, the steps written, and fresh execution progress.
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "report_case_result"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional free-text notes for the case run | |
| steps | No | Per-step results to upsert. | |
| caseId | No | Alternative to executionCaseId: the numeric case id (with executionId). | |
| status | No | Case status from the project vocabulary, typically not_executed, in_testing, passed, failed or blocked, plus any the project added; call get_project for the list it uses. Pass "auto" to derive it from the step results, or omit to leave the status unchanged. The per-step status inside steps[] is a different and fixed vocabulary. | |
| groupId | No | Optional: disambiguate when the case is in several source groups. | |
| causedBy | No | Optional: which step or thing caused failure | |
| executionId | No | Alternative to executionCaseId: the execution UUID (with caseId). | |
| durationMinutes | No | Optional: time spent, in minutes | |
| executionCaseId | No | The case-run row UUID (from get_execution_cases). Preferred. |