Zephyr Scale MCP

zephyr-scale-mcp

MCP server for Zephyr Scale on self-hosted Jira Server / Data Center (formerly TM4J). It gives an AI agent — Claude Code, Claude Desktop, Cursor, any MCP client — 54 tools over your test management: test cases, folders, test cycles, executions, test plans, attachments and automation imports, through the Zephyr Scale REST API v1 at {JIRA_BASE_URL}/rest/atm/1.0.

npm: zephyr-scale-mcp · MCP Registry: io.github.vilaabo/zephyr-scale-mcp · Русская версия →

⚠️ Scope: Server / Data Center only. Zephyr Scale Cloud (API v2) and Zephyr Squad are different APIs and are out of scope — this server will not work against them.

Why this exists

Most Zephyr MCP servers target the Cloud API. If your Jira is on-premise you get the v1 API instead, and v1 has teeth: test runs are immutable after creation, folders cannot be listed, statuses are case-sensitive internal names, BDD scripts reject a Feature: header, and older plugin builds are missing whole endpoints. This server encodes that knowledge instead of leaving the agent to discover it one 400 at a time.

• 54 tools (42 public + 12 opt-in internal-API tools), each with a description that states the endpoint, the constraints a caller cannot guess, and the exact response shape.
• Composite tools for the API's blind spots — add_test_steps merges steps by id (read → merge → write) so nothing is silently deleted; recreate_test_run_with_items works around run immutability and can carry the last results over; get_issue_test_coverage, get_test_run_summary, clone_test_case, move_test_cases_to_folder.
• Degradation on older builds — automatic fallback when the paginated results endpoint is absent, and a per-item fallback when the bulk create endpoint is broken. Both were found on a real legacy instance, not in a changelog.
• Plumbing that fails loudly — strict zod input validation, Retry-After-aware retries with exponential backoff, error messages carrying actionable hints, read-only mode, secrets kept out of logs and tool output.
• 1181 unit and contract tests (vitest + msw, no network) plus a gated end-to-end scenario against a real instance.

Quick start

Requirements: Node.js >= 20, Jira Server/DC with the Zephyr Scale plugin, and a Personal Access Token (Jira 8.14+) or a username/password pair.

Nothing to clone — the package is on npm. Claude Code:

claude mcp add zephyr-scale \

--env JIRA_BASE_URL=https://jira.example.com \ --env JIRA_PAT= \ --env ZEPHYR_DEFAULT_PROJECT_KEY=PROJ \ --env ZEPHYR_ALLOW_INTERNAL_API=true \ -- npx -y zephyr-scale-mcp

Claude Desktop / any MCP client (claude_desktop_config.json, .mcp.json):

{

"mcpServers": { "zephyr-scale": { "command": "npx", "args": ["-y", "zephyr-scale-mcp"], "env": { "JIRA_BASE_URL": "https://jira.example.com", "JIRA_PAT": " ", "ZEPHYR_DEFAULT_PROJECT_KEY": "PROJ", "ZEPHYR_ALLOW_INTERNAL_API": "true" } } } }

Running from source instead

git clone https://github.com/vilaabo/zephyr-scale-mcp.git

cd zephyr-scale-mcp npm install npm run build # -> dist/index.js

Then point the client at the build: "command": "node", "args": ["/path/to/zephyr-scale-mcp/dist/index.js"].

`ZEPHYR_ALLOW_INTERNAL_API=true` is optional and recommended. It registers 12 extra tools that reach the things the public API cannot do at all: editing a test run in place — renaming or moving it (update_test_run) and adding or removing cases without changing its key (add_test_cases_to_run, remove_test_cases_from_run) — plus listing the folder tree (get_folder_tree), deleting folders (delete_folder), editing older executions (update_test_result_by_id) and reading the exact status names the API silently expects (get_status_options). These call the same undocumented /rest/tests/1.0 endpoints the Jira UI itself uses; the vendor does not support them and they may differ or be absent on another Zephyr Scale version. Leave the flag off if that trade-off is not acceptable — the other 42 tools are unaffected.

Then ask the agent to run health_check. It verifies connectivity and credentials via GET /rest/api/2/myself and, when ZEPHYR_DEFAULT_PROJECT_KEY is set, that the Zephyr plugin answers on /rest/atm/1.0.

What you can ask your agent to do

• *"Create the folder /Regression/Payments and add step-by-step test cases for the checkout flow described in this document."*
• *"Find every Draft case in /Regression, review them, and set the ready ones to Approved."*
• *"Create a cycle for sprint 42 with all smoke cases, then record the results from this report — step by step where the script has steps."*
• *"Which test cases cover PROJ-123, and when did each of them last pass?"* — traceability from the issue to its cases and their latest executions.
• *"Take this ZIP of Cucumber JSON reports and publish it as a new cycle in PROJ."* — automation import; scenarios are matched to BDD cases by their @TestCaseKey=PROJ-T1 tag.
• *"Add two steps to PROJ-T55 after step 3."* — existing steps and their ids survive.
• *"Recreate cycle PROJ-R7 with three more cases, keep the results, and delete the original."*

Configuration

Two guarantees the tests cover: JIRA_PAT and JIRA_PASSWORD never appear in logs, tool output or error messages — in any encoding they can take on the way out: raw, JSON-escaped, or the base64 basic-auth token (error text carries the method and path only — never the query string, which may contain data) — and stdout is reserved for the MCP protocol, every log line goes to stderr. One deliberate exception: a secret shorter than six characters is left alone, because redacting it would corrupt unrelated output while protecting nothing; the server warns about it at startup.

Configuration is validated at startup: all problems are reported at once and the process exits with a non-zero code rather than starting half-configured.

Tools

54 tools. The 42 public ones are always registered; the 12 in the last group only with ZEPHYR_ALLOW_INTERNAL_API=true.

Test cases — 13 tools

Test cycles (test runs) — 7 tools

Executions (test results) — 4 tools

Items that exist several times in a run (per environment or per assignee) are disambiguated with matchEnvironment / matchUserKey, sent as query parameters.

Test plans — 5 tools

Folders — 2 tools

Attachments</b