Allure TestOps MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ALLURE_TOKEN | Yes | Your API token for authentication (required) | |
| ALLURE_PROJECT_ID | No | Optional default project ID (if not set, tools require projectId or projectName) | |
| ALLURE_TESTOPS_URL | Yes | The URL of the Allure TestOps instance (required) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_test_casesC | List test cases for a project. |
| search_test_casesB | Search test cases by AQL query. |
| get_test_caseB | Get a test case by ID. |
| create_test_caseA | Create a new test case. payload.projectId defaults to ALLURE_PROJECT_ID env when omitted. payload.precondition (string) is the preconditions field — always use this for preconditions/prerequisites text, NOT payload.description. payload.description (string) is the general test case description — always populate this with a meaningful summary of what the test case verifies. payload.customFields supports values like { customField: { id }, id, name }. payload.steps is an optional array of step objects with { name (step text), expectedResult (optional expected result text) } — steps are created after the test case. When a step has multiple expected results, list them in expectedResult separated by semicolons (e.g. "Result A; Result B") or as a bullet list (lines starting with -, *, or a number). |
| update_test_case_stepB | Update a test case step by ID. Supports updating body text and/or expectedResult. If expectedResult is provided, the expected result node is created automatically if it does not exist yet. |
| update_test_caseB | Update an existing test case. payload.customFields supports values like { customField: { id }, id, name }. |
| delete_test_caseB | Delete a test case by ID. |
| add_test_case_tags_bulkC | Add one or multiple tags to one or multiple test cases using bulk API. |
| remove_test_case_tags_bulkB | Remove one or multiple tags from one or multiple test cases using bulk API. |
| add_test_case_external_links_bulkB | Add one or multiple external links to one or multiple test cases using bulk API. |
| get_test_case_overviewC | Get test case overview data. |
| get_test_case_historyC | Get test case run history. |
| get_test_case_scenarioC | Get scenario for a test case. |
| get_test_case_stepsA | Get manual scenario steps for a test case. Returns a normalized scenario with root step and a flat map of all steps (scenarioSteps), where each step contains body, expectedResult, children IDs, and optional sharedStepId. |
| get_test_case_tagsB | Get tags assigned to a test case. |
| set_test_case_tagsC | Set tags for a test case. |
| get_test_case_issuesB | Get linked issues for a test case. |
| set_test_case_issuesC | Set linked issues for a test case. |
| restore_test_caseA | Restore a deleted test case. |
| list_project_custom_fieldsB | List custom fields configured for a project. |
| list_custom_field_valuesC | List values for a custom field in a project. |
| get_test_case_custom_fieldsC | Get custom field values for a test case. |
| set_test_case_custom_fieldsB | Add custom field values for a test case via bulk API. Supports grouped values [{ customField: { id }, values: [{ id|name }] }] and flat values [{ id|name, customField: { id } }]. |
| list_test_case_attachmentsB | List attachments for a test case. |
| upload_test_case_attachmentA | Upload a file attachment to a test case. Provide file content as a base64-encoded string. |
| delete_test_case_attachmentB | Delete an attachment from a test case by attachment ID. |
| get_test_case_attachment_contentA | Download the binary content of a test case attachment. Returns base64-encoded content with its MIME type. |
| list_launchesC | List launches for a project. |
| search_launchesB | Search launches by AQL query. |
| get_launchB | Get a launch by ID. |
| create_launchB | Create a new launch. payload.projectId defaults to ALLURE_PROJECT_ID env when omitted. |
| update_launchC | Update an existing launch. |
| delete_launchB | Delete a launch by ID. |
| close_launchB | Close an open launch. |
| reopen_launchC | Reopen a closed launch. |
| get_launch_statisticC | Get launch statistics. |
| get_launch_progressC | Get launch progress widget data. |
| add_test_cases_to_launchC | Add test cases to a launch. |
| add_test_plan_to_launchC | Add a test plan to a launch. |
| list_test_resultsC | List test results for a launch. |
| search_test_resultsA | Search test results by AQL query. The 'id' field in returned results is an integer — pass it as a number (not a string) to get_test_result or get_test_result_retries. |
| get_test_resultB | Get a test result by ID. |
| create_test_resultC | Create a new test result. |
| update_test_resultC | Update an existing test result. |
| get_test_result_historyC | Get history for a test result. |
| assign_test_resultC | Assign a test result. payload must include username. |
| resolve_test_resultB | Resolve a test result. payload must include status. |
| get_test_result_retriesA | Get the retry history for a test result. Returns the list of previous attempts for the same test in the same launch. Key tool for flaky test detection: if a test failed on attempt 1 but passed on attempt 2, it is a flaky test, not a real failure. Check status across retries to assess reliability. |
| list_test_result_attachmentsA | List attachments (screenshots, logs, HAR files, etc.) for a test result. Returns attachment metadata: id, name, contentType, size. Use this to discover what evidence is available before calling get_test_result_attachment_content. |
| get_test_result_attachment_contentA | Download the binary content of a test result attachment. Returns base64-encoded content with its MIME type. Use attachment ID from list_test_result_attachments. For text-based attachments (logs, JSON, XML): decode base64 to read the content. For images (screenshots): the base64 PNG/JPEG can be rendered directly. |
| list_test_plansC | List test plans for a project. |
| get_test_planA | Get a test plan by ID. |
| create_test_planC | Create a new test plan. payload.projectId defaults to ALLURE_PROJECT_ID env when omitted. |
| update_test_planC | Update an existing test plan. |
| delete_test_planB | Delete a test plan by ID. |
| run_test_planC | Run a test plan by ID. |
| get_automation_chartB | Get automation trend chart data for a project (test automation coverage over time). |
| get_group_by_automationB | Get test case counts grouped by automation status for a project. |
| get_group_by_statusB | Get test case counts grouped by status for a project. |
| get_launch_duration_histogramB | Get histogram of launch durations for a project. |
| get_mute_trendB | Get trend of muted test cases over time for a project. |
| get_statistic_trendC | Get test result statistic trend over time for a project. |
| get_tc_last_resultB | Get last test result for each test case in a project. |
| get_tc_success_rateB | Get test case success rate analytics over time for a project. |
| list_dashboardsC | List all dashboards for a project. |
| create_dashboardB | Create a new dashboard in a project. |
| get_dashboardB | Get a dashboard by ID. |
| update_dashboardB | Update dashboard fields (name, shared status, etc.). |
| delete_dashboardB | Delete a dashboard by ID. |
| copy_dashboardB | Copy an existing dashboard to the same or another project. |
| get_widget_dataC | Get data for a specific dashboard widget. |
| list_defectsA | List defect records for a project. Defects group similar test result failures by root cause. Each defect has a name, status (open/closed), and optional matcher rules. Use this as the entry point for failure pattern analysis: 'what are the top open defects in this project right now?' |
| get_defectA | Get a defect by ID. Returns the defect name, status, description, and matcher configuration. |
| create_defectA | Create a new defect record to group a novel failure pattern. payload must include: name (string), projectId (number). Optional: description (string). |
| update_defectB | Update defect name, description, or status. |
| get_defect_test_resultsA | Get the test results grouped under a specific defect. Use this to see how many failures belong to this defect and in which launches they appeared. |
| get_defect_test_casesB | Get the test cases affected by a specific defect. Use this to understand which test scenarios are impacted by the failure pattern. |
| get_defect_launchesA | Get launches in which a specific defect has appeared. Use this to understand the blast radius: is this defect appearing in every run or only in specific environments? |
| get_launch_defectsA | Get all defects present in a specific launch. This is the fastest way to get a defect summary for a launch: 'what are all the distinct failure patterns in this test run?' |
| find_similar_failuresA | Find test results that match a defect pattern within a launch. Use this to detect flaky tests and group failures by root cause: pass launchId to scope the search, optionally pass a defectId to check match against a specific defect. Returns test results that are candidates for linking to the defect. |
| link_defect_to_test_resultsB | Link one or multiple test results to a defect record (bulk API). payload must include: defectId (number) and testResultIds (array of numbers). |
| bulk_close_defectsA | Close multiple defects at once — mark them as resolved after a fix is confirmed. payload must include: ids (array of defect IDs). |
| bulk_reopen_defectsA | Reopen multiple closed defects — use when a regression is detected after a fix was marked complete. payload must include: ids (array of defect IDs). |
| link_issue_to_defectA | Link an external issue (Jira, GitHub, etc.) to a defect record. payload must include: url (string) and name (string). Use this to associate a tracker ticket with a failure pattern. |
| unlink_issue_from_defectB | Remove the external issue link from a defect record. |
| apply_defect_matchersA | Apply all configured defect matcher rules to a launch. This auto-triages unresolved test results by matching them to existing defect records based on error message patterns. Run this after a launch completes to auto-group failures. |
| list_shared_stepsA | List shared steps (reusable step library) for a project. Shared steps are referenced from test case scenarios via sharedStepId. Use this to discover the available shared step library before reading test case steps. |
| get_shared_stepA | Get a shared step by ID. Returns metadata: name, project, archived status. |
| get_shared_step_stepsA | Get the full normalized scenario (list of steps) inside a shared step. This is the key tool for resolving sharedStepId references in test case scenarios: when get_test_case_steps returns a step with sharedStepId, call this tool to inline the actual step content. Returns the same NormalizedScenarioDto format as get_test_case_steps. |
| get_shared_step_usageA | Get the list of test cases that use a specific shared step. Use this for impact analysis before editing or archiving a shared step: shows which test cases would be affected. |
| create_shared_stepA | Create a new shared step in a project. payload must include at minimum: name (string) and projectId (number). Use this to extract repeated test steps into a reusable library. |
| update_shared_stepC | Update shared step metadata (name, etc.) by ID. |
| archive_shared_stepA | Archive a shared step to retire it from active use. Archived steps remain readable but are hidden from the active library. Run get_shared_step_usage first to check impact before archiving. |
| unarchive_shared_stepB | Restore an archived shared step back to active status. |
| list_env_varsA | List all environment variable definitions (keys) available in the system. Environment variables track test configuration context: browser, OS, environment name, build number, etc. Use this to discover what ev[] keys are available before constructing AQL filters like ev["browser"] = "Chrome" or ev["os"] = "Linux" in search_test_results or search_launches. |
| suggest_env_varsA | Search environment variable definitions by name. Returns matching env var keys with their IDs. Use this to find the exact name of an env var key before querying values. |
| list_env_var_schemasA | List environment variable schema definitions for a project. Schemas define which env var keys are tracked and displayed for launches in this project. Use this to understand what configuration context is captured per launch in a given project. |
| list_env_var_valuesA | List all recorded values for a specific environment variable key. Returns the distinct values that have been used across test runs (e.g. all browser versions recorded). Use envVarId from list_env_vars. Useful for building precise AQL filters: know that ev["browser"] has values ["Chrome 123", "Firefox 115"]. |
| suggest_env_var_valuesA | Search for recorded environment variable values by partial text. Optionally scope by envVarId, projectId, or launchId. Use this to autocomplete valid values for AQL ev[] filters before running a search. |
| get_test_result_env_varsA | Get the environment variable values recorded for a specific test result. Shows what configuration context (browser, OS, env name, build) this result ran against. Use this when investigating a failure to understand if the environment is a factor: e.g. 'does this only fail on Chrome 124 but not on Firefox?' |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iampopovich/allure-testops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server