Create a new test case in Allure TestOps.

Get complete details of a specific test case.

Retrieves all information about a test case including its steps, tags, custom fields, and attachments. Use this before updating a test case to understand its current state.

Update an existing test case in Allure TestOps. ⚠️ CAUTION: Destructive.

Performs a partial update: only supplied fields are sent to the API. When provided, steps replace all existing steps, and attachments replace all existing global attachments. Omit a field to preserve its current value.

Archive an obsolete test case. ⚠️ CAUTION: Destructive.

This performs a SOFT DELETE (archive). The test case can typically be recovered from the Allure UI if needed.

⚠️ CAUTION: This action removes the test case from active views. Historical data and launch associations may be affected.

Permanently delete all archived/deleted test cases in the current project.

List all test cases in a project.

Returns a paginated list of test cases with their IDs, names, and tags. Use this to review existing test documentation in a project.

Get available custom fields and their allowed values for the project.

Use this tool to discover what custom fields are available (e.g., 'Layer', 'Priority') and what values are valid for them (e.g., 'UI', 'High'). This is essential before creating or updating test cases to ensure you use valid field names and values.

Delete custom fields that are unused by any test case in the current project.

List available values for a custom field.

Create a new custom field value option.

Update an existing custom field value. ⚠️ CAUTION: Destructive.

Delete a custom field value. ⚠️ CAUTION: Destructive.

Retrieve custom field values for a specific test case.

Search for test cases by name, tag, or AQL query.

Find test cases matching your search criteria. Supports simple name/tag search or advanced AQL (Allure Query Language) for complex filtering.

Simple Query Syntax (use 'query' parameter):

• Plain text: Searches in test case names (case-insensitive)

• tag:value: Filters by exact tag match

• Combined: "login tag:smoke" finds test cases with "login" in name AND "smoke" tag

Important: see https://docs.qameta.io/allure-testops/advanced/aql/ for the full AQL syntax reference. AQL Syntax (use 'aql' parameter):

• Operators: and, or, not

• Precedence: and binds tighter than or; use parentheses to group

• Strings are double-quoted; numbers are unquoted; booleans are true/false

• Comparison operators: =, !=, ~= (contains), in, not in

• Field examples: status, tag, name, createdBy, automated, layer

Create a new launch in Allure TestOps.

Retrieve a specific launch and summarize its details.

List launches in a project.

List test results inside a launch, including manual execution metadata.

Schedule manual reruns for selected launch results.

Start a manual execution session for a launch.

Submit manual execution results for a manual session.

Upload external test results to an existing launch.

Upload evidence to a manual test result.

Upload evidence to a manual attachment step inside a test result.

Delete a launch by ID. ⚠️ CAUTION: Destructive.

Close a launch and return updated launch details.

Reopen a launch and return updated launch details.

List available integrations (issue trackers) in Allure TestOps.

Use this tool to discover which integrations (Jira, GitHub, etc.) are configured and available for linking issues to test cases.

Create a new reusable Shared Step.

List shared steps in a project to find existing ones.

Update an existing shared step. ⚠️ CAUTION: Destructive.

⚠️ IMPORTANT: Changes propagate to ALL test cases using this shared step.

Only provided fields will be updated. Omitted fields remain unchanged. Repeated calls with the same data are idempotent.

Delete a shared step from the library. ⚠️ CAUTION: Destructive.

⚠️ CAUTION: If this shared step is used by test cases, deleting it will break those references.

Permanently delete all archived shared steps in the current project.

Link a shared step to a test case. ⚠️ CAUTION: Destructive.

Adds a reference to the shared step in the test case's step list. The shared step's actions will expand at execution time.

Remove a shared step reference from a test case. ⚠️ CAUTION: Destructive.

Removes the link to the shared step. The test case will no longer include those steps at execution time.

List test layers to discover available test layer taxonomy.

Test layers define the taxonomy for categorizing test cases (e.g., Unit, Integration, E2E). Use this to find layer IDs and names before creating or updating test cases.

Create a new test layer in Allure TestOps.

Test layers define taxonomy for categorizing test cases. Common examples include 'Unit', 'Integration', 'E2E', 'UI', 'API', etc.

Update an existing test layer's name. ⚠️ CAUTION: Destructive.

Delete a test layer from Allure TestOps. ⚠️ CAUTION: Destructive.

List test layer schemas for a project.

Test layer schemas map custom field keys to test layers within a project. They determine which test layer is assigned when a specific custom field value is used.

Create a new test layer schema to map a custom field key to a test layer.

Test layer schemas define the mapping between custom field keys and test layers. This allows test cases with specific custom field values to be automatically assigned to the correct test layer.

Update an existing test layer schema. ⚠️ CAUTION: Destructive.

Delete a test layer schema from the project. ⚠️ CAUTION: Destructive.

Create a new test suite node in the hierarchy tree.

List hierarchy suites for a project tree.

Assign test cases to a suite path in hierarchy.

⚠️ CAUTION: Destructive. Reassigning test cases changes their hierarchy location.

Delete a test suite node from hierarchy. ⚠️ CAUTION: Destructive.

This operation removes a hierarchy suite/group node. Allure TestOps handles nested entities according to its API behavior for tree groups.

Create a new Test Plan in Allure TestOps.

This tool allows creating a Test Plan, which is a collection of Test Cases to be executed. You can define the content of the plan either by:

1. Explicitly listing Test Case IDs (test_case_ids).

2. Providing an AQL (Allure Query Language) filter (aql_filter).

3. Both (explicit selection + dynamic filter).

Update the metadata of an existing Test Plan.

Currently, supports updating the name of the plan.

Modify the content (Test Cases) of an existing Test Plan.

Allows adding or removing specific Test Cases by ID, or updating the underlying AQL filter query.

List Test Plans for the current project.

Retrieves a paginated list of Test Plans, showing their IDs, names, and the number of test cases they contain.

Delete a Test Plan. ⚠️ CAUTION: Destructive.

Permanently removes the Test Plan from Allure TestOps. The operation is idempotent: if the plan does not exist, it returns success.

Create a new defect in the current project.

Use this tool to register a known defect that can later be linked to failing test results through defect matchers (automation rules).

Retrieve detailed information about a specific defect.

Link a defect to a test case through a shared issue mapping.

This operation ensures defect governance and test coverage are connected: the issue is linked to the defect and to the specified test case.

List test cases currently linked to a defect.

Unlink an issue from a test case.

This operation is idempotent: if the issue is already unlinked, it still returns a successful confirmation. Supply the issue key (for example, PROJ-123) or the internal issue-link ID returned by Allure TestOps.

Update an existing defect's name, description, or status.

At least one field must be provided. Fields set to null/None are left unchanged.

Permanently delete a defect and all its associated matchers.

This is a destructive operation. The confirm parameter must be set to true to actually perform the deletion.

List all defects in the current project.

Create a defect matcher (automation rule) for a defect.

Matchers automatically link future failing test results to a defect when the test failure's error message or stack trace matches the provided regex patterns.

At least one of message_regex or trace_regex must be supplied.

Update a defect matcher's name or regex patterns.

At least one field must be provided.

Permanently delete a defect matcher (automation rule).

This is a destructive operation. The confirm parameter must be set to true to actually perform the deletion.

List all matchers (automation rules) for a given defect.