Zebrunner MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEBUG | No | Enable detailed logging | false |
| MAX_PAGE_SIZE | No | Maximum items per page | 100 |
| ZEBRUNNER_URL | Yes | Your Zebrunner instance URL (without trailing slash), e.g. https://your-company.zebrunner.com/api/public/v1 | |
| MCP_RULES_FILE | No | Custom technical rules file (optional) | |
| ZEBRUNNER_LOGIN | Yes | Your Zebrunner login (usually your email) | |
| ZEBRUNNER_TOKEN | Yes | Your Zebrunner API token (get this from your Zebrunner profile) | |
| DEFAULT_PAGE_SIZE | No | Default items per page | 100 |
| ENABLE_RULES_ENGINE | No | Enable intelligent rules system (auto-detected if rules file exists) | true |
| REQUIRE_UI_VALIDATION | No | Require UI validation in tests (optional) | |
| MIN_COVERAGE_THRESHOLD | No | Minimum coverage percentage (optional) | |
| REQUIRE_API_VALIDATION | No | Require API validation in tests (optional) |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_test_suitesC | 📋 List test suites for a project (✅ Verified Working) |
| get_test_case_by_keyB | 🔍 Get detailed test case by key (✅ Verified Working) |
| get_all_subsuitesB | 📋 Get all subsuites from a root suite as flat list with pagination |
| get_test_cases_advancedA | 📊 Advanced test case retrieval with filtering and pagination (✨ Enhanced with automation state and date filtering) ⚠️ IMPORTANT: Use 'suite_id' for direct parent suites, 'root_suite_id' for root suites that contain sub-suites. 💡 TIP: Use 'get_test_cases_by_suite_smart' for automatic suite type detection! |
| get_suite_hierarchyB | 🌳 Get hierarchical test suite tree with configurable depth |
| get_test_cases_by_automation_stateA | 🤖 Get test cases filtered by automation state (💡 Use get_automation_states to see available states) |
| get_automation_statesB | 🔧 Get available automation states for a project (names and IDs) |
| get_test_case_by_titleC | 🔍 Get test cases by title using partial match search with pagination support |
| get_test_case_by_filterC | 🔍 Get test cases using advanced filtering options with exact matching |
| get_automation_prioritiesB | 🎯 Get available priorities for a project (names and IDs) |
| get_test_coverage_by_test_case_steps_by_keyC | 🔍 Analyze test case coverage against actual implementation with recommendations |
| generate_draft_test_by_keyB | 🧪 Generate draft test code from Zebrunner test case with intelligent framework detection |
| get_enhanced_test_coverage_with_rulesC | 🔍 Enhanced test coverage analysis with configurable rules validation and quality scoring |
| get_tcm_test_suites_by_projectC | 📋 Get TCM test suites by project with pagination (Java methodology) |
| get_all_tcm_test_case_suites_by_projectC | 📋 Get ALL TCM test case suites by project using comprehensive pagination |
| get_root_suitesB | 🌳 Get root suites (suites with no parent) from project |
| get_tcm_suite_by_idC | 🔍 Find TCM suite by ID with comprehensive search |
| get_all_tcm_test_cases_by_projectB | 📋 Get ALL TCM test cases by project using comprehensive pagination |
| get_all_tcm_test_cases_with_root_suite_idC | 🌳 Get ALL TCM test cases enriched with root suite ID information |
| get_root_id_by_suite_idB | 🔍 Get root suite ID for a specific suite ID |
| get_test_cases_by_suite_smartA | 🧠 Smart test case retrieval by suite ID - automatically detects if suite is root suite and uses appropriate filtering with enhanced pagination |
| get_launch_detailsB | 🚀 Get comprehensive launch details including test sessions (uses new reporting API with enhanced authentication) |
| get_launch_test_summaryA | 📊 Get lightweight launch test summary with statistics (auto-paginated, token-optimized) |
| get_launch_summaryB | 📋 Get quick launch summary without detailed test sessions (uses new reporting API) |
| analyze_test_failureA | 🔍 Deep forensic analysis of failed test including logs, screenshots, error classification, and similar failures. 💡 NEW: Compare with last passed execution to see what changed! 💡 TIP: Can be auto-invoked from Zebrunner test URLs like: https://workspace.zebrunner.com/projects/PROJECT/automation-launches/LAUNCH_ID/tests/TEST_ID |
| get_test_execution_historyB | 📊 Get execution history for a test across multiple launches - shows pass/fail history, last passed execution, and pass rate |
| download_test_screenshotC | 📸 Download test screenshot with authentication from Zebrunner |
| analyze_screenshotB | 🔍 Analyze test screenshot with OCR and visual analysis - returns image to Claude Vision for detailed analysis |
| analyze_test_execution_videoA | 🎬 Download and analyze test execution video with Claude Vision - extracts frames, compares with test case, and predicts if failure is bug or test issue. NEW: Analysis depth modes (quick/standard/detailed), parallel frame extraction, similar failures search, and historical trends analysis! |
| detailed_analyze_launch_failuresA | 🚀 Analyze failed tests WITHOUT linked issues in a launch with grouping, statistics, and recommendations. Automatically analyzes all tests if ≤10, otherwise first 10 (use offset/limit for more). Use filterType: 'all' to include tests with issues. Supports pagination and screenshot analysis. NEW: Jira format with smart grouping - creates combined tickets for similar errors! 💡 TIP: Can be auto-invoked from Zebrunner launch URLs like: https://workspace.zebrunner.com/projects/PROJECT/automation-launches/LAUNCH_ID |
| get_all_launches_for_projectB | 📋 Get all launches for a project with pagination (uses new reporting API) |
| get_all_launches_with_filterC | 🔍 Get launches with filtering by milestone, build number, or launch name (uses new reporting API) |
| test_reporting_connectionA | 🔌 Test connection to Zebrunner Reporting API with new authentication |
| get_platform_results_by_periodC | 📊 Get test results by platform for a given period (SQL widget, templateId: 8) |
| get_top_bugsC | 🐞 Top N most frequent defects with optional issue links (SQL widget, templateId: 4) |
| get_bug_reviewC | 🔍 Get detailed bug review with failures, defects, reproduction dates, and optional automatic failure detail fetching (SQL widget, templateId: 9) |
| get_bug_failure_infoC | 🔬 Get comprehensive failure information including failure summary and detailed test runs (SQL widgets, templateId: 6 & 10) |
| get_project_milestonesC | 🎯 Get available milestones for a project with pagination and filtering |
| get_available_projectsC | 🏗️ Discover available projects with their keys and IDs for dynamic project selection |
| validate_test_caseC | 🔍 Validate a test case against quality standards and best practices (Dynamic Rules Support + Improvement) |
| improve_test_caseC | 🔧 Analyze and improve a test case with detailed suggestions and optional automatic fixes |
| list_test_runsB | 🏃 List Test Runs from Public API with advanced filtering |
| get_test_run_by_idC | 🔍 Get detailed Test Run information by ID from Public API |
| list_test_run_test_casesC | 📝 List all Test Cases in a Test Run from Public API |
| get_test_run_result_statusesB | Get list of Result Statuses configured for a project. These statuses are used when assigning results to Test Cases. |
| get_test_run_configuration_groupsC | Get list of Configuration Groups and their Options for a project. These are used to configure Test Runs. |
| analyze_test_cases_duplicatesB | 🔍 Analyze test cases for duplicates and group similar ones by step similarity (80-90%) |
| analyze_test_cases_duplicates_semanticC | 🧠 Advanced semantic duplicate analysis using LLM-powered step clustering and two-phase analysis |
| aggregate_test_cases_by_featureA | 🔍 Find ALL test cases related to a specific feature across the project. Searches in title, description, preconditions, and test steps (case-insensitive, partial match). Groups results by Root Suite and Feature Suite, avoiding duplicates. Output formats: detailed (full hierarchy), short (summary), dto (JSON), test_run_rules (for automation tags) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 49 tools
Multiple tools have overlapping purposes, causing significant ambiguity. For example, 'get_all_tcm_test_cases_by_project', 'get_all_tcm_test_cases_with_root_suite_id', 'get_test_case_by_filter', 'get_test_cases_advanced', and 'get_test_cases_by_suite_smart' all retrieve test cases with subtle distinctions that an agent would struggle to differentiate. Similarly, 'analyze_test_cases_duplicates' and 'analyze_test_cases_duplicates_semantic' overlap in purpose, and 'get_launch_details' vs. 'get_launch_summary' vs. 'get_launch_test_summary' are confusingly similar. The descriptions help but don't fully resolve the redundancy.
The naming follows a mixed convention with some consistency but notable deviations. Most tools use snake_case (e.g., 'aggregate_test_cases_by_feature', 'get_launch_details'), which is good, but there are inconsistencies like 'list_test_runs' (verb-first) vs. 'get_all_launches_for_project' (get-first), and some tools lack clear verb patterns (e.g., 'test_reporting_connection'). While readable, the mix of 'get', 'list', 'analyze', and other verbs without a strict pattern reduces predictability.
With 49 tools, the count is excessive for a test management server, leading to bloat and confusion. Many tools could be consolidated (e.g., multiple test case retrieval methods, duplicate analysis variants), and the high number suggests poor scoping. This overwhelms agents and makes navigation difficult, as typical MCP servers for similar domains (like GitHub with 10-15 tools) are more manageable. The server's purpose is clear, but the tool surface is unnecessarily fragmented.
The tool set is highly comprehensive for test management, covering analysis, retrieval, reporting, and automation tasks with few obvious gaps. It includes CRUD-like operations for test cases, launches, and suites, along with advanced features like failure analysis and duplicate detection. Minor gaps might include direct update or delete tools for test cases, but the server focuses on read and analyze operations, which aligns with its reporting and analytics domain. Overall, the coverage is thorough and supports complex workflows.