Skip to main content
Glama

download_feature_files

Read-only

Export BDD test cases from Jira/Zephyr as Gherkin .feature files in a ZIP via a required testCase TQL query, saving it to a local path.

Instructions

Export BDD test cases as Gherkin .feature files packed in a ZIP archive (GET /automation/testcases). tql is REQUIRED — the API rejects the call without it — and this endpoint uses the testCase.-prefixed TQL dialect, which supports ONLY the fields testCase.key, testCase.projectKey and testCase.name (= and IN) joined by AND: testCase.folder, testCase.status, testCase.priority and testCase.labels are rejected with 400 "Error executing TQL", so a whole folder cannot be exported — select the cases with testCase.key IN (...) instead. Values must be quoted, single or double quotes both work, and spaces around operators are optional here, unlike search_test_cases; lowercase "and", lowercase "testcase." and OR are not accepted, and an OR query answers 200 with an empty body rather than a syntax error. Only cases whose script type is BDD are exported: STEP_BY_STEP and PLAIN_TEXT cases, and keys in an IN list that do not exist, are silently skipped (332 cases yielded 251 .feature files on the reference instance) and the return value does not say which keys were dropped. A query that matches no BDD case — a nonexistent projectKey included — returns HTTP 200 with an EMPTY body, not an empty ZIP, and this tool then reports that the query matched nothing. The archive is flat: one .feature per case, no directories. The server writes "Feature: ", " @TestCaseKey=", " Scenario: ", a blank line, then every stored BDD line prefixed with exactly 8 spaces, so an exported file is only byte-identical to the stored script after that prefix is removed, and it is NOT accepted back by set_test_script / create_test_case (400 "Invalid BDD Script") until the Feature:/@TestCaseKey/Scenario: header is stripped. The archive is written to outputPath only after its 'PK' signature is verified, so an HTML login or error page served with HTTP 200 fails loudly instead of leaving a corrupt file. outputPath's parent directory must already exist, '~' is NOT expanded, and an existing file at outputPath is overwritten without warning on success (a failed call leaves it byte-identical). Reads from Zephyr only, so it stays available in ZEPHYR_READONLY mode. Returns { savedTo, bytes }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tqlYesTQL query selecting the BDD test cases to export, in the testCase.-prefixed dialect this endpoint requires — only testCase.key, testCase.projectKey and testCase.name are queryable, e.g. 'testCase.projectKey = "PROJ"' or 'testCase.key IN ("PROJ-T1", "PROJ-T2")'
outputPathYesLocal path to write the ZIP archive to, on the machine running this MCP server (the parent directory must exist)

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 only supply readOnlyHint=true, yet the description reconciles it ("Reads from Zephyr only, so it stays available in ZEPHYR_READONLY mode") and adds rich behavior: silent dropping of non-BDD/nonexistent keys, HTTP 200 with an empty body on no match, 'PK' signature verification, overwrite-without-warning of an existing outputPath, and that a failed call leaves it byte-identical. This is well beyond what the annotation conveys.

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 every sentence carries a concrete, non-redundant fact (dialect limits, silent skips, overwrite behavior). It is dense to the point of being a wall of text, so it is not maximally scannable, but nothing reads as filler.

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 discloses the return value ("Returns { savedTo, bytes }"), which is exactly the gap it needs to close. Combined with the edge-case behavior and file-format caveats, an agent has everything required to invoke it 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 operational meaning beyond the schema: quote requirements, disallowed lowercase/or forms, the exact per-field dialect restrictions, and that '~' is not expanded and the parent directory must pre-exist. It notably omits the same detail it advertises for tql from the schema text on outputPath syntax.

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 and resource ("Export BDD test cases as Gherkin .feature files packed in a ZIP archive") and cites the underlying endpoint GET /automation/testcases. It is clearly distinguishable from siblings like set_test_script, download_attachment and search_test_cases.

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 strong context on when the call is viable: tql is REQUIRED, only the testCase.-prefixed dialect works, only BDD-script cases are exported, and it explicitly recommends testCase.key IN (...) since folder/status/priority filters are rejected. It never routes to an alternative for the main purpose (e.g. search_test_cases to discover keys), so it stops short of a full when/when-not map.

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