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.

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

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.