Creates a new test case in a project and returns it.

The test suite and section must already exist: this tool does not create them. There is no delete endpoint for test cases in the Tuskr API, so use a sandbox project while experimenting and name throwaway cases clearly.

Pass test_case_type as well: Tuskr rejects a create without one with "Type is required", at least on a tenant with no default type. Find a type's ID on the testCaseTypeId field of any list_test_cases row.

Records a result against one or more test cases in a test run.

Tuskr exposes a single bulk endpoint for results, so one call applies the same status to every test case listed. Pass a single test case to record one result, or a list to record many in one request. Always prefer one call with a list over repeated single calls: Tuskr rate-limits every plan at 10 requests/second.

Archives one or more test runs.

Archiving hides a run from the default test-run list without deleting it. Archived runs remain readable: pass filter_status='archived' to list_test_runs to see them, or filter_status='active' to exclude them.

The endpoint is bulk. Reversing an archive is not exposed as a dedicated API action: Tuskr's own UI does it by sending the run's full object back with status changed to "active", which this server does not wrap yet. Restoring an archived run today means using the Tuskr UI.

The response is a bare boolean, not a run snapshot. Confirming the new status on a specific run needs a follow-up list_test_runs call with filter_status set.

Exports test runs of a project together with their test cases and the latest result of each case, in one call.

One call can return several runs, where get_test_run_results needs a call per run and per page. Always narrow the export with filter_ids or the other filters when test cases are included: a project's runs with all their cases run to tens of megabytes. A response over the MCP size limit is replaced by an error saying how large it was and how to narrow it.

Run fields and the response envelope ({count, rows, meta}) are passed through as the API sends them, keys in the API's own capitalisation.

Creates a copy of an existing test run along with its test cases.

The copy is created in the same project as the source run: this endpoint takes no project parameter, so a run cannot be copied across projects. The case selection is carried over in full and cannot be narrowed here; use create_test_run when a different selection is needed. Results are not carried over: every case in the copy starts UNTESTED even if the source run had recorded results (verified live against a sandbox project).

Every optional argument below overrides the corresponding attribute on the copy. Leaving one unset keeps the source run's own value rather than clearing it.

Creates a new test run in a project.

Fetches a test run's details, including when execution started and ended.

Besides the run's metadata (id, key, name, project, description, references, assignedTo, externalId, deadline, status), the response carries three timing fields:

• firstResultAt: timestamp of the first result marked in the run

• lastResultAt: timestamp of the last result marked in the run

• durationInMinutes: time between the two, computed by Tuskr

This is the direct way to answer "when did this run finish" or "how long did execution take". Deriving the same from each case's resultHistory via get_test_run_results is slower and needs one large call per run.

Caveat: Tuskr says it timestamps only results marked after this endpoint shipped (8 Sept 2026), so older runs may return null firstResultAt and lastResultAt with a meaningless durationInMinutes. This is not guaranteed: a run whose only result predates the release still returned real timestamps. A run with no results also returns nulls. A null therefore means unknown, not "no results yet"; check the run's results before concluding that.

The endpoint takes one test run per call. Tuskr rate-limits every plan at 10 requests/second.

Fetches the test cases in a test run together with their latest result.

The main use is confirmation testing: pass status='FAILED' to get back only the test cases that need re-checking after a fix.

Reports when testing in a test run actually started and finished.

Use this instead of comparing a run's createdAt to its lockedAt. Those two bracket the run's administrative life, not its testing: a run is typically opened before anyone executes against it and locked well after the last result, so the gap between them can be twice the real duration.

This reads the per-execution timestamps Tuskr keeps on each test case and keeps only those recorded against this run, giving the true first and last execution, the span between them, and how many distinct days saw activity.

For a recent run, get_test_run_details is the cheaper way to get the first and last result times and the duration: one small call, where this tool fetches every results page untrimmed (100 cases per page). Use this tool when those timestamps come back null (Tuskr may not have recorded them for older results), or when you need the number of distinct days with activity, the daily breakdown, or the cases that were never executed.

Retrives list of projects based on various filter criteria.

Retrieves list of test cases of a project with support for various filters.

Use this to discover the test case keys a project actually contains before recording results against them with add_test_run_results.

Retrieves list of test runs of a project with support for various filters.

Retrieves list of test suites and their associated sections in a project.

Use this to discover suite and section IDs. Pass them to list_test_cases as filter_test_suite and filter_test_suite_section instead of reading the IDs off existing test case rows.

Each suite row embeds its sections. Returns Tuskr's raw rows, count and meta for a single page; this tool does not fetch further pages.

Locks or unlocks a test run.

A locked test run is read-only: results can no longer be recorded against it and its test cases can no longer be edited. Locking is otherwise a manual action in the Tuskr UI, so this tool is what lets an automated workflow seal a run once execution is complete.

The endpoint accepts one test run per call, so locking several runs takes one call each. Tuskr rate-limits every plan at 10 requests/second.

Adds test cases to an existing test run and removes test cases from it.

This is how to change which cases a run contains after it was created. It also switches a run between ALL and SPECIFIC case selection. Do not use add_test_run_results to add a case: recording a result for a case that is not in the run returns an empty list and stores nothing. Do not use copy_test_run either, which resets every result.

To add a case: read the run's current case IDs with get_test_run_results (the testCase.id of each row), append the new case's ID (the id of a list_test_cases row), and send the full list as test_cases.

To remove a case: send the run's current case IDs without that case. A case that already has a result in this run cannot be removed. Tuskr then answers HTTP 400 "Cannot remove test case because it already has results: ", and this tool returns that text as is.

test_cases is the complete selection, not a delta: it replaces the current one, so any case left out is removed. Cases that stay in the selection keep the results already recorded for them, also across a switch to ALL and back.

Switching from SPECIFIC to ALL takes no test_cases. Switching from ALL to SPECIFIC needs test_cases to include every case that already has a result in the run.

Every identifier here is a UUID, unlike create_test_run: keys and names are not accepted for the run, the project or the cases. The tool never sends the run's description, deadline or assignee, and a description stays unchanged. On success Tuskr returns the updated run.

Creates a test case or updates an existing one, and returns it.

This tool can both create new test cases and modify existing ones. Exactly one of test_case_id or external_id must be given:

• test_case_id updates the test case with that ID; the case must already exist.

• external_id updates the case with that external ID in the project, or creates a new case carrying that external ID when none exists.

Only the fields you pass are sent. A field left unset keeps its current value on an update, so this tool cannot clear a field to empty. Pass name when the call may create a case.

Unlike add_test_case, this endpoint looks the suite and section up by NAME only: a suite or section ID is answered with "Test suite does not exist". With create_missing_suite or create_missing_section set, an ID passed by mistake would instead create a suite or section named after it. The test case type accepts an ID or a name.