Zephyr Review MCP
Provides tools to review test coverage of Jira issues by fetching linked test cases, steps, and executions from Zephyr Scale Cloud.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Zephyr Review MCP review test coverage for STORY-123"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Zephyr Review MCP
A read-only Model Context Protocol server that exposes Zephyr Scale Cloud test data as review-oriented tools, so Claude (e.g. in Cowork) can review a story against its actual test coverage.
It answers: does this story have adequate, well-formed tests, and are they passing?
The story text (description, acceptance criteria) is expected to come from Jira (e.g. the Atlassian Rovo MCP). This server supplies the test-coverage half of the picture from Zephyr.
What it does (and does not)
Read-only. Every tool issues only
GETrequests. No tool creates, updates, or deletes Zephyr data. "Draft new tests" is a Claude reasoning activity in the conversation, not a write call.Assumes your team links test cases to Jira issues in Zephyr (the
issuelinksrelationship). If a story has no linked tests, coverage reads as empty.
Related MCP server: mcp-zephyr-scale
Tools
Tool | Purpose |
| Headline tool. Fans out over the linked test cases, their steps, and executions and returns one digested coverage bundle plus a pass/fail/not-run summary. Heavier — use when assessing coverage/quality/pass-fail. |
| Lightweight, story-scoped listing: the test cases linked to a story, each with key, name/title, priority, and status. No steps or executions. Use when you just want the list/titles of a story's tests. |
| Full detail of one test case, including ordered steps (empty expected-result fields kept visible for quality review). |
| Focused pass/fail view: each linked execution's status, cycle, and date. |
| Full execution history of one test case, newest-first — every run across all cycles plus ad-hoc runs (not just the latest). Each execution carries status, cycle, date, comment, timing (execution/estimated ms), who ran it, environment, custom fields, and linked Jira issues. Test-case-scoped; use |
| Project-wide discovery: test cases in a project whose key/name/objective match |
| Project identifier and metadata. |
Configuration
Set via environment variables (see .env.example):
Variable | Required | Default | Notes |
| yes | — | JWT bearer token. Generate in Jira → profile → Zephyr API keys. The server fails fast if unset. |
| no |
| One of |
| no | derived from region | Full base URL override; takes precedence over |
Regional base URLs:
us→https://api.zephyrscale.smartbear.com/v2(default)eu→https://eu.api.zephyrscale.smartbear.com/v2au→https://au.api.zephyrscale.smartbear.com/v2de→https://de.api.zephyrscale.smartbear.com/v2
The token maps to a Jira/Zephyr user; the server sees only what that user can see.
Usage
For using the server in an MCP client. Requires Node.js 18+. No clone or build needed — npx fetches and runs the published package.
Add to your MCP client config (Claude Cowork / Claude Desktop):
{
"mcpServers": {
"zephyr": {
"command": "npx",
"args": ["-y", "@pabloveintimilla/zephyr-mcp"],
"env": {
"ZEPHYR_API_TOKEN": "<your-token>",
"ZEPHYR_REGION": "us"
}
}
}
}That's it — the client launches the server on demand.
Development
For working on the server itself: clone the repository and install dependencies.
git clone https://github.com/pabloveintimilla/zephyr-mcp.git
cd zephyr-mcp
npm install
npm run buildRun it:
ZEPHYR_API_TOKEN=<your-token> npm start # from built dist/
ZEPHYR_API_TOKEN=<your-token> npm run dev # from source, no build stepRun the tests:
npm testPoint an MCP client at your local build (instead of the published package):
{
"mcpServers": {
"zephyr": {
"command": "node",
"args": ["/absolute/path/to/zephyr-mcp/dist/index.js"],
"env": {
"ZEPHYR_API_TOKEN": "<your-token>",
"ZEPHYR_REGION": "us"
}
}
}
}Spec-driven development with OpenSpec
This project uses OpenSpec for spec-driven
development. Do not start coding a feature directly — capture the intent as a change
first, then implement against it. This keeps openspec/specs/ (the source of truth for
current behavior) accurate and makes each change reviewable before code is written.
Layout:
openspec/specs/— the current, agreed behavior (one folder per capability).openspec/changes/— active changes in progress (proposal, design, specs delta, tasks).openspec/changes/archive/— completed changes, kept for history.
Workflow (run as slash commands in Claude Code, or with the openspec CLI):
Explore —
/opsx:exploreto think through the problem before committing to a design.Propose —
/opsx:proposeto create a change withproposal.md,design.md, a spec delta underspecs/, andtasks.md.Apply —
/opsx:applyto implement the tasks, checking them off as you go.Archive —
/opsx:archiveonce the work is done and verified; this syncs the spec delta intoopenspec/specs/and moves the change toarchive/.
Useful CLI commands:
openspec list # active changes
openspec status --change "<name>" # artifacts + task progress
openspec instructions <artifact> --change "<name>"Publishing / Release
Publishing to npm is automated by GitHub Actions (.github/workflows/publish.yml). Publishing a GitHub Release builds the package and runs npm publish --provenance --access public.
One-time setup:
Create an npm access token (Automation or Granular, with publish rights for
@pabloveintimilla/zephyr-mcp).Add it as a repository secret named
NPM_TOKEN(Settings → Secrets and variables → Actions).
Each release:
Bump the version:
npm version <patch|minor|major>(commits and tags).Push with tags:
git push --follow-tags.Create a GitHub Release for that tag — the workflow publishes it.
Verify: npx -y @pabloveintimilla/zephyr-mcp on a clean shell resolves the new version.
Reference
The Zephyr Scale Cloud OpenAPI spec is vendored at docs/zephyr.api.yml.
Available Tools
7 toolsget_projectGet projectA
Returns Zephyr project metadata (Zephyr id, Jira project id, key, enabled flag) for a project key. Useful to resolve keys and scope during a review. Read-only.
Inputs: projectKey (required).
get_test_caseGet test case detailA
Returns the full detail of a single Zephyr test case, including ordered steps with expected results. Steps with an empty expected-result field are preserved so quality gaps stay visible. Read-only.
Inputs: testCaseKey (required).
list_story_executionsList story executionsA
Returns the test executions linked to a Jira issue (story) with their status, cycle, and date — a focused pass/fail view. Returns an empty list when the story's tests have not been run. Read-only.
Inputs: issueKey (required).
list_story_test_casesList story test cases (titles only)A
LIGHTWEIGHT list of the test cases linked to one story (Jira issue key) — each with key, name/title, priority, and status. No steps, no executions. Use this when asked for the test cases or titles of a specific story. Prefer this over search_test_cases (which is project-wide, not story-scoped) and over review_story_coverage (which is heavier) when you only need the list. Read-only; returns an empty list (not an error) when no tests are linked.
Inputs: issueKey (required).
list_test_case_executionsList test case executions (full history)A
FULL execution history of ONE test case (Zephyr test case key), newest-first — every run across all cycles plus ad-hoc runs, not just the latest. Each execution includes status, cycle, date, comment, automated flag, timing (execution/estimated ms), who ran it, environment, custom fields, and linked Jira issues. Use this when asked about a specific test case's runs, history, or flakiness. This is TEST-CASE scoped — for the executions of a whole story (Jira issue key) use list_story_executions instead. Read-only; returns an empty list (not an error) when the test case has never been run.
Inputs: testCaseKey (required).
review_story_coverageReview story test coverageA
FULL coverage for one story (Jira issue key), including every step and execution. Use when assessing whether a story is well covered, well-formed, or passing. Returns a digested bundle: linked test cases with objective, priority, status, steps (action / expected result / data), each case's most recent execution, referenced test cycles, and a coverage summary (passed / failed / not-run counts and step-quality flags). Heavier than list_story_test_cases — if you only need the list/titles of a story's tests, use that instead. Read-only; returns empty coverage (not an error) when no tests are linked.
Inputs: issueKey (required).
search_test_casesSearch test cases (project-wide)A
PROJECT-WIDE search across ALL test cases in a project, matching key/name/objective (case-insensitive, client-side; the Zephyr API has no full-text search). This is NOT scoped to a story — do not use it to get the tests of a specific issue. Use it only when you do NOT have a Jira issue key, or to look beyond the tests linked to a single story. For a story's tests, use list_story_test_cases (titles) or review_story_coverage (full). Read-only.
Inputs: query (required), projectKey (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 7 tools
Each tool targets a distinct resource and action: project metadata, individual test case details, story-level test listing, story-level execution summary, test-case-level full execution history, comprehensive coverage review, and project-wide search. Descriptions explicitly differentiate between similar-sounding tools (e.g., list_story_test_cases vs review_story_coverage).
All tools follow a consistent verb_noun pattern with snake_case (get_project, get_test_case, list_story_executions, list_story_test_cases, list_test_case_executions, review_story_coverage, search_test_cases). The verbs are appropriately varied (get, list, review, search) and clearly indicate the operation type.
With 7 tools, the server is well-scoped for a read-only Zephyr review interface. Each tool serves a clear purpose without redundancy, covering project lookup, test case retrieval, story-level test listing, execution history (both story and test-case scoped), full coverage review, and project-wide search.
The tool surface fully covers the read-only Zephyr review domain: project metadata, individual test cases (with steps), story-linked tests (lightweight), story executions (pass/fail view), test case execution history (detailed), full coverage bundle (with step quality, cycles, summary), and project-wide search. No obvious gaps for the intended use case.
Maintenance
Related MCP Connectors
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Free test management over MCP: projects, test cases, plans, runs, environments and tasks.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Related MCP Servers
- AlicenseBqualityCmaintenanceAn MCP server for Zephyr Scale test management supporting Jira Cloud and Data Center. It enables creating, reading, and managing test cases and test runs via the Atlassian REST API with official API-compliant schemas.16283 npm7MIT
- AlicenseNot gradedqualityFmaintenanceMCP server for Zephyr Scale test management tool, enabling test case, test plan, test cycle, and test execution management.46 npm2MIT
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables Claude to read Jira user stories, search Confluence documentation, and generate QA artifacts like test scenarios, test cases, traceability matrices, coverage analysis, and executive summaries using GPT-4o.-
- AlicenseNot gradedqualityDmaintenanceMCP server for Zephyr Scale test management enabling test case, test run, folder, and assignment operations via natural language.2MIT