Skip to main content
Glama
Sign In
BoomBidiBuyBuy

tuskr-mcp-server

by BoomBidiBuyBuy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Upsert Test Case

upsert_test_case

Create a new test case or update an existing one by test case ID or external ID, sending only the fields you want to change; provide a name when creation is possible.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
nameNoname of the test case
projectYesID, name or external ID of the project
test_suiteNoname of the test suite (not its ID)
descriptionNodescription of the test case
external_idNoexternal ID used to find the case to update, or to assign to the case being created
test_case_idNoUUID of an existing test case to update
custom_fieldsNoobject of custom field values, keyed by the field's key. Keys and value shapes are specific to the tenant and depend on the field type. Tuskr's own example uses `stepsWithExpectedResults`, a `multi_select` field and a `date` field.
test_case_typeNoID or name of the test case type
test_suite_sectionNoname of the section in the suite (not its ID)
create_missing_suiteNocreate the test suite when it does not exist (Tuskr default: it does not)
create_missing_sectionNocreate the section when it does not exist (Tuskr default: it does not)
estimated_time_in_minutesNoestimated execution time, whole minutes, at least 1. Tuskr rejects 0 ("Validation min on estimatedTimeInMinutes failed"), so 0 is rejected here first

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of it well: partial-update semantics ('only the fields you pass are sent'), the inability to clear a field to empty, and the surprising side effect where a mistakenly-passed suite ID plus create_missing_suite creates a new suite. Still silent on permissions/auth requirements and overall idempotency guarantees, which keeps it short of a 5.

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

Conciseness4/5

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

Front-loaded with the core operation, then bullets the ID modes, then the field-merge and suite-lookup caveats. Slight redundancy in 'This tool can both create new test cases and modify existing ones' restating the opening sentence, but density of useful content is high.

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

Completeness4/5

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

For a 12-parameter dual-mode mutation with no output schema, it covers the decision-critical semantics: mode selection, merge behavior, name-lookup pitfalls, and required name on create. It does not describe what the returned test case looks like or what error surfaces when both IDs are omitted, leaving minor gaps.

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 100%, so baseline would be 3, but the description adds genuine semantics the schema does not: the mutual-exclusivity/at-least-one constraint on test_case_id and external_id, which one creates vs updates, and the name-only lookup rule for suite and section that the schema flags only as '(not its ID)'.

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?

Opens with a specific verb+resource ('Creates a test case or updates an existing one') and immediately scopes the dual-mode behavior. It explicitly contrasts itself with the sibling add_test_case, so an agent can route between them without opening either 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?

Gives explicit selection rules for test_case_id vs external_id, states that name must be passed when a create may occur, and names add_test_case as the alternative for the ID-lookup path. The when-not guidance around create_missing_suite/section with mistaken IDs is exactly the kind of trap an agent needs warned about.

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