Zephyr Scale MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_TYPE | No | Force Jira type: 'cloud' or 'datacenter' | |
| JIRA_USERNAME | No | Your Jira account email address (required for issue_links feature on Cloud) | |
| JIRA_API_TOKEN | No | Jira API token (required for issue_links feature on Cloud) | |
| ZEPHYR_API_KEY | Yes | Zephyr Scale API key/token | |
| ZEPHYR_BASE_URL | Yes | Your Jira instance URL (e.g., https://your-company.atlassian.net for Cloud, https://your-jira-server.com for Data Center) | |
| ZEPHYR_API_BASE_URL | No | Override Zephyr API base URL (e.g., for EU region: https://eu.api.zephyrscale.smartbear.com/v2) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_test_caseB | Get detailed information about a specific test case |
| create_test_caseB | Create a new test case with STEP_BY_STEP, PLAIN_TEXT, or BDD content. To match your project's structure, use the zephyr://testcase/EXISTING-KEY resource to fetch a real test case and use its structure as a template, especially for custom_fields. |
| update_test_case_bddA | Update an existing test case with BDD content. Optionally update the test case name. Unspecified fields are preserved. |
| create_folderA | Create a new folder in Zephyr Scale. On Cloud: provide a path like "/Parent/Child" — the server resolves parent segments and creates the leaf folder. On Data Center: the full path is sent directly. |
| get_foldersA | Get folders from Zephyr Scale. All parameters are optional. If folder_path is provided, returns the full subtree (the folder and all its descendants at every depth) under that path. Otherwise returns all folders matching the filters. |
| get_test_run_casesC | Get test case keys from a test run |
| delete_test_caseA | Delete a specific test case (Data Center only — not supported on Cloud v2) |
| create_test_runC | Create a new test run |
| get_test_runA | Get detailed information about a specific test run |
| get_test_executionA | Get detailed information about a specific test execution by ID or key. On Cloud, provide the execution ID or key (e.g., PROJ-E123) directly. On Data Center, also provide test_run_keys to search within. |
| search_test_cases_by_folderB | Search for test cases in a specific folder |
| search_test_runsA | Search for test runs using a query. Supports filtering by projectKey and/or folder path. On Cloud, only returns cycles in the exact folder (not sub-folders). Use folder_id for direct numeric ID lookup (skips path resolution). |
| list_executions_by_cycleB | List all test executions for a specific test cycle. Returns execution status, executedBy, actualEndDate for each test case in the cycle. Cloud only. |
| update_test_runA | Update an existing test cycle — set owner, name, description, dates, or status. Unspecified fields are preserved. Cloud only. |
| delete_test_runA | Delete a specific test run (Data Center only — not supported on Cloud v2) |
| add_test_cases_to_runA | Add test cases to an existing test run (Cloud only — not supported on Data Center) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| File System Access | Read user-provided files containing test case examples, payloads, or templates. Use file:// followed by absolute path (e.g., file:///Users/username/examples/test-payload.json) |
| Live Test Case Data | Fetch real test case data from Zephyr Scale to use as templates. Use zephyr://testcase/TEST-KEY (e.g., zephyr://testcase/PROJ-T123). The fetched data shows the exact structure including customFields, folder paths, and other project-specific configurations that you can copy when creating new test cases. |
| Step-by-Step Test Case - Request Payload Example | Example payload for creating a step-by-step test case |
| BDD Content Conversion Example | Shows how BDD content is converted from markdown to Gherkin format |
TDQS
Scored across 16 tools
Each tool targets a distinct resource and action (folders, test cases, test runs, executions). There is no overlap or ambiguity; even similar tools like create_test_case and update_test_case_bdd are clearly differentiated by operation and scope.
All tools follow a consistent verb_noun pattern (e.g., create_test_case, get_test_run, update_test_run). Names are descriptive and predictable, making it easy for an agent to infer functionality.
16 tools is slightly above the typical well-scoped range but still reasonable for a test management server covering folders, test cases, runs, and executions. Each tool appears justified, with no redundant ones.
The surface covers most CRUD operations for test cases and runs, but has notable gaps: update_test_case only supports BDD content (no general update), and some operations are restricted to Cloud or Data Center. Missing delete for test executions is minor.