io.github.mshegolev/allure-testops-mcp

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).

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``).

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``).

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).

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).

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) - ``count`` (int): items in this response (post any client-side ``automated`` filter) - ``pagination`` (dict): raw Allure paging - ``test_cases`` (list): each item carries ``id`` / ``name`` / ``automated`` / ``status`` / ``layer`` / ``created_by`` / ``last_modified_by`` / ``tags`` Examples: - "How many manual TCs does project 63 have?" -> ``project_id=63, automated=False``, read ``pagination.total`` - "First 200 automated TCs" -> ``automated=True, size=200`` - "My manual TCs in project 63" -> ``project_id=63, automated=False, owner="jdoe", size=200`` Don't use when: - You need just the automation % (``allure_get_project_statistics``).

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 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``).

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.

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 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``).

Create a new test case in an Allure TestOps project. Requires ``ALLURE_ENABLE_WRITE=true`` to be set when the server starts — otherwise this tool is not registered. Surfaces the Allure 400 / 409 error text on rejection (e.g. unknown status/layer name, duplicate). Status and layer accept either a ``status_id`` / ``layer_id`` (used as-is) or a ``status`` / ``layer`` *name*, which is resolved to its id against the project's status/layer list. An unknown name yields an actionable error listing the valid names. Examples: - "Create a Draft TC named 'Login flow' in project 63" -> ``project_id=63, name="Login flow", status="Draft"`` - "Add an automated smoke TC" -> ``automated=True, tags=["smoke"]``

Partially update an existing test case. Only the fields you set are sent to Allure — the rest are left untouched. Pass ``tags=[]`` to clear every tag; omit ``tags`` to leave them as-is. Requires ``ALLURE_ENABLE_WRITE=true``. Status and layer accept a ``status_id`` / ``layer_id`` (sent as Allure's flat ``statusId`` / ``testLayerId``) or a ``status`` / ``layer`` *name*, which is resolved to its id — this performs an extra lookup of the test case's project. An unknown name yields an actionable error. Examples: - "Rename TC 555 to 'Login (rewritten)'" -> ``test_case_id=555, name="Login (rewritten)"`` - "Mark TC 555 automated" -> ``test_case_id=555, automated=True`` - "Set TC 555 status to Active" -> ``test_case_id=555, status="Active"``

Permanently delete a test case from Allure TestOps. **Destructive**: the deletion is irreversible from Allure's side. The explicit ``confirm=True`` parameter is required so callers cannot delete by accident if the destructive-hint annotation is ignored. Requires ``ALLURE_ENABLE_WRITE=true``. Examples: - "Delete test case 555" -> ``test_case_id=555, confirm=True``

Create a defect category (named, coloured bucket) in a project. A category on its own classifies nothing — pair it with a matcher (``allure_create_category_matcher``) to auto-assign failures by regex. Requires ``ALLURE_ENABLE_WRITE=true``. The server rejects an empty colour (HTTP 409), so a default grey is sent when ``color`` is omitted. Examples: - "Add a category 'Infra: WireMock down' to project 175" -> ``project_id=175, name="Infra: WireMock down", color="#E67E22"``

Permanently delete a defect category. **Destructive.** Any matchers still pointing at this category are orphaned (they classify nothing). Requires ``ALLURE_ENABLE_WRITE=true``. Examples: - "Delete category 377" -> ``category_id=377, confirm=True``

Create a regex matcher and attach it to a project's automation schema. This is the rule that makes a category *automatic*: at result-ingest time Allure assigns any failure whose message/trace matches to ``category_id``. Two API calls — create the matcher, then attach it to the project; the ``attached`` flag reports whether the second step succeeded. At least one of ``message_regex`` / ``trace_regex`` should be set (a matcher with neither classifies nothing). Requires ``ALLURE_ENABLE_WRITE=true``. **Existing-run caveat.** Matchers evaluate at ingest, so a new matcher does NOT retroactively reclassify past launches — it applies from the next run. Examples: - "Auto-route ISSO token failures to category 382 in project 175" -> ``project_id=175, category_id=382, name="Auth/ISSO", message_regex="(?s).*(unauthenticated|sign in via ISSO).*"``

Permanently delete a category matcher (regex automation rule). **Destructive.** Removing the matcher stops auto-classification into its category from the next run onward; the category bucket itself remains. Requires ``ALLURE_ENABLE_WRITE=true``. Examples: - "Delete matcher 278" -> ``matcher_id=278, confirm=True``