TestRail MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TESTRAIL_API_KEY | Yes | Your TestRail API key | |
| TESTRAIL_USERNAME | Yes | Your TestRail user email address | |
| TESTRAIL_INSTANCE_URL | Yes | Your TestRail instance URL (e.g., https://example.testrail.io) | |
| TESTRAIL_ENABLE_SHARED_STEPS | No | Set to true to enable Shared Steps management tools | false |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_projectA | Retrieve a single project or all projects in TestRail. Set payload.action to 'one' or 'many' to specify the operation. |
| mutate_suiteB | Create a new test suite or update an existing one in TestRail. Set payload.action to 'create' or 'update' to specify the operation. |
| query_suiteB | Retrieve a single test suite or all test suites for a project in TestRail. Set payload.action to 'one' or 'many' to specify the operation. |
| get_caseB | Get detailed information about a test case including its custom fields |
| get_casesA | Get all test cases for a project. Filter by section, API params (priority, type), or any field including custom fields via 'where'. Returns case IDs, titles, and any additional requested fields. |
| get_case_fieldsA | Get the field schema for test cases for a specific project. You should normally provide project_id to get fields applicable to your project. If you truly need all fields across all projects, you may omit project_id, but this is rarely what you want. Returns available fields with their types and options (for dropdown fields). |
| update_caseA | Update a test case in TestRail. The update operation requires knowing valid field names that are returned by get_case_fields tool. Supports partial updates — only specify the fields you want to change. |
| update_casesA | Bulk update multiple test cases with the same field values. The update operation requires knowing valid field names that are returned by get_case_fields tool. More efficient than calling update_case multiple times. |
| add_caseA | Create a new test case in TestRail. The create operation requires knowing valid field names that are returned by get_case_fields tool. |
| resolve_case_fieldA | Resolve numeric reference IDs of a Multi-select case field (type ID 12) into their textual values for a specific project. |
| query_sectionB | Retrieve a single section or all sections for a project in TestRail. Set payload.action to 'one' or 'many' to specify the operation. |
| mutate_sectionA | Create a new section or update an existing section in TestRail. Set payload.action to 'create' or 'update' to specify the operation. |
| mutate_runA | Create a new test run or update an existing one in TestRail. Set payload.action to 'create' or 'update' to specify the operation. |
| query_runA | Retrieve a single test run or all test runs for a project in TestRail. Set payload.action to 'one' or 'many' to specify the operation. |
| query_testB | Retrieve a single test by ID or all tests for a test run in TestRail. Set payload.action to 'one' or 'many' to specify the operation. |
| get_testsA | Get tests for a test run, optionally filtered by status (Deprecated: use query_test with action 'many' instead) |
| add_resultsC | Add one or more test results to a test run |
| add_results_for_casesB | Add one or more test results to a test run using case IDs instead of test IDs |
| get_resultsC | Get results for a specific test in TestRail. |
| add_attachmentA | Add an attachment to a test case, test run, or test result in TestRail. If the file_path points to a directory, it will be automatically zipped before uploading. Maximum upload size is 256MB. |
| query_attachmentA | Download a single attachment or list all attachments for a test case or test run in TestRail. Set payload.action to 'one' or 'many' to specify the operation. |
| get_configurationsA | Get all configuration groups and configurations for a project in TestRail. |
| get_labelsA | Get all available test case labels (sometimes called tags) for a project. Returns label IDs and titles that can be used when creating or updating test cases. |
| get_prioritiesA | Get all available test case priorities (e.g. Critical, High, Medium, Low). Returns priority IDs and names that can be used when creating or updating test cases. |
| get_statusesA | Get all available test statuses (e.g. Passed, Failed, Blocked). Returns status IDs and names that can be used with add_result and get_tests |
| get_templatesA | Get available test case templates for a project. Template IDs determine which fields are available when creating or updating test cases |
| get_usersA | Get active users from TestRail. Resolves active users globally or per-project. If global fetch is forbidden (for non-admin accounts), falls back to merging users across all active projects so users referenced as reviewers or assignees can be resolved. |
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 27 tools
Most tools target clearly distinct resources and actions (e.g., get_case vs get_cases, query_suite vs mutate_suite), and descriptions help resolve overlaps. However, the results tools (get_results, add_results, add_results_for_cases) and the deprecated get_tests vs query_test create some ambiguity that could lead to misselection.
All tool names are snake_case with a verb_noun structure, which is largely predictable. Still, retrieval uses both get_ and query_, while writes use add_, update_, and mutate_ across similar resources, making the convention slightly inconsistent rather than uniform.
27 tools is on the heavy side for an MCP server, though TestRail's broad domain (projects, suites, sections, cases, runs, tests, results, attachments, metadata) justifies many of them. Redundant entries like get_tests and two result-add variants keep the count from feeling fully earned.
Core read/create/update workflows for cases, suites, sections, runs, results, and attachments are present, so common test management tasks are covered. However, delete operations are entirely absent, and project, milestone, and plan management are not represented, leaving notable lifecycle gaps.