Provides tools for interacting with Jira AIO Test Case Management System, allowing users to get test case details, search test cases by project and folders, retrieve folder structures, and list projects.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jira-aio-mcp-server Get test case details for AT-TC-9"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for interacting with Jira AIO (All-in-One) Test Case Management System.
Get test case details from AIO
Search test cases by project and/or folders
Get folder structure of a project
Get list of all projects in AIO
Create and update test cases (title, description, preconditions, steps, status, priority)
Link Jira issues as requirements when creating a case
Create folders and subfolders
Related MCP server: Xray MCP Server
Node.js 18+
Access to a Jira instance with AIO Tests
Jira API token
Clone the repository
Install dependencies:
npm installBuild the project:
npm run buildAfter npm run build, restart the jira-aio MCP server in Cursor (Settings → MCP → Restart). Cursor does not reload build/index.js automatically.
The server reads JIRA_URL and JIRA_TOKEN from mcp.json:
~/.cursor/mcp.json
or a mcp.json in the project root
Example:
{
"mcpServers": {
"jira-aio": {
"command": "node",
"args": ["C:/path/to/jira-aio-mcp-server/build/index.js"],
"env": {
"JIRA_URL": "https://your-jira-instance:port",
"JIRA_TOKEN": "your-jira-token"
}
}
}
}JIRA_URL: Jira base URL, including port if needed
JIRA_TOKEN: Jira personal access token (Bearer)
Get detailed information about a specific test case.
projectKey: Project key (e.g. BON, MSG)
testCaseKey: Test case key (e.g. BON-TC-170)
Search for test cases within a project and optional folders.
projectId: Numeric Jira/AIO project ID (e.g. 11800)
folderIds: Optional array of folder IDs
Retrieve the folder tree of a project.
projectId: Numeric project ID (e.g. 11800)
List Jira projects available to the token.
No parameters
Update only the fields you pass. Other fields stay unchanged. The response includes rollback with previous values (especially steps).
projectKey, testCaseKey — required
title
description — empty string clears the field
precondition — empty string clears the field
status — Draft, Under Review, Published, Deprecated, Not integrated (IDs are read from the project config)
priority — Critical, High, Medium, Low, Lowest (IDs are read from the project config)
steps — full step list: { id?, step, expectedResult, data? }. Pass id to update an existing step. To undo, send rollback.steps from the previous response.
Plain URLs in description, preconditions, and steps are converted to clickable HTML links.
Create a test case. Steps and Jira requirements are saved after the case itself, same as the AIO UI.
projectKey, title — required
folderId or folder — folder ID, name, or path (e.g. 8616 or не актуально / тесты)
description, precondition
status — default Draft
priority
steps — [{ step, expectedResult, data? }]
requirements — Jira keys or IDs, e.g. ["BON-1642"]
Status, priority, and custom-field IDs are taken from the target project's AIO config. Do not hardcode BON IDs for other projects.
Create a folder or subfolder.
projectKey, name — required
parentId or parent — parent folder ID, name, or path. Omit to create at the project root.
Status and priority IDs differ between projects (BON Draft is 61, MSG Draft is 49).
update_case currently does not change tags, case type, estimated effort, or custom fields.
After code changes: npm run build, then restart MCP jira-aio in Cursor.
The server handles:
API request failures
Authentication issues
Invalid configuration
Missing required parameters
Bearer token authentication
HTTPS is supported
Tokens belong in mcp.json / environment variables, not in the repo
npm run build
npm test
npm run lintStack: TypeScript, Model Context Protocol SDK, Axios.
Create an AIO test case. Required: projectKey, title, folderId. Optional: description, precondition, status, priority, steps, requirements. Status/priority IDs are taken from the project config. Steps and Jira requirements are saved after create.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Шаги кейса. Каждый шаг: { step, expectedResult, data? } | |
| title | Yes | Название кейса | |
| folder | No | ID папки или имя / путь (например, тесты или не актуально / тесты) | |
| status | No | Статус: Draft, Under Review, Published, Deprecated, Not integrated. ID берутся из конфига проекта. По умолчанию Draft | |
| folderId | No | ID папки AIO (например, 8616). Можно вместо этого передать folder | |
| priority | No | Приоритет: Critical, High, Medium, Low, Lowest. ID берутся из конфига проекта | |
| projectKey | Yes | Ключ проекта в AIO (например, BON) | |
| description | No | Описание (Description) | |
| precondition | No | Предусловия (Pre-conditions) | |
| requirements | No | Jira-задачи для привязки: ключи (BON-1642) или числовые ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral details: it creates a case, uses project-config IDs for status/priority, and defers saving steps/requirements until after creation. It does not mention permissions or failure behavior, but the main side effects are disclosed.
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?
Two concise sentences organize required/optional parameters and important behavioral notes without redundancy. Easy to scan.
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 10-parameter create tool with no output schema, the description gives enough context to call it: required/optional fields, folder alternative is in schema, and special handling of config IDs/steps/requirements is called out. It does not explicitly mention return value or how to obtain folder/project IDs, but sibling tools cover discovery.
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 descriptions already cover all 10 parameters; the tool description adds useful context about config-derived status/priority IDs and post-create saving. However, it slightly conflicts with the schema by listing folderId as required when the schema marks it optional.
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?
States clearly that it creates an AIO test case, distinguishing it from get/search/update operations. The required/optional parameter summary and project config note further clarify scope.
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?
Provides when-to-use signal by naming creation and listing required vs optional parameters, plus notes about status/priority IDs and deferred saving of steps/requirements. It does not explicitly contrast with update_case, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an AIO test case folder. Required: projectKey, name. Optional: parentId or parent (folder ID, name, or path). Without parent the folder is created at the project root.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Название новой папки | |
| parent | No | ID, имя или путь родителя (например, не актуально) | |
| parentId | No | ID родительской папки (например, 1594). Можно вместо этого передать parent | |
| projectKey | Yes | Ключ проекта в AIO (например, BON) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral disclosure burden. It adds useful placement behavior ('Without parent the folder is created at the project root') and clarifies the accepted forms for parent, but it does not mention permissions, conflict/overwrite behavior, or what the caller can expect as a result. This is adequate but has clear gaps.
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 compact and each sentence contributes a distinct fact: the operation, required inputs, optional parent alternatives, and the root-level default. There is no filler, and the most important 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?
For a straightforward creation tool with a fully described input schema and no output schema, the description covers the core invocation contract: required fields, optional parent resolution, and the root fallback. The only notable gaps are expected return shape and error/conflict behavior, which are not essential for selecting and invoking the tool correctly.
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%, so the schema already documents all four parameters and even notes that parent can be used instead of parentId. The description repeats the required/optional split and rephrases parent's accepted forms as 'folder ID, name, or path,' which improves readability but adds little semantic information beyond the schema. A baseline of 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 opens with a concrete action and object: 'Create an AIO test case folder.' It clearly identifies the resource as a folder and separates it from sibling tools like create_case or get_aio_folder, while also stating the minimum identifiers needed to perform the operation.
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 marks required vs optional inputs: 'Required: projectKey, name. Optional: parentId or parent' and explains the default behavior when no parent is supplied. It does not explicitly name an alternative tool or state when not to use this tool, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get folder structure of a project
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ID проекта в AIO (например, 11502) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'get' implies read-only, but it does not explicitly state side effects, return behavior, or error handling. The description lacks detail on what the structure includes (e.g., nested folders, names, IDs).
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 a single, direct sentence with no unnecessary words. It is appropriately terse for such a simple retrieval operation.
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 is minimal and lacks critical context such as when to use it, what the return format is, and whether it has side effects. For a simple get, it is functional but incomplete, especially given the lack of annotations.
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 only parameter, projectId, is fully described with its semantic meaning ('ID in AIO') and a concrete example ('11502'). This goes beyond the schema's type and required fields, providing clear context for use.
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 ('Get') and the resource ('folder structure of a project'). It is distinguishable from sibling tools like get_aio_testcase or create_folder, though 'folder structure' could be more precise (e.g., whether it returns a tree or a flat list).
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?
There is no guidance on when to use this tool versus its siblings (e.g., when you need a folder hierarchy vs. a project list). No alternatives or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of all projects in AIO
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It signals a read-only listing operation via 'Get list', which is the core behavioral trait, but it does not disclose details such as output shape, pagination, authentication needs, or whether projects are returned as summary objects or full records.
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 a single efficient sentence with no filler. It front-loads the action and resource, and every word contributes to understanding what the tool does.
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 this is a zero-parameter tool with no output schema and no annotations, the description is mostly complete for an agent to decide to call it. The only notable gap is the lack of any information about the returned shape, but for a simple get-all listing this is a minor omission.
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 tool has zero parameters, and the schema description coverage is 100% vacuously. The description adds useful context by specifying 'all projects in AIO', which clarifies scope even though there are no inputs to document.
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 ('Get'), the resource ('projects'), and the scope ('all projects in AIO'). This distinguishes it from sibling tools that operate on testcases, folders, or individual cases, so an agent can tell them apart without inspecting schemas.
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 clear context: use this tool when you need the full list of all AIO projects. It does not explicitly discuss exclusions or alternatives, but for a simple get-all listing this is reasonably apparent from the resource name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get test case details from AIO
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | Ключ проекта в AIO (например, AT) | |
| testCaseKey | Yes | Ключ тест-кейса (например, AT-TC-9) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get test case details', which implies a read operation, but does not mention return format, error behavior, required permissions, or anything about side effects.
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 a single concise sentence with no redundancy. It is appropriately short for a simple getter tool, though it could include more contextual 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 description does not explain how it differs from search_aio_testcase, what 'details' entails, or what the caller should expect as output. Given no output schema or annotations, this is a significant gap for a tool with minimal documentation.
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%: both projectKey and testCaseKey are described with examples. The description adds no additional parameter meaning, so a baseline score of 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 states a specific verb ('Get'), resource ('test case details'), and platform ('AIO'). It is clear and distinct from siblings like search_aio_testcase, though it does not explicitly contrast them.
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?
No guidance is provided about when to use this tool versus search_aio_testcase or other sibling tools. The intended usage is only implied by the name and required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search test cases by project and/or folders
| Name | Required | Description | Default |
|---|---|---|---|
| folderIds | No | Array of folder IDs to search within (optional) | |
| projectId | Yes | ID проекта в AIO (например, 11502) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Search test cases' and does not mention return format, pagination, matching behavior, or the effect of omitting folderIds. The agent is left without information about what the search operation actually returns.
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 a single, efficient sentence with no filler. The verb and resource are front-loaded, making the purpose immediately clear.
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 no output schema and no annotations, so the description should explain what the search returns, but it does not. The description is minimally sufficient to attempt a call, yet incomplete for an agent to understand the result structure or behavior of the folder filter.
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%, so the baseline is 3. The phrase 'by project and/or folders' loosely maps to projectId and folderIds, but does not add any meaning beyond the schema's own property descriptions.
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 uses a specific verb ('Search') and names the exact resource ('test cases') plus the two filtering criteria ('by project and/or folders'). This clearly differentiates it from sibling tools like get_aio_testcase, create_case, and create_folder.
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 implies when to use the tool: when you need test cases filtered by project and/or folders. However, it does not explicitly state alternatives, exclusions, or when to prefer a sibling tool like get_aio_testcase instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an AIO test case. Changes only explicitly passed fields (title, description, precondition, status, priority, steps). Response includes rollback with previous values, especially for steps.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Полный список шагов. Каждый шаг: { step, expectedResult, data? }. Если есть id — обновляется существующий шаг. Чтобы откатить, передай rollback.steps из ответа. | |
| title | No | Новое название кейса | |
| status | No | Статус: Draft, Under Review, Published, Deprecated, Not integrated — или ID из конфига проекта | |
| priority | No | Приоритет: Critical, High, Medium, Low, Lowest — или ID из конфига проекта | |
| projectKey | Yes | Ключ проекта в AIO (например, BON) | |
| description | No | Описание (Description). Пустая строка очищает поле | |
| testCaseKey | Yes | Ключ тест-кейса (например, BON-TC-170) | |
| precondition | No | Предусловия (Pre-conditions). Пустая строка очищает поле |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses that only explicitly passed fields are updated and that the response includes rollback values with previous values, especially for steps. This covers the most important side effects and rollback capability, though auth and failure modes are not mentioned.
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?
Two sentences with no filler: the first states the operation and scope, the second delivers the key behavioral and rollback information. Critical details are front-loaded and every sentence earns its place.
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 an update operation with 8 parameters and no output schema, the description covers purpose, partial-update behavior, and response rollback content. The schema covers the parameter semantics. Missing explicit sibling differentiation and error/auth context, but this is not a major gap given the strong schema and concise tool description.
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 the schema already documents each parameter in detail. The description adds partial-update semantics but does not meaningfully clarify individual parameters beyond the schema, so the baseline score of 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 operation ('Update') and the resource ('AIO test case'), and enumerates the exact fields that can be changed. This makes it immediately distinguishable from create_case and the read-only get/search siblings.
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 usage context is implied but not explicit: updating an existing test case versus creating a new one or retrieving one. There is no direct mention of create_case or search/get alternatives, so the agent must infer when to choose this tool.
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.
v1.0.0create_casecreate_folderget_aio_foldersget_aio_projectsget_aio_testcasesearch_aio_testcaseupdate_caseScored across 7 tools
Each tool targets a distinct action or resource: get vs search, projects vs folders vs test cases, and create vs update are clear. There is no meaningful overlap that would cause an agent to select the wrong tool.
The tool naming is readable but inconsistent: four tools follow a get_aio_* pattern, while three use bare verb_noun forms like create_case and create_folder. This mix of conventions makes the set feel less unified, even though the verb and noun components are clear.
Seven tools is well-scoped for an AIO test-case management server: project discovery, folder navigation, test-case search/retrieval, creation, and update are all represented. Each tool serves a clear purpose without redundancy.
The set covers project listing, folder handling, and test-case create/read/update/search, but there is no delete operation for either test cases or folders. This notable lifecycle gap prevents full end-to-end management of AIO test cases.
An MCP server that provides access to Testiny projects, test cases and test runs
Connect to Atlassian Jira, Confluence, Loom, and more to search, create, and manage your work.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Manage test suites, run tests, view results, and automate QA workflows via AI with testRigor.
