Skip to main content
Glama
mungowang

jira-mcp

by mungowang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

set_test_script

DestructiveIdempotent

Replace a Zephyr Scale test case's full script or switch its format; missing steps are deleted and the stored write is read back.

Instructions

Replace a test case's whole script or change its format (PUT /testcase/{testCaseKey} with a full testScript). DESTRUCTIVE: switching STEP_BY_STEP to PLAIN_TEXT or BDD irreversibly deletes all steps, and a STEP_BY_STEP replacement deletes every stored step whose id is absent from steps. text is required for PLAIN_TEXT and BDD, steps for STEP_BY_STEP — the pairing is validated locally, before any request — but steps: [] passes that check and DELETES every stored step, leaving an empty STEP_BY_STEP script. BDD text is stored verbatim and must contain Gherkin step lines only, no "Feature:"/"Scenario:" header (400 "Invalid BDD Script"). A step whose "Call to Test" points at its own case is refused locally: the API answers 2xx to such a write and stores NOTHING. After the write the tool reads the case back (a second GET) and compares the STORED script with the one sent — its type, the step count for STEP_BY_STEP, and that a non-empty text survived for PLAIN_TEXT/BDD (the text itself is not compared byte-for-byte). Returns { key, url }; when the stand accepted the write and kept the old script, the answer also carries storedType, storedSteps and a warning saying what is really stored, and a warning alone when the read-back itself failed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoScript body — required for PLAIN_TEXT and BDD (Gherkin step lines only), rejected for STEP_BY_STEP
typeYesNew script format: STEP_BY_STEP, PLAIN_TEXT or BDD
stepsNoComplete final list of steps — required for STEP_BY_STEP, rejected otherwise. Steps omitted here are deleted; keep the ids from get_test_case to update steps in place.
testCaseKeyYesTest case key, e.g. PROJ-T123

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.5

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the destructiveHint/idempotentHint annotations: it specifies what is irreversibly deleted, the local validation ordering, the API's silent 2xx-and-store-nothing behavior on self-referencing steps, the BDD verbatim/Gherkin-only constraint, and the read-back verification with its partial-comparison caveat. This is unusually rich operational disclosure.

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 purpose and the DESTRUCTIVE warning, and every sentence carries a distinct edge case. It is dense and long, and a few clauses (e.g. the byte-for-byte caveat wording) could be tightened, but little is truly wasted.

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?

No output schema exists, so the description carries the return contract — { key, url } plus the storedType/storedSteps/warning variants when the write is ignored or read-back fails. For a complex, destructive, no-output-schema tool this is complete enough to call correctly.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description adds real semantics beyond it: the text/steps ↔ type pairing, that steps: [] passes local validation yet wipes all steps, and the exact scope of what is compared on read-back. It doesn't fully document every step sub-field, hence not a 5.

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?

States a precise verb+resource ('Replace a test case's whole script or change its format') and even names the underlying call (PUT /testcase/{testCaseKey} with a full testScript). This clearly separates it from siblings like add_test_steps (incremental) and update_test_case (metadata), so an agent can route without opening the schema.

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

Usage Guidelines4/5

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

It gives strong context for when to use it — full script replacement, and the destructive conditions (STEP_BY_STEP→PLAIN_TEXT/BDD, steps: [] deletion, self-referencing Call to Test). However it never explicitly names the alternative tools (add_test_steps, update_test_case) to route the agent, leaving that inference to the reader.

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