Skip to main content
Glama

create_folder

Creates a Jira/Zephyr test folder for cases, plans, or runs/cycles using a full root path; missing parent folders can be added when needed.

Instructions

Create a folder for test cases, test plans or test runs / test cycles (POST /folder). name is the FULL path from the root, not a single segment, and every segment must be non-empty and not blank — "/" alone, "/A//B", a trailing "/" and a whitespace-only segment ("/A/ ") are rejected before any HTTP call because the API would create a permanently nameless folder from them. Spaces around a real name are legal and are NOT trimmed. The two rules surface differently: a missing leading "/" is caught by the input schema (an MCP input-validation error), while empty or blank segments are caught by the tool itself (a plain "Invalid folder path ..." message). The other tools never create folders implicitly: create_test_case, create_test_run and create_test_plan fail with 400 on an unknown folder. Not idempotent: an existing path fails with 400 "The folder already exists" and no retry is attempted. With recursive=true (the default) any OTHER 400 on the full path triggers the fallback — every parent prefix is created from the root and the full path is retried once; 403, 409 and 5xx propagate unchanged, so a permission problem is never mistaken for a missing parent. On builds where POST /folder already creates missing ancestors itself that fallback never fires — the reference build is one of them: a two-level-deep new path succeeds even with recursive=false, so recursive is effectively a no-op there. Each folder type has its own tree, so the same path must be created once per type. The public Server/DC API v1 cannot LIST folders, so keep the numeric id returned by create_folder — rename_folder and delete_folder need it (otherwise it can only be found in the Jira UI, or with get_folder_tree when the internal API is enabled). Returns { id, name, type } — id is the id of the LAST segment only, so ancestors created along the way have ids this call never reports (find them with get_folder_tree).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesFull path of the folder to create, from the root, starting with "/", e.g. "/Regression/Payments" — every segment is a folder level and must contain at least one non-whitespace character. Segments are stored verbatim: leading and trailing spaces are NOT trimmed, so "/A/ B " and "/A/B" are different folders, but a segment made only of spaces is rejected.
typeYesFolder kind: TEST_CASE (test case folders), TEST_PLAN (test plan folders) or TEST_RUN (test cycle folders)
recursiveNoCreate missing parent folders after a 400 on the full path (default true). Client-side only — never sent to the API.
projectKeyNoJira project key, e.g. "PROJ"; defaults to ZEPHYR_DEFAULT_PROJECT_KEY when omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.5

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden and does so: it explains pre-flight validation, exact failure modes (400/403/409/5xx), non-idempotency with the specific error text, the recursive fallback semantics and the build where it is a no-op, and that 403 is never mistaken for a missing parent.

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 action and endpoint, and every sentence carries real information. It is a single dense paragraph with some overlap against the schema's own name rules, and could be broken into bullets for scanability, but nothing is 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?

With no output schema, the description still explains the return value { id, name, type } and the critical caveat that id is only the last segment, directing the agent to get_folder_tree for ancestor ids. Nothing needed to call it correctly is missing.

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 meaning beyond the schema: it clarifies that recursive is client-side only and effectively a no-op on the reference build, and explains that the two path rules surface through different layers (schema vs. tool).

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+resource with the underlying endpoint: 'Create a folder for test cases, test plans or test runs / test cycles (POST /folder)'. It also explicitly distinguishes itself from siblings, noting create_test_case/create_test_run/create_test_plan never create folders implicitly and fail with 400 on an unknown folder.

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 when-to-use context and alternatives: which sibling tools do not create folders, that each folder type has its own tree so a path must be created once per type, that the call is not idempotent, and that the returned id is required by rename_folder/delete_folder.

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