List all TestRail projects visible to the configured user.

Create a new TestRail suite in a project (only works on multi-suite projects).

project_id defaults to TESTRAIL_PROJECT_ID from env.

List suites under a TestRail project.

project_id defaults to TESTRAIL_PROJECT_ID from env when omitted or 0.

List sections in a suite, returning {id, name, parent_id}.

Defaults to TESTRAIL_PROJECT_ID / TESTRAIL_SUITE_ID from env when omitted.

Find a section that has at least min_cases real cases — useful as a house-style anchor when bootstrapping a new feature. Returns the first section meeting the threshold (sections are scanned in TestRail order).

List test cases in a project, optionally filtered by suite, section, or title substring.

Both project_id and suite_id fall back to env defaults (TESTRAIL_PROJECT_ID / TESTRAIL_SUITE_ID) when omitted or 0.

Fetch a single test case by its TestRail ID.

Create a single test case in a TestRail section.

case should look like: { "title": "...", "preconditions": "...", "steps": [{"step": "...", "expected": "..."}, ...] }

Resolve a section hierarchy like Auth > Login > Edge Cases, creating missing parents as needed. Returns {"section_id": int, "path": str}.

Defaults to TESTRAIL_PROJECT_ID / TESTRAIL_SUITE_ID from env when not provided.

Return up to N existing cases from the target section in style-example format.

Use this to preview what Claude will see as "house style" before generating.

Fetch the inputs needed to generate TestRail cases from a free-form spec.

This is an MCP-native pattern: the server doesn't call an LLM. It returns the spec, the house-style anchors, the target section, and an instructions block that tells the calling Claude how to generate cases and where to push them.

Targeting modes:

• section_id — push into an existing section ID later

• section_hierarchy — like Auth > Login; missing nodes will be created when you call add_test_cases_bulk. Defaults come from TESTRAIL_PROJECT_ID and TESTRAIL_SUITE_ID env.

House-style matching (default on): the server pulls a few existing cases from the target section (or a fallback populated section) so the calling Claude can match the local tone, naming, and step granularity. Override the style source with house_style_section_id to pull anchors from a different "golden" section.

Fetch a Jira ticket + house-style anchors. Returns the context the calling Claude needs to generate TestRail cases. Example: issue_key='ABC-123'.

Fetch a Confluence page + house-style anchors. Returns the context the calling Claude needs to generate TestRail cases. page_id is the numeric ID from the page URL: /wiki/spaces/X/pages/<page_id>.

Push a batch of test cases to TestRail in one call. Returns the IDs created.

cases items are in the shape returned by prepare_cases_* — each has {title, preconditions, steps:[{step, expected}]}. The server maps that into TestRail's payload format (custom_steps_separated etc.).

Targeting: either section_id directly, or section_hierarchy like 'Auth > Login > Smoke' — missing nodes are created.

Check generated cases against what's already in a TestRail section.

Uses title-token overlap (no embeddings) — fast, deterministic. Returns:

• kept: list of {case, reason} that look new

• duplicates: list of {case, existing_id, existing_title, overlap} threshold is the minimum token-overlap (0..1) to flag as duplicate.

Return the case batch alongside lint instructions for the calling Claude to evaluate.

No LLM call happens server-side — the client Claude reviews the cases using its own context and reports back, paid for by the user's subscription.

Return the spec and the existing case titles, plus instructions for the calling Claude to find missing coverage. No LLM call happens server-side.

List test runs in a project.

Filters:

• suite_id — only runs of this suite

• is_completed — True for closed/archived runs only, False for open only

Fetch the full metadata of a single test run.

Tests in a run with their current status (current = latest result).

All result entries for a run — includes comments, defects, who tested when.

Pull run metadata, statuses, and failure comments — return the structured payload + report instructions for the calling Claude to synthesise into Markdown.

No LLM call happens server-side. Claude in the client writes the report.

include_passed_titles=False (default) keeps the payload compact for big runs. Set True only for tiny runs (<50 tests) when full granularity is useful.

Create a new test run.

By default includes every case in the suite (include_all=True). Pass an explicit case_ids list and set include_all=False to scope the run.

Patch an existing test run's metadata. Pass only fields you want to change.

Mark a test run as completed/archived. This is irreversible in TestRail.

Post a single test result by case_id (TestRail looks up the test inside the run).

status accepts a string ("passed" | "failed" | "blocked" | "retest" | "untested") or a raw TestRail status_id (1..5 by default). elapsed is a TestRail time string ("30s", "1m 30s", "1h 5m"). defects is a comma-separated list of bug-tracker IDs ("BUG-1, BUG-2").

Post many results in one TestRail call (much faster than looping add_result).

Each entry in results must have at least case_id and status (string or id). Optional per-entry fields: comment, defects, elapsed, version, assignedto_id.

Patch an existing test case. fields is forwarded to TestRail as-is.

Common keys: title, custom_preconds, custom_steps_separated, priority_id, type_id, refs. To rewrite steps, pass a list under custom_steps_separated: [{"content": "...", "expected": "..."}, ...].

Compute the regression / fix / coverage delta between two runs and return the structured data + narrate instructions for the calling Claude.

A is the baseline (older), B is the newer run. No LLM call happens server-side.

Pull this case's result across the last N runs and flag flakiness.

A test is "flaky" if it has BOTH passes and failures in the window AND flips between them at least twice. Returns the run-by-run trace.

Prepare a feature-import workflow: fetch the spec, pull house-style anchors, and return everything the calling Claude needs to drive generation and push.

No LLM call happens server-side. Claude in the client generates cases (with the instructions and style examples this tool returns) and then calls add_test_cases_bulk to commit them.

Required:

• source_type: "confluence" | "jira" | "text"

• source_value: page_id / issue_key / raw text

• either new_suite_name (creates a new suite when you push) or existing_suite_id

• section_name — hierarchy allowed: "A > B > C"

Optional:

• style_from_suite_id — pull style anchors from a populated suite. Recommended when you're bootstrapping a brand-new empty suite that has no cases yet.