Skip to main content
Glama

clone_test_case

Copy a test case in its own project using its source key, duplicating fields and optionally the script. The folder must exist; returns the new key and URL.

Instructions

Copy a test case inside its own project (GET /testcase/{testCaseKey}, then POST /testcase). Copies name, objective, precondition, folder, status, priority, component, owner, estimatedTime, labels, custom fields, parameters and — unless includeScript is false — the script; step ids are dropped so the copy owns its steps. Issue links, attachments and execution history are NOT copied. name defaults to " (copy)" and folder to the source folder. The folder MUST already exist — the API never creates folders implicitly (use create_folder first). A test case name is limited to 255 CHARACTERS, not bytes (the API rejects a longer one with an opaque HTTP 500): an explicit longer name is refused locally before any request, and the default name is shortened to fit — the copied source name is cut on a whole-character boundary (an astral character is dropped rather than split), the " (copy)" marker is kept, and note reports both lengths. An explicitly empty name ("") is sent as-is and rejected with 400 "The field name is required." — omit the parameter to get the default. Names are not deduplicated: cloning twice gives two cases with the same name, and cloning a copy gives "… (copy) (copy)" — unless the source name is already at the limit, where the shortening cuts exactly the previous " (copy)" off and the copy ends up named identically to its source (note says so; pass an explicit name to tell them apart). With includeScript=false the copy has no steps, but the API still reports an empty PLAIN_TEXT testScript — that is what every script-less case looks like here. Returns { key, url, sourceKey, note? }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of the copy, at most 255 characters (defaults to "<source name> (copy)", shortened to fit)
folderNoFolder path for the copy, full path from the root starting with "/" (defaults to the source folder)
testCaseKeyYesKey of the SOURCE test case, e.g. PROJ-T123
includeScriptNoCopy the test script too (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.5

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers: what is copied vs. explicitly NOT copied (issue links, attachments, execution history), the folder-must-exist precondition, the 255-character failure mode and its local pre-check, the 400 on empty name, and non-deduplication semantics. This is exactly the destructive/mutation context an agent needs absent annotation hints.

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?

Purpose is front-loaded and the copy/no-copy inventory is efficient, but the name-limit passage runs long with multiple parentheticals covering astral-character boundaries, repeated '(copy)' markers, and the note field. The information is genuinely useful for edge cases, yet it is denser than a reader needs on first pass.

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?

There is no output schema, and the description compensates by stating the return shape: '{ key, url, sourceKey, note? }'. Combined with the copy semantics and failure modes, an agent has everything needed to invoke and interpret the result.

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 the baseline is 3, but the description adds substantial meaning beyond the schema: includeScript=false yields a copy with no steps plus a spurious empty PLAIN_TEXT testScript, name defaulting and shortening behavior, the step-id-dropping rule, and the empty-string edge case. This goes well past restating field definitions.

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?

Opening clause gives a precise verb+resource+scope: 'Copy a test case inside its own project,' immediately distinguishing it from create_test_case (new case) and get_test_case (read). The description also enumerates exactly which fields travel with the copy, so an agent knows what the resulting artifact is.

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?

Prerequisites and alternatives are explicit where it matters: 'The folder MUST already exist — the API never creates folders implicitly (use create_folder first)' names the sibling to call first. It also states the when-not implicitly via 'inside its own project,' but never spells out a cross-project alternative, so it stops short of full alternative routing.

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