Skip to main content
Glama
Sign In
BoomBidiBuyBuy

tuskr-mcp-server

by BoomBidiBuyBuy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Update Test Run

update_test_run

Modify an existing test run by adding or removing test cases and switching between ALL and SPECIFIC case selection; use the full case ID list to replace the run's current selection.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
nameNonew name for the run. Leave unset to keep the current name.
projectNoID (UUID) of the project the run belongs to. Leave unset to keep the run in its current project.
test_runYesID (UUID) of the test run to update. list_test_runs returns it.
test_casesNofor 'SPECIFIC', the IDs (UUIDs) of every case the run should hold afterwards: a single ID or a list of them.
test_case_inclusion_typeYes'ALL' or 'SPECIFIC' (case-insensitive). With 'ALL' the run holds every case in the project and test_cases must be omitted. With 'SPECIFIC' test_cases is required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so thoroughly: test_cases replaces rather than appends, omitted cases are removed, cases with existing results cannot be removed, the exact HTTP 400 error behavior is disclosed, identifiers must be UUIDs, and the tool does not modify description, deadline, or assignee. This is unusually complete for a mutation tool without annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but the length is justified by the complexity of a mutation tool with no annotations and five parameters. The core behavior and alternatives are front-loaded, and the procedural details are information-dense rather than repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity, lack of annotations, and lack of an output schema, the description covers everything an agent needs to invoke the tool correctly: selection semantics, UUID constraints, error behavior, switching rules, unchanged fields, and a brief success return statement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds critical meaning beyond the schema: test_cases is the complete selection rather than a delta, switching between ALL and SPECIFIC has different parameter requirements, and every identifier is a UUID rather than a key or name. These are high-value semantics that the schema descriptions alone do not fully convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: it adds and removes test cases in an existing test run and switches the run's case selection mode. It explicitly distinguishes itself from sibling tools such as add_test_run_results and copy_test_run, so an agent can identify the correct tool without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance, including negative guidance not to use add_test_run_results or copy_test_run for this purpose. It also provides step-by-step procedures for adding and removing cases and states exactly when test_cases is required versus omitted for ALL and SPECIFIC modes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools