The allure-testops-mcp server provides an MCP interface to Allure TestOps, enabling LLM agents to explore, manage, and report on projects, launches, test cases, and reference data via the Allure REST API.
List all projects: Discover all projects on the instance by ID, name, and abbreviation.
Get project statistics: Retrieve total test case count, automation rate, and the latest launch's pass/fail/broken breakdown.
List launches: Browse recent test launches with pass/fail/broken/skipped stats, paginated newest-first.
Get test results: Fetch individual test results within a specific launch, optionally filtered by status (PASSED, FAILED, BROKEN, SKIPPED).
Search failed/broken tests: Quickly find FAILED and BROKEN tests in the most recent or a specified launch for triage.
List test cases: List test cases with optional filters for automation type (automated/manual) and ownership (creator/last modifier).
Get test case detail: Retrieve full details of a single test case — description, preconditions, expected results, status, layer, tags, and flattened scenario steps.
Get test case custom fields: View custom-field values assigned to a specific test case.
List statuses: Discover all test-case statuses defined in a project (id, name, color).
List layers: Discover all test layers defined in a project (e.g., Unit, API, E2E).
List custom fields: View the custom field schema for a project (name, type, required, etc.).
List categories: View defect categories (named/colored buckets) defined in a project.
List category matchers: View regex automation rules that map error messages/traces to defect categories.
ALLURE_ENABLE_WRITE=true)Create test case: Create a new test case with name, status, and layer.
Update test case: Partially update an existing test case — only provided fields are changed.
Delete test case: Permanently delete a test case (destructive; requires explicit confirm=true).
Create category: Create a new defect category in a project.
Delete category: Permanently delete a defect category (destructive; requires confirm=true).
Create category matcher: Attach a regex rule that automatically assigns failures to a defect category.
Delete category matcher: Permanently delete a category matcher rule (destructive; requires confirm=true).
Instance-wide access: One server connects to all projects on the Allure instance.
Pagination: All list tools support pagination with has_more and next_page indicators.
Structured output: Typed JSON schemas and markdown summaries for all tools.
Security: API-token authentication, optional SSL verification, proxy bypass, and input validation (Pydantic, no RQL injection).
Actionable error messages: Handles common API errors (auth failures, rate limits, etc.) with clear guidance.
Progress reporting: Multi-call tools report progress during execution.
An MCP server for Allure TestOps. It lets an LLM agent (Claude Code, Cursor, OpenCode, …) explore and manage projects, launches, test cases, test results and reference data through the Allure REST API.
Stack: Python 3.10+, FastMCP, stdio transport.
Compatibility: any Allure TestOps instance — SaaS qameta.io or self-hosted / on-prem (API at /api/rs).
Instance-wide — all projects at once: one connection serves every project on the instance. The server isn't pinned to a single project — discover them with allure_list_projects, then pass any project_id. No reconfiguration to switch or compare projects.
Corporate-friendly: API-token auth, optional SSL-verify toggle, deliberate proxy bypass.
Safe by default: 13 read-only tools; the 7 write tools are off unless you opt in.
claude mcp add allure -s user \
--env ALLURE_URL=https://allure.example.com \
--env ALLURE_TOKEN=your-api-token \
-- uvx --from allure-testops-mcp allure-testops-mcpThen ask your agent: "List all Allure projects" or "Show failed tests in the last launch for project 175". Get an API token in Allure TestOps under Profile → API tokens. See Configuration for other clients and Environment variables for all options.
Related MCP server: Allure TestOps MCP
20 tools — 13 read-only (always on) and 7 write tools (opt-in via ALLURE_ENABLE_WRITE=true). Every tool
carries MCP annotations and returns both a typed structuredContent payload and a markdown summary.
Tool | Kind | Purpose |
| read | All projects (id, name, abbreviation) |
| read | TC count, automation rate, last-launch summary |
| read | Recent launches with pass/fail stats |
| read | Test results in a launch (filter by status) |
| read | FAILED/BROKEN tests in the last or a given launch |
| read | Test cases (automated/manual + owner filters) |
| read | One test case's full detail + scenario steps |
| read | A test case's custom-field values |
| read | A project's statuses (id, name, color) |
| read | A project's test layers (id, name) |
| read | A project's custom-field schema |
| read | Defect categories (named/coloured buckets) |
| read | Regex automation rules (message/trace → category) |
| write ⚑ | Create a test case |
| write ⚑ | Partial update of a test case |
| write ⚑ | Permanent delete (destructive — needs |
| write ⚑ | Create a defect category |
| write ⚑ | Permanent delete (destructive — needs |
| write ⚑ | Create + attach a regex automation rule |
| write ⚑ | Permanent delete (destructive — needs |
⚑ Registered only when ALLURE_ENABLE_WRITE=true. Without the flag they are never imported, so the agent
never sees them — see Security considerations.
allure_create_test_case / allure_update_test_case accept status and layer as either a name
(status / layer) or a numeric id (status_id / layer_id). Names are auto-resolved to ids against
the project's status/layer lists (GET /api/rs/status, GET /api/rs/testlayer) — an unknown name returns an
actionable error listing the valid options. Update is partial (only the fields you pass change), and
allure_delete_test_case is irreversible: it carries destructiveHint: True (compliant clients prompt) and
additionally requires an explicit confirm=true argument.
Full tool annotations — read tools are readOnlyHint: True / openWorldHint: True so clients don't
prompt; allure_delete_test_case is destructiveHint: True.
Structured output on every tool — each tool declares a TypedDict return type, so FastMCP
auto-generates an outputSchema and every result carries both structuredContent and a markdown block.
Actionable errors — auth / 400 / 403 / 404 / 409 / 429 / 5xx / missing-env errors are converted to specific, next-step messages (e.g. "Authentication failed — verify ALLURE_TOKEN has API scope").
Pydantic input validation — every argument has typed constraints (ranges, lengths, literals), exposed as JSON Schema; usernames are alphabet-restricted to prevent RQL injection.
Pagination — list tools return a pagination block with page, total, has_more, next_page.
Progress reporting — multi-call tools emit ctx.report_progress + ctx.info events.
Version-agnostic update verb — allure_update_test_case issues PATCH and falls back to PUT on
HTTP 405, so it works across Allure deployments that expose only one verb.
Single source of truth for version — __version__ derives from installed package metadata, and a test
asserts pyproject.toml matches both server.json version fields, so the published version can't drift.
Requires Python 3.10+. No manual install needed if you use uvx (recommended) — your MCP client runs it.
# run on demand via uvx (recommended)
uvx --from allure-testops-mcp allure-testops-mcp
# or install with pipx
pipx install allure-testops-mcpClaude Code — one command:
claude mcp add allure -s user \
--env ALLURE_URL=https://allure.example.com \
--env ALLURE_TOKEN=your-api-token \
--env ALLURE_SSL_VERIFY=true \
-- uvx --from allure-testops-mcp allure-testops-mcpAny MCP client — add to ~/.claude.json, a project .mcp.json, Cursor's mcp.json, etc.:
{
"mcpServers": {
"allure": {
"type": "stdio",
"command": "uvx",
"args": ["--from", "allure-testops-mcp", "allure-testops-mcp"],
"env": {
"ALLURE_URL": "https://allure.example.com",
"ALLURE_TOKEN": "${ALLURE_TOKEN}",
"ALLURE_SSL_VERIFY": "true"
}
}
}
}See .env.example for a template. Verify the connection:
claude mcp list
# allure: uvx --from allure-testops-mcp allure-testops-mcp - ✓ ConnectedVariable | Required | Default | Description |
| yes | — | Allure TestOps URL (e.g. |
| yes | — | API token (Allure → Profile → API tokens) |
| no |
|
|
| no |
|
|
ALLURE_TEST_PROJECT_ID (plus optional ALLURE_TEST_STATUS / ALLURE_TEST_LAYER) are used only by the
opt-in live integration tests — see Development.
The server is a stdio process your client respawns each session, so the running version is decided by the
uvx invocation. uvx caches the resolved environment under ~/.cache/uv, so an older version sticks until
you refresh:
uvx --refresh --from allure-testops-mcp allure-testops-mcp # force latest on next run
uv cache clean allure-testops-mcp # or drop the cached envThen reconnect the server (/mcp → reconnect, or restart the session). To control the version from config,
edit args — pin for stability, or always-latest for currency:
// Pin a version (deterministic; bump consciously)
"args": ["--from", "allure-testops-mcp==0.8.0", "allure-testops-mcp"]
// Always latest on every start (adds a PyPI lookup per launch)
"args": ["--refresh", "--from", "allure-testops-mcp", "allure-testops-mcp"]Read-only:
"List all Allure projects"
"Show the last 10 launches for project 63"
"Failed tests in the last launch for project 175"
"What's the automation rate for project 842?"
"Compare the automation rate of project 63 and project 842" — works across projects in one session
"Show me the steps of test case 641012"
"Which custom fields does project 1664 have?"
With ALLURE_ENABLE_WRITE=true, drive test-case CRUD in natural language:
"Create a Draft manual TC named 'Login flow' in project 63"
"Add an automated smoke TC in project 63 tagged smoke, layer E2E"
"Rename test case 555 to 'Login (rewritten)' and set its status to Active"
"Delete test case 555" — the agent passes confirm=true, and a compliant client prompts you first
API token is read from ALLURE_TOKEN only — never passed on the command line, never written to logs.
Secrets are never echoed back in tool responses (no header dumps, no auth reflection).
Self-signed SSL is opt-in via ALLURE_SSL_VERIFY=false (default true). Disabling verification on a
public network is a risk; use only for trusted corporate instances.
Proxy discovery is disabled (session.trust_env = False) — the server ignores HTTP_PROXY /
HTTPS_PROXY so it can't be silently routed through an unintended proxy.
Writes are opt-in and least-privilege — without ALLURE_ENABLE_WRITE=true the server registers only the
13 read-only tools and cannot create, modify, or delete anything, even with a write-scoped token. When
enabled, the destructive tools (allure_delete_test_case / allure_delete_category /
allure_delete_category_matcher) carry destructiveHint: True and require confirm=true.
Input validation via Pydantic — every argument is typed and bounded; usernames are alphabet-restricted to prevent RQL injection through the search endpoint.
A token is never more privileged than its account — Allure Api-Token auth inherits the issuing user's
role, so a read-only (guest) account yields a read-only server regardless of the ALLURE_ENABLE_WRITE flag.
Allure TestOps enforces per-instance rate limits (typically ~60 requests/minute per token). On HTTP 429 the
server returns an actionable error suggesting you wait 30–60s, reduce size, or paginate with smaller pages.
Two tools make multiple API calls internally — allure_get_project_statistics (3) and
allure_search_failed_tests (2–3) — and report per-step progress via MCP Context.
git clone https://github.com/mshegolev/allure-testops-mcp.git
cd allure-testops-mcp
pip install -e '.[dev]'
pytest # unit suite (all HTTP mocked)
ruff check src tests && ruff format --check src testsRun the server directly (stdio transport — waits on stdin for MCP messages):
ALLURE_URL=... ALLURE_TOKEN=... allure-testops-mcpAn opt-in suite runs a real create → update → delete lifecycle against a live Allure project. It is
deselected by default and skips itself unless credentials are present, so a normal pytest stays green:
export ALLURE_URL=https://allure.example.com
export ALLURE_TOKEN=... # token from an account with write access
export ALLURE_ENABLE_WRITE=true
export ALLURE_TEST_PROJECT_ID=63 # a throwaway project you can write to
pytest -m integration tests/integration -vIssues and PRs welcome. Keep the unit suite green (pytest) and the linter clean (ruff check,
ruff format); CI runs both on Python 3.10 / 3.11 / 3.12. See CHANGELOG.md for the
release history.
MIT © Mikhail Shchegolev
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``).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Allure project ID (discover via allure_list_projects). |
| Name | Required | Description |
|---|---|---|
| project_id | Yes | |
| total_test_cases | Yes | |
| automated_test_cases | Yes | |
| manual_test_cases | Yes | |
| automation_rate_pct | Yes | |
| last_launch_id | Yes | |
| last_launch_name | Yes | |
| last_launch_passed | Yes | |
| last_launch_failed | Yes | |
| last_launch_broken | Yes | |
| last_launch_total | Yes | |
| recent_launches_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool performs 3-4 API calls with progress reported via MCP Context, which is useful behavioral insight beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (summary, Args, Returns, Examples, Don't use). It is front-loaded with the purpose. While somewhat verbose, every section adds value and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully compensates for the lack of an output schema by providing a detailed return dict specification. It includes examples and instructions on interpreting results. For a simple one-param tool, it is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (project_id) is well described in the schema and the description adds examples of usage. With 100% schema coverage, the baseline is 3, and the description adds marginal value but not significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get summary statistics for an Allure project' and lists specific outputs (TC count, automation rate, last launch breakdown). It distinguishes from siblings by noting when not to use it (for per-test detail or full launch history, referencing sibling tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Don't use when' instructions with alternative tools (allure_get_test_results, allure_list_launches) and includes concrete examples for typical queries. This gives clear guidance on appropriate vs. inappropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| test_case_id | Yes | Allure test-case ID. | |
| include_scenario | No | Also fetch the manual scenario steps (one extra call). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| project_id | Yes | |
| automated | Yes | |
| description | Yes | |
| precondition | Yes | |
| expected_result | Yes | |
| status | Yes | |
| layer | Yes | |
| tags | Yes | |
| created_by | Yes | |
| last_modified_by | Yes | |
| steps | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds valuable detail: it returns a dict with specific keys, including 'steps' with 'depth' marker, and clarifies that steps are empty when 'include_scenario' is false. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear first sentence stating purpose, a contrast with a sibling, and a concise return format. It is appropriately sized—every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description complements it well by listing the dictionary keys and explaining the step structure. It covers the essential aspects of the tool's behavior and return value comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions. The description adds context about the structure of steps and the effect of 'include_scenario' (an extra call), which is not in the schema. Since schema coverage is 100%, baseline is 3, but the extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get one test case's full detail' and lists specific fields (status, layer, tags, steps). It explicitly distinguishes from the sibling 'allure_list_test_cases' which returns summaries, making it easy for an agent to select the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with 'allure_list_test_cases' and says 'Use it to read or review the actual content of a test case.' It also explains the effect of 'include_scenario', providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| test_case_id | Yes | Allure test-case ID. |
| Name | Required | Description |
|---|---|---|
| test_case_id | Yes | |
| count | Yes | |
| custom_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds behavioral context about the flattened return structure (field_id, field_name, value_id, value_name), which is not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff, and front-loaded with the main action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, high annotation coverage, and an output schema, the description is complete. It explains the return structure and differentiates from a sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (only parameter 'test_case_id' described). The description does not add parameter-specific info beyond the schema, but it explains the return format. Baseline 3 is appropriate since schema covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the custom-field values set on a test case.' It specifies the exact action and resource, and distinguishes from sibling 'allure_get_test_case' by noting that custom fields are not included there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'fetch them here when you need a test case's custom-field assignments.' It also mentions that these are not included in 'allure_get_test_case', providing clear differentiation from a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| launch_id | Yes | Allure launch ID. | |
| status | No | Filter by status. None returns all statuses. | |
| page | No | 0-based page. | |
| size | No | Items per page (1-200). |
| Name | Required | Description |
|---|---|---|
| launch_id | Yes | |
| count | Yes | |
| pagination | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive. The description adds detailed return structure (fields like id, name, status, duration_ms, error truncated to 300 chars) and pagination behavior, surpassing what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: purpose sentence, Args with bullet-like notation, Returns dict, Examples, and exclusion note. No wasted words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema, and sibling tools, the description covers all aspects: parameter details, return format, usage hints, and alternatives. It enables correct invocation without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by linking launch_id to another tool's output, explaining page is 0-based, size limits, and providing real-world examples. That justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves individual test results filtered by status, with a specific verb 'Get' and resource 'test results inside a launch'. It distinguishes from sibling 'allure_search_failed_tests' by noting that sibling handles FAILED+BROKEN together.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use (for FAILED+BROKEN) and points to alternative 'allure_search_failed_tests'. Also provides examples clarifying common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Allure project ID. |
| Name | Required | Description |
|---|---|---|
| project_id | Yes | |
| count | Yes | |
| custom_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the description adds value by detailing the returned fields and the negative/positive id distinction for built-in vs. custom fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each serving a purpose: stating the action, listing return fields, giving usage guidance, and providing extra id context. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, clear annotations, and an output schema (implied), the description is complete. It explains what the tool returns, when to use it, and references a related sibling tool, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for 'project_id'. The description does not add further parameter-level semantics but provides useful context about the tool's output, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'custom fields defined on a project', and differentiates from sibling tools by referencing 'allure_get_test_case_custom_fields' as a subsequent step. It also explains the output specifics (field_id, name, single_select, required) and the id sign convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool 'before reading a test case's values with allure_get_test_case_custom_fields', providing clear context. While it does not mention when not to use it, the recommendation is strong and helps the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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``).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Allure project ID. | |
| page | No | 0-based page. | |
| size | No | Items per page (1-100). |
| Name | Required | Description |
|---|---|---|
| project_id | Yes | |
| count | Yes | |
| pagination | Yes | |
| launches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety profile is known. The description adds value by detailing the return structure (pagination block, launch breakdown) and pagination behavior, which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples, Don't use when) and is concise. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (pagination, detailed return structure), the description covers all key aspects: parameter details, return format with field descriptions, usage examples, and sibling differentiation. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so parameters are well-documented. The description adds a usage hint for the 'size' parameter ('20 is usually enough for triage'), which provides additional context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List recent launches'), the resource ('launches for a project'), and ordering ('newest first'). It also distinguishes from sibling tools by explicitly stating alternatives in the 'Don't use when' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (to list launches with breakdown and pagination) and when not to use it, naming two alternative tools (allure_get_test_results, allure_search_failed_tests). This clearly helps the agent decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Allure project ID. |
| Name | Required | Description |
|---|---|---|
| project_id | Yes | |
| count | Yes | |
| layers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds value by detailing the return structure (dict with project_id, count, layers) and the negative id behavior for built-in layers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a return format note. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter with full schema coverage, output schema exists, and the description covers usage guidance, return structure, and special behavior (negative ids). It is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for 'project_id'. The tool description does not add any further parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'test layers defined in a project', and specifies the output (id, name). It also differentiates from sibling list tools by focusing on layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover valid layer names/ids before setting a layer on allure_create_test_case / allure_update_test_case', providing a clear use case and hinting at alternatives. It also notes built-in layer id ranges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 0-based page number. | |
| size | No | Items per page (1-500). |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by describing pagination parameters and the return structure (dict with count and list of projects with id, name, abbreviation). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, examples, and anti-guidance. Every sentence adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete description for a simple listing tool: covers usage, return format, examples, and when not to use. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the purpose of parameters in the context of project discovery and providing examples of usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all projects in the Allure TestOps instance. It uses specific verb 'list' and resource 'projects', and distinguishes from siblings by noting this tool discovers project IDs used by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use this first to discover project IDs and advises not to use when the project ID is already known, with a clear alternative of going directly to the target tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Allure project ID. |
| Name | Required | Description |
|---|---|---|
| project_id | Yes | |
| count | Yes | |
| statuses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by specifying the return structure (dict with project_id, count, statuses) and mentioning built-in statuses use negative ids, which aids understanding but does not heavily extend beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with the main action front-loaded. Every sentence serves a purpose: defining the function, guiding usage, and explaining return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one integer parameter, no nested objects) and the presence of an output schema, the description covers the tool's purpose, usage, and return values completely. It leaves no important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter project_id, so baseline is 3. The description does not add additional meaning beyond what the schema provides ('Allure project ID'). No extra semantics are offered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists test-case statuses with specific fields (id, name, color). It distinguishes from sibling tools like allure_list_projects and allure_list_test_cases because it focuses on statuses, not other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use this to discover valid status names/ids before setting a status on allure_create_test_case / allure_update_test_case.' It also notes that built-in statuses use negative ids, providing crucial context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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``).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Allure project ID. | |
| automated | No | True: only automated. False: only manual. None: both. | |
| owner | No | Allure username — narrows the result to TCs where the user is the creator OR the last modifier. Applied server-side via Allure RQL (see docstring). | |
| page | No | 0-based page. | |
| size | No | Items per page (1-200). |
| Name | Required | Description |
|---|---|---|
| project_id | Yes | |
| count | Yes | |
| pagination | Yes | |
| test_cases | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral details beyond annotations: audit fields and tags are only populated when owner is set (Allure endpoint constraint), owner is actually a union of createdBy and lastModifiedBy, the automated filter becomes client-side when owner is used, pagination implications, and the regex pattern preventing RQL injection. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, Examples, and a 'Don't use when' section. It is front-loaded with the primary purpose, and every section earns its place by providing necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, optional filters, server-side vs client-side behavior), the description covers all aspects: input semantics, output structure, edge cases (owner limitation), and practical examples. The presence of an output schema does not reduce the value of the detailed return format explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds significant semantic value: explains why owner maps to creator/modifier, details the trade-off with automated filtering, provides pattern explanation and injection prevention context, and gives concrete examples for using automated, page, and size parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists test cases for a project with optional automation and ownership filters. It details specific fields returned (id, name, automated, status, layer, etc.), distinguishing it from sibling tools like allure_get_project_statistics, which returns summary data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples (e.g., 'How many manual TCs does project 63 have?'), a 'Don't use when' section pointing to allure_get_project_statistics for automation percentages, and detailed context on when to set owner and associated trade-offs (e.g., client-side filtering).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Allure project ID. | |
| launch_id | No | Specific launch ID. If omitted, uses the most recent launch. | |
| limit | No | Max failures to return per status. |
| Name | Required | Description |
|---|---|---|
| launch_id | Yes | |
| failed_count | Yes | |
| results | Yes | |
| reason | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. The description adds that up to 3 API calls are made and progress is reported via MCP Context, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with summary, usage, args, returns, examples, and exclusions. Every sentence is purposeful and the description is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema, the description still explains return values and provides examples. It covers all necessary context for correct usage and triage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning: max failures per status (2*limit total), launch_id fallback to latest, and mentions ctx auto-injection. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds FAILED and BROKEN tests in a launch. It uses a specific verb and resource, and distinguishes from sibling tools like allure_get_test_results by focusing on failures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use for triage, with examples. A 'Don't use when' section specifies when to use alternative tools (allure_get_test_results). Context and alternatives are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.8.2allure_get_test_caseallure_get_test_case_custom_fieldsallure_list_custom_fieldsallure_list_layersallure_list_statusesv0.2.1allure_list_test_cases5 fields changedInput schema / properties / ownerAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 255,
+ "pattern": "^[A-Za-z0-9._@-]+$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Allure username — narrows the result to TCs where the user is the creator OR the last modifier. Applied server-side via Allure RQL (see docstring).",
+ "title": "Owner"
+}Output schema / $defs / TestCaseSummary / properties / created_byAdded value: +{
+ "title": "Created By",
+ "type": "string"
+}Output schema / $defs / TestCaseSummary / properties / last_modified_byAdded value: +{
+ "title": "Last Modified By",
+ "type": "string"
+}Output schema / $defs / TestCaseSummary / properties / tagsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "title": "Tags",
+ "type": "array"
+}Output schema / $defs / TestCaseSummary / requiredPrevious value: -[
- "id",
- "name",
- "automated",
- "status",
- "layer"
-]New value: +[
+ "id",
+ "name",
+ "automated",
+ "status",
+ "layer",
+ "created_by",
+ "last_modified_by",
+ "tags"
+]v0.1.2allure_get_project_statisticsallure_get_test_resultsallure_list_launchesallure_list_projectsallure_list_test_casesallure_search_failed_testsEach tool targets a distinct entity or operation (projects, statistics, test cases, launches, results, failures, custom fields, layers, statuses) with clear boundaries and explicit 'Don't use when' guidance to prevent misselection.
All tools follow a consistent 'allure_verb_noun' pattern (e.g., allure_list_projects, allure_get_test_case), making the naming predictable and easy to navigate.
With 11 tools, the set is well-scoped for a test management server, covering essential query and list operations without being overwhelming.
The tools are heavily read-focused, missing create/update/delete operations for test cases and other entities, which are fundamental to full lifecycle management. The descriptions reference 'allure_create_test_case' but it is not included.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official MCP server for Qase — manage test cases, runs, suites, defects via AI tools.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mshegolev/allure-testops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
