TestRail MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEBUG | No | Enable debug logging | |
| LOG_LEVEL | No | Set the log level (e.g., debug) | |
| TESTRAIL_URL | Yes | Your TestRail instance URL (e.g., https://your-instance.testrail.com) | |
| TESTRAIL_API_KEY | Yes | Your TestRail API key | |
| TESTRAIL_USERNAME | Yes | Your TestRail username |
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 |
|---|---|
| get_caseC | Fetch a TestRail test case by ID. |
| add_caseA | Create a new TestRail test case in a specific section. IMPORTANT: Before creating a case, gather required information using get_projects, get_suites, get_sections, and get_case_fields tools to ensure proper section_id, type_id, and custom field values. Or ask the user to provide the information if not provided. |
| update_caseC | Update a TestRail test case by ID with new field values. |
| get_projectsB | List all TestRail projects. |
| get_projectB | Get details for a specific TestRail project by ID. |
| get_suitesB | Get all test suites for a specific TestRail project by ID. |
| get_suiteC | Get details for a specific TestRail test suite by ID. |
| get_casesB | Get a list of test cases for a project or specific test suite with optional filtering and pagination. |
| add_attachment_to_caseC | Upload a file attachment to a TestRail test case. |
| get_sectionsC | Get a list of sections for a project and test suite with optional pagination. |
| get_runsA | Get a list of test runs for a project with optional filtering and pagination. Only returns test runs that are not part of a test plan. |
| get_runB | Returns an existing test run. Please see get tests for the list of included tests in this run. |
| update_runC | Updates an existing test run. Partial updates are supported. |
| get_testsC | Returns a list of tests for a test run. |
| get_testC | Returns an existing test. |
| update_testC | Updates the labels assigned to an existing test. |
| add_resultC | Adds a new test result, comment, or assigns a test. |
| get_case_fieldsB | Returns a list of available test case custom fields. |
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 18 tools
Most tools have distinct purposes targeting specific TestRail resources (cases, runs, tests, projects, suites, sections, fields), but there is some overlap between get_case/get_cases and get_test/get_tests that could cause confusion if an agent misinterprets singular vs. plural usage. The descriptions help clarify, but the naming similarity creates minor ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case, using clear action verbs like get, add, and update paired with specific nouns (e.g., get_case, add_attachment_to_case, update_run). This uniformity makes the tool set predictable and easy to navigate.
With 18 tools, the count is slightly high but reasonable for a comprehensive TestRail API coverage, including CRUD operations for cases, runs, tests, and supporting resources like projects and suites. It feels slightly heavy but well-scoped to the domain without being excessive.
The tool set provides complete CRUD/lifecycle coverage for TestRail's core domain, including projects, suites, sections, cases, runs, tests, and attachments. It supports creation (add_case), retrieval (get_* tools), updates (update_* tools), and result management (add_result), with no obvious gaps for essential workflows.