The surface mirrors TestRail's own nouns, with two additions that matter in practice: addResultsForCases posts an entire run's outcome in a single call, and getCases deliberately omits steps and expected results so listing a suite does not fill the context window. Milestones and shared steps are read-only here, and nothing deletes a run or a plan — cases and sections can be removed, but run cleanup still happens in the UI.
A server over the TestRail API covering projects, suites, sections, cases, runs, tests, results, plans, milestones and shared steps.
- Cases created, updated, copied and moved between sections, with updateCases applying the same field values to many cases at once and getCaseHistory showing what changed and when
- Results posted per case or for a whole run in one call, each carrying status, comment, defects, elapsed time, version and assignee
- Runs and plans built from the same material: a run from explicit case IDs or includeAll, a plan from entries, and further runs added to an existing plan entry for configuration matrices
- BDD in both directions — a .feature file imported into a section as a BDD-template case, and an existing case exported back out as Gherkin
- Reads sized for a context window: getCases returns basic fields without steps or expected results, getCase returns one case in full, and getSections pages with limit and offset
- Field discovery before writing: the available case types, the available case fields, and a project's shared steps
TESTRAIL_URL, TESTRAIL_USERNAME and TESTRAIL_API_KEY for a TestRail instance that account can reach. Writing customStepsSeparated needs templateId=2, and addBdd creates its case on the BDD template, template_id=4. MIT.
One command plus a key — npx -y @bun913/mcp-testrail, then supply credentials