Skip to main content
Glama

create_test_cases_bulk

Create multiple Zephyr test cases in one request, each with its own fields, and report per-item failures when bulk creation falls back.

Instructions

Create several test cases in one request (POST /testcase/bulk). Each item takes the same fields as create_test_case; an item without its own projectKey uses the shared projectKey, then ZEPHYR_DEFAULT_PROJECT_KEY. The folder MUST already exist — the API never creates folders implicitly (use create_folder first). Some Server builds ship a broken bulk endpoint (any 5xx, or a JSON 404 — as opposed to the plugin-not-installed HTML 404) while single creation works: the tool then falls back to POST /testcase per item so partial progress survives — on such a build the fallback runs on every call and the bulk shape is never returned. A 4xx from the bulk endpoint is a payload error and is NOT retried. Returns [{ key, url }] on the bulk path, or { note, created: [{ key, url }], failed?: [{ index, name, error }] } when the fallback ran — also when SOME items failed, so always read failed[]. created[] is in input order but carries no index, and failed[] is omitted entirely when every item succeeded; index is the position in the testCases array. When EVERY item fails nothing was created and the call FAILS, with one line per item naming its index, its name and its error, so the payload can be fixed in one pass. A name longer than 255 characters is rejected locally, naming the item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
testCasesYesTest cases to create, each shaped like create_test_case input
projectKeyNoShared Jira project key for items without their own, e.g. "PROJ"; defaults to ZEPHYR_DEFAULT_PROJECT_KEY

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?

Annotations are empty, so the description carries the full burden and does so: it discloses the broken-bulk-endpoint fallback, that 4xx is not retried, the two distinct return shapes, that failed[] is omitted on full success, that created[] lacks indices, that an all-fail call raises with per-item lines, and the 255-char local rejection. This is exactly the behavioral detail an agent needs.

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?

It is long but front-loaded with purpose and folder prerequisite before the failure/return semantics. Nearly every sentence carries operational weight (fallback behavior, return shape, failure mode), though the return-shape discussion is dense and could be tightened without loss.

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?

With no annotations and no output schema, the description fully compensates by documenting both return shapes and the failure contract. Combined with 100% schema coverage on the input side, an agent has everything needed to call this correctly and interpret the result.

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 schema already documents both parameters and the nested item shape. The description still adds value beyond the schema: the cross-reference that each item takes the same fields as create_test_case, the projectKey resolution chain order, and the 255-character name limit that is not expressed in the schema.

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 specific verb (create), resource (test cases), and scope (several in one request, POST /testcase/bulk), which distinguishes it from the sibling create_test_case. It also names the shared field semantics and the fallback path, so an agent can tell what the tool actually does end-to-end.

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?

Gives a concrete prerequisite ('use create_folder first' because folders are never created implicitly) and explains the build-specific fallback path, which is useful routing context. It does not explicitly contrast against single create_test_case or state when bulk is preferable beyond the implied 'several items', so it stops short of full when/when-not guidance.

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