io.github.mshegolev/allure-testops-mcp

Get summary statistics for an Allure project. Returns TC count, automation rate, and the last closed launch's pass/fail breakdown. Performs 3-4 API calls — progress is reported via MCP Context (visible as progress updates in compatible clients). Args: project_id: Allure project ID (see ``allure_list_projects``). ctx: MCP Context injected by FastMCP (used for progress reporting; never supplied by the agent directly). Returns: dict with keys: - ``project_id`` (int) - ``total_test_cases`` (int) - ``automated_test_cases`` (int) - ``manual_test_cases`` (int) - ``automation_rate_pct`` (float) - ``last_launch_id`` (int | None): latest *closed* launch - ``last_launch_name`` (str | None) - ``last_launch_passed`` / ``last_launch_failed`` / ``last_launch_broken`` (int) - ``last_launch_total`` (int) - ``recent_launches_count`` (int): launches examined to find the latest closed one Examples: - "How automated is project 63?" -> ``project_id=63``, read ``automation_rate_pct`` - "What was the last passing run for project 175?" -> read ``last_launch_passed`` Don't use when: - You need per-test detail (use ``allure_get_test_results``). - You need the full launch history (use ``allure_list_launches``).

Get one test case's full detail — fields, status/layer, tags, and steps. Unlike ``allure_list_test_cases`` (summaries), this returns the body of a single test case: description, precondition, expected result, and the manual scenario steps (flattened with a ``depth`` marker). Use it to read or review the actual content of a test case. Scenario steps are loaded from ``GET /testcase/{id}/scenario`` (nested tree). If that returns no steps, falls back to ``GET /testcase/{id}/step`` (normalized ``root`` + ``scenarioSteps`` map used by some Allure versions). Returns: dict with ``id``, ``name``, ``project_id``, ``automated``, ``description``, ``precondition``, ``expected_result``, ``status``, ``layer``, ``tags`` and ``steps`` (each: ``depth``, ``keyword``, ``name``, ``expected_result``). ``steps`` is empty when ``include_scenario`` is false or the case has none.

List the custom-field values set on a test case. Returns each value flattened to ``field_id`` / ``field_name`` (the custom field) and ``value_id`` / ``value_name`` (the chosen value) — e.g. field "Priority" → value "High". These are not included in ``allure_get_test_case``; fetch them here when you need a test case's custom-field assignments.

Get individual test results inside a launch, optionally filtered by status. The Allure server may ignore the ``status`` query parameter and return mixed-status pages. When ``status`` is set, this tool enforces the filter client-side (case-insensitive comparison) so the returned ``results`` always contain only rows matching the requested status. Args: launch_id: Allure launch ID (from ``allure_list_launches``). status: Filter — ``PASSED`` / ``FAILED`` / ``BROKEN`` / ``SKIPPED``. ``None`` returns all. page: 0-based page index. size: Items per page (1-200; default 50). Returns: dict with keys: - ``launch_id`` (int) - ``count`` (int): number of results after client-side status filter - ``pagination`` (dict) - ``results`` (list): each with ``id`` / ``name`` / ``status`` / ``duration_ms`` / ``error`` (first 300 chars of ``statusMessage``) Examples: - "FAILED tests in launch 12345" -> ``launch_id=12345, status="FAILED"`` - "All results in launch X, second page" -> ``launch_id=X, page=1`` Don't use when: - You want only FAILED+BROKEN (``allure_search_failed_tests`` does both in one call).

List the defect categories configured for a project. Categories are the named, coloured buckets shown on the project's *Categories* settings page (``name`` / ``color`` / ``description``). They are inert on their own — the regex rules that auto-assign failures live in ``allure_list_category_matchers``. Args: project_id: Allure project ID. page: 0-based page index. size: Items per page (1-500). Returns: dict with keys: - ``project_id`` (int) - ``count`` (int): items in this response - ``pagination`` (dict) - ``categories`` (list): each ``id`` / ``name`` / ``color`` / ``description`` Examples: - "What defect categories does project 175 have?" -> ``project_id=175`` Don't use when: - You want the regex automation rules (use ``allure_list_category_matchers``).

List the regex automation rules (matchers) for a project. Each matcher carries a ``message_regex`` / ``trace_regex`` (Java regex) and the ``category_id`` / ``category_name`` it feeds. This is the project's *automation schema* — what makes failing results land in a category automatically at result-ingest time. Args: project_id: Allure project ID. page: 0-based page index. size: Items per page (1-500). Returns: dict with keys: - ``project_id`` (int) - ``count`` (int) - ``pagination`` (dict) - ``matchers`` (list): each ``id`` / ``name`` / ``message_regex`` / ``trace_regex`` / ``category_id`` / ``category_name`` Examples: - "Show the auto-classification rules for project 175" -> ``project_id=175`` Don't use when: - You only need the bucket names/colours (use ``allure_list_categories``).

List the custom fields defined on a project (its schema). Returns each field's ``field_id``, ``name``, ``single_select`` and ``required``. Use it to discover which custom fields a project has before reading a test case's values with ``allure_get_test_case_custom_fields``. Built-in metadata fields (Epic/Feature/Story/Component/Suite) use negative ids; project-specific custom fields use positive ids.

List recent launches for a project, newest first. Each launch carries a pass/fail/broken/skipped breakdown from Allure's ``statistic`` field. Pagination info is returned in the ``pagination`` block (use ``next_page`` to continue). Args: project_id: Allure project ID. page: 0-based page index. size: Items per page (1-100; 20 is usually enough for triage). Returns: dict with keys: - ``project_id`` (int) - ``count`` (int): items in this response - ``pagination`` (dict): ``page`` / ``size`` / ``total`` / ``total_pages`` / ``has_more`` / ``next_page`` - ``launches`` (list): each with ``id`` / ``name`` / ``status`` / ``created_date`` / ``passed`` / ``failed`` / ``broken`` / ``skipped`` / ``total`` Examples: - "Last 10 launches for project 63" -> ``project_id=63, size=10`` - "Older launches beyond page 1" -> repeat with ``page=1`` Don't use when: - You need test results inside a launch (``allure_get_test_results``). - You need just the latest FAILED/BROKEN tests (``allure_search_failed_tests``).

List the test layers defined in a project (id, name). Use this to discover valid layer names/ids before setting a layer on ``allure_create_test_case`` / ``allure_update_test_case``. Built-in layers use negative ids (e.g. API Tests = -3). Returns: dict with ``project_id``, ``count`` and ``layers`` (each: ``id``, ``name``).

List all projects in the Allure TestOps instance. Use this first to discover which project IDs exist — all other tools take a ``project_id`` that you can look up here. Returns: dict with keys: - ``count`` (int): number of projects in this response - ``projects`` (list): each item has ``id``, ``name``, ``abbreviation`` Examples: - "Which projects exist in Allure?" -> default call, take the names/ids - "Find project by abbreviation" -> iterate ``projects`` and match Don't use when: - You already know the project id (skip discovery, go straight to the target tool).

List the test-case statuses defined in a project (id, name, color). Use this to discover valid status names/ids before setting a status on ``allure_create_test_case`` / ``allure_update_test_case``. Built-in statuses use negative ids (e.g. Draft = -1). Returns: dict with ``project_id``, ``count`` and ``statuses`` (each: ``id``, ``name``, ``color``).

List test cases for a project with optional automation and ownership filters. Each TC carries ``id``, ``name``, ``automated``, ``status``, ``layer`` (e.g. ``UNIT``, ``API``, ``E2E``), the ``createdBy`` / ``lastModifiedBy`` audit usernames, and a flat list of tag names. **Caveat:** the audit fields and ``tags`` are only populated when ``owner`` is set, because Allure's plain ``/testcase`` endpoint returns a compact projection that omits them — the ``owner`` path uses ``__search`` which returns the full projection. Args: project_id: Allure project ID. ctx: MCP Context (auto-injected by FastMCP for progress reporting). automated: ``True`` — only automated, ``False`` — only manual, ``None`` — both. owner: Optional Allure username. When set, the response is narrowed to TCs where ``createdBy = owner OR lastModifiedBy = owner`` (case-sensitive, exact match), enforced **server-side** via Allure's RQL ``__search`` endpoint. The username must match ``[A-Za-z0-9._@-]+`` — anything else is rejected at the MCP input layer (Pydantic ``pattern``) to prevent RQL injection. **Why "creator/modifier" and not "owner".** Allure TestOps does not expose a separate ``owner`` field in RQL on most deployments — the closest stable proxy for "TCs I touched" is the union of ``createdBy`` and ``lastModifiedBy``. **Trade-off when ``owner`` is set.** ``__search`` does not accept the ``automated`` query parameter, so an ``automated`` filter combined with ``owner`` is applied **client-side after the page is fetched**. ``pagination`` then reflects the raw owner-filtered set, not the further automation-filtered view — a fetched page of 50 may shrink. Raise ``size`` (max 200) or iterate ``page`` for full coverage. page: 0-based page index. size: Items per page (1-200; default 50). Returns: dict with keys: - ``project_id`` (int)…

Find FAILED and BROKEN tests in the most recent (or given) launch. Useful for triage: _"what's broken in the latest run"_ without listing every test. Performs up to 3 API calls; progress reported via MCP Context. Args: project_id: Allure project ID. launch_id: Specific launch ID. If ``None``, the latest launch is used. limit: Max failures per status (so up to ``2 * limit`` total). ctx: MCP Context (auto-injected). Returns: dict with keys: - ``launch_id`` (int): the resolved launch (latest if not passed in) - ``failed_count`` (int) - ``results`` (list): ``id`` / ``name`` / ``status`` / ``duration_ms`` / ``error`` Examples: - "What's failing in project 63 right now?" -> ``project_id=63`` - "Failures in launch 98765" -> ``project_id=N, launch_id=98765`` Don't use when: - You need PASSED tests too (use ``allure_get_test_results`` without status filter).