Test Automation MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JIRA_EMAIL | No | Your Jira account email address | |
| JIRA_BASE_URL | No | Your Jira Cloud base URL, e.g. https://your-company.atlassian.net | |
| JIRA_API_TOKEN | No | Your Jira Cloud API token. Leave the Jira variables out to keep create_jira_bug in draft mode. |
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 | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_test_suitesA | List the test suites this server can run, with their commands and report locations. |
| run_testsA | Run a configured test suite (optionally filtered) and return pass/fail counts and the failing tests. Use get_failure_details next to dig into a specific failure. |
| get_test_resultsB | Summarize the most recent JUnit report for a suite without re-running it. |
| get_failure_detailsA | Return the error message, stack trace and captured output for failing tests whose name contains the given text. |
| query_test_dataA | Look up test accounts, products or other fixtures, filtered by exact field values. |
| create_jira_bugA | File a bug for a confirmed product defect. Include reproduction steps, expected vs actual result and the failing test name. Without Jira credentials this writes a draft file instead of creating a real issue. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| triage_failures | Run a suite, classify each failure and draft bugs only for real product defects. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct step in the test workflow: discovering suites, running tests, reading recent results, drilling into failures, querying fixtures, and filing a bug. The run_tests vs. get_test_results distinction is explicit: one executes, the other summarizes an existing report. get_failure_details is also clearly scoped to digging into named failing tests.
All tools use consistent snake_case with a clear verb_noun pattern: list_test_suites, run_tests, get_test_results, get_failure_details, query_test_data, create_jira_bug. The convention is predictable throughout with no mixed styles.
Six tools is well-scoped for a test automation server, covering the core workflow without redundant or filler operations. Each tool has a clear role in the run-inspect-debug-file lifecycle.
The surface covers the main workflow from listing suites through running tests, inspecting failures, querying fixtures, and filing a Jira bug. Minor gaps remain, such as historical results beyond the most recent report and suite configuration/management, but agents can work around them.