The QA Sphere MCP Server enables interaction with QA Sphere test management via APIs, allowing LLMs to access test case information. You can:
Retrieve specific test cases using unique markers (e.g., BDI-123)
Get project information using project codes
List all projects in the QA Sphere account
List test cases with options for filtering, pagination, sorting, and including related data
List test case folders with pagination and sorting options
List all tags defined within a project
Supports running the QA Sphere MCP server using Node.js, allowing interaction with QA Sphere's test management system
Click on "Install 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., "@qasphere-mcp show me test cases for the login feature"
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.
This repository is archived and no longer maintained.
QA Sphere now serves an MCP server directly — there is no need to run this standalone package. The hosted server is always up to date with the QA Sphere API, exposes the full set of tools allowed by your role, and needs nothing installed locally.
Recommended setup: in QA Sphere go to Settings ⚙️ → MCP Server, pick your assistant and access level, add an API key, and follow the setup instructions shown there. See the QA Sphere documentation for details.
The instructions below are kept for reference only. While running the standalone
server, it points this out once per session; set
QASPHERE_MCP_HIDE_MIGRATION_NOTICE=1 to silence that.
A Model Context Protocol server for the QA Sphere test management system.
This integration enables Large Language Models (LLMs) to interact directly with QA Sphere test cases, allowing you to discover, summarize, and chat about test cases. In AI-powered IDEs that support MCP, you can reference specific QA Sphere test cases within your development workflow.
Node.js (>=22)
QA Sphere account with API access
API key from QA Sphere (Settings ⚙️ → API Keys → Add API Key)
Your company's QA Sphere URL (e.g., example.eu2.qasphere.com)
Related MCP server: MCP RAG Agent Server
This server is compatible with any MCP client. Configuration instructions for popular clients are provided below.
Navigate to Claude → Settings → Developer → Edit Config
Open claude_desktop_config.json
Add the QA Sphere configuration to the mcpServers dictionary
Go to Settings... → Cursor settings → Add new global MCP server
Add the QA Sphere configuration
Click the button below to automatically install and configure the QA Sphere MCP server:
Open 'Tools' and press 'New'
Complete the form with:
Tool key: qasphere
Command: npx -y qasphere-mcp
Environment variables (see below)
For any MCP client, use the following configuration format:
{
"mcpServers": {
"qasphere": {
"command": "npx",
"args": ["-y", "qasphere-mcp"],
"env": {
"QASPHERE_TENANT_URL": "your-company.region.qasphere.com",
"QASPHERE_API_KEY": "your-api-key"
}
}
}
}Replace the placeholder values with your actual QA Sphere URL and API key.
This project is licensed under the MIT License - see the LICENSE file for details.
If you encounter any issues or need assistance, please file an issue on the GitHub repository.
Create a new test case in QA Sphere. Supports both standalone and template test cases with various options like steps, tags, requirements, and parameter values for templates.
| Name | Required | Description | Default |
|---|---|---|---|
| pos | No | Position within the folder (0-based index) | |
| tags | No | List of tag titles | |
| type | Yes | Type of test case. A 'template' test case uses `${var}` placeholders in its title, precondition, and step fields; each entry in `parameterValues` substitutes those placeholders to generate one filled test case. | |
| links | No | Additional links relevant to the test case | |
| steps | No | List of test case steps | |
| title | Yes | Test case title. In template test cases, may contain `${var}` placeholders that are substituted via `parameterValues` to produce filled test case titles. | |
| comment | No | Test case precondition (HTML format). DEPRECATED — prefer the `precondition` object | |
| isDraft | No | Whether to create as draft | |
| folderId | Yes | ID of the folder where the test case will be placed. Use upsert_folders tool to create new folders or get existing folders. | |
| priority | Yes | Test case priority | |
| projectCode | Yes | Project code identifier (e.g., BDI) | |
| customFields | No | Custom field values. Keys are custom field system names. Custom fields must exist in the project (created via the web UI). | |
| precondition | No | Test case precondition: either `{sharedPreconditionId}` to reference a shared one, or `{text}` for a standalone precondition | |
| requirements | No | Test case requirements | |
| parameterValues | No | One set of parameter substitutions per filled test case to generate from the template. Applies only when `type` is `template`; ignored for standalone test cases. A placeholder with no matching key is left untouched (e.g., `${action}` with no `action` value stays literal). | |
| filledTCaseTitleSuffixParams | No | Parameter names whose substituted values are appended to each filled test case title for disambiguation (e.g., pass `["env"]` to suffix titles with the `env` value). |
| Name | Required | Description |
|---|---|---|
| id | Yes | Unique identifier of the created test case |
| seq | Yes | Sequence number of the test case in the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states the creation action and lists options, but does not reveal side effects, authorization needs, idempotency, or constraints like folder existence.
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, well-structured sentence that front-loads the core purpose. No extraneous 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 tool's high complexity (16 params, nested objects, templates), the description is too brief. It lacks guidance on parameter interdependencies (e.g., type=template requires parameterValues) and prerequisites like folder existence.
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 description does not add extra parameter meaning beyond the schema's detailed 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?
Description clearly states the action ('Create') and resource ('test case in QA Sphere'), distinguishes between standalone and template types, and mentions key options. It is distinct from sibling tools like update_test_case.
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 explicit when-to-use or alternatives compared to siblings. The mention of standalone vs template provides some usage context, but no guidance on prerequisites or when to use update_test_case instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a project information from QA Sphere using a project code (e.g., BDI). You can extract PROJECT_CODE from URLs https://acme-corp.eu2.qasphere.com/project/%PROJECT_CODE%/...
| Name | Required | Description | Default |
|---|---|---|---|
| projectCode | Yes | Project code identifier (e.g., BDI) |
| Name | Required | Description |
|---|---|---|
| id | Yes | Unique identifier of the project |
| code | Yes | Project code (e.g., BDI) |
| links | Yes | Project links |
| title | Yes | Project title |
| createdAt | Yes | Project creation time (ISO 8601) |
| updatedAt | Yes | Project last-update time (ISO 8601) |
| archivedAt | Yes | Project archival time (ISO 8601); null if the project is not archived |
| overviewTitle | Yes | Project overview title |
| overviewDescription | Yes | Project overview description (HTML) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. Implies a read-only, safe operation but does not explicitly mention authentication needs, error responses, or side effects. Adequate for a simple lookup but could be more transparent.
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 zero wasted words. First sentence states purpose, second gives practical usage hint. Perfectly front-loaded and concise.
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 for a simple lookup tool with output schema present. No need to describe return format. Provides enough context given the sibling list of 15 tools.
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?
Parameter 'projectCode' is fully defined in schema with pattern and description. The description adds value by explaining how to extract the code from URLs, going beyond schema. No additional 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?
Clearly states verb 'Get' and resource 'project information', specifies the unique identifier 'project code' (e.g., BDI), and provides a practical derivation from URLs. Distinguishes from siblings like list_projects.
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 instructs when to use (when you have a project code) and gives URL extraction method. Could be improved by contrasting with list_projects for discovering codes, but the guidance is already clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a test case from QA Sphere using a marker in the format PROJECT_CODE-SEQUENCE (e.g., BDI-123). You can use URLs like: https://acme-corp.eu2.qasphere.com/project/%PROJECT_CODE%/tcase/%SEQUENCE%?any Extract %PROJECT_CODE% and %SEQUENCE% from the URL and use them as the marker.
| Name | Required | Description | Default |
|---|---|---|---|
| marker | Yes | Test case marker in format PROJECT_CODE-TEST_CASE_SEQUENCE (e.g., BDI-123) |
| Name | Required | Description |
|---|---|---|
| id | Yes | Unique identifier of the test case |
| pos | Yes | Ordered position (0-based) of the test case in its folder |
| seq | Yes | Sequence number of the test case within its project (assigned incrementally) |
| tags | No | List of test case tags |
| type | Yes | Type of the test case. Known values: "standalone" | "template" | "filled" |
| files | Yes | List of files attached to the test case |
| links | Yes | Additional links relevant to the test case |
| steps | No | List of test case steps |
| title | Yes | Title of the test case |
| comment | Yes | Test case precondition text (HTML). DEPRECATED — prefer the `precondition` object |
| isDraft | Yes | Whether the test case is still in draft state |
| isEmpty | Yes | Whether the test case is empty (has no precondition and steps) |
| version | Yes | Version of the test case. Updates (except folder/pos) create a new version |
| authorId | Yes | Unique identifier of the user who added the test case |
| folderId | Yes | Identifier of the folder where the test case is placed |
| legacyId | Yes | Legacy identifier of the test case (empty string if none is set) |
| priority | Yes | Priority of the test case. Known values: "high" | "medium" | "low" |
| createdAt | Yes | Test case creation time (ISO 8601) |
| updatedAt | Yes | Test case last-update time (ISO 8601) |
| customFields | No | Custom field values |
| precondition | No | Test case precondition object (may be a shared or standalone precondition) |
| requirements | No | Test case requirements |
| isLatestVersion | Yes | Whether this is the latest version of the test case |
| numFilledTCases | No | Number of corresponding filled test cases (only for template test cases) |
| parameterValues | No | Parameter substitutions for filled test cases (only for template test cases) |
| templateTCaseId | No | Corresponding template test case ID (only for filled test cases) |
| filledTCaseTitleSuffixParams | No | Parameter names whose substituted values are appended to each filled test case title for disambiguation (only for template test cases). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Clearly a read operation (Get), no side effects implied. Does not mention authentication or rate limits, but for a simple get tool this is acceptable. The output schema exists, so return behavior is documented externally.
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. First states purpose, second provides critical usage nuance (URL conversion). No wasted words; every sentence earned 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?
Given simple tool (1 param, output schema present), description fully covers how to identify the test case. No gaps – the agent has all needed info to invoke 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?
Single parameter (marker) with schema coverage 100%. Description adds significant value beyond schema by explaining the format and providing a real-world URL extraction example, making it easy for the agent to construct the parameter correctly.
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?
Clearly states 'Get a test case' with specific resource (test case) and verb (get). Distinguishes from siblings like create/update/list_test_cases by focusing on retrieval by marker. Includes the exact marker format and URL extraction, leaving no ambiguity.
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?
Describes how to use (via marker or URL), implicitly indicating when to use (when you have a marker) vs. alternatives for listing/searching. Lacks explicit exclusion statements but the specific retrieval context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all custom fields available for a project. Useful when creating or updating test cases with custom field values — use the systemName property as the key on the customFields parameter of create_test_case / update_test_case. Only enabled fields should be used. Custom fields allow you to extend test cases with additional metadata specific to your organization's needs.
| Name | Required | Description | Default |
|---|---|---|---|
| projectCode | Yes | Project code identifier (e.g., BDI) |
| Name | Required | Description |
|---|---|---|
| customFields | Yes | List of custom fields defined in the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It describes listing all custom fields for a project but doesn't disclose whether disabled fields are included or if there's any filtering/pagination. The note about 'only enabled fields should be used' suggests the list may contain disabled ones, which is ambiguous.
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 (3 sentences) and front-loaded with main action. Every sentence adds value: purpose, usage, and a constraint. No 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 simple single-parameter tool with output schema, description covers core usage and ties back to sibling tools. Could be slightly improved by clarifying list behavior regarding disabled fields, but sufficient for the complexity.
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% (projectCode has a description). Description adds usage context for the parameter's purpose but doesn't elaborate on the parameter itself beyond the schema. 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?
Description clearly states it lists custom fields for a project, and distinguishes itself from sibling tools like list_folders by focusing on custom fields. It specifies the resource ('custom fields') and the scope ('for a project').
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 to use (when creating/updating test cases) and provides usage guidance (use systemName as key, only enabled fields). Lacks explicit 'when not to use' or alternative tools, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List folders for test cases within a specific QA Sphere project. Allows pagination and sorting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of folders to return (0-5000, defaults to 20). Use 0 to fetch only the total count | |
| offset | No | Number of folders to skip before returning results (defaults to 0) | |
| sortField | No | Field to sort results by | |
| sortOrder | No | Sort direction (ascending or descending) | |
| projectCode | Yes | Project code identifier (e.g., BDI) |
| Name | Required | Description |
|---|---|---|
| data | Yes | List of folders |
| limit | Yes | Limit applied to the query |
| total | Yes | Total number of items available |
| offset | Yes | Offset applied to the query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose pagination and sorting behavior, which is useful context. However, it does not explicitly state that the operation is read-only, whether it returns only folders at the top level or all nested folders, or any other side-effect relevant behavior. For a simple list operation, the disclosure is adequate but not rich.
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 with no filler. The main action and scope are in the first sentence, and capability highlights are in the second. Every word adds value, and it front-loads the most important information.
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 that an output schema exists and the input schema has 100% parameter coverage, the description is largely complete for a straightforward listing tool. It communicates the scope (within a project), the core operation (list folders), and the key features (pagination, sorting). The only shortfall is the lack of explicit guidance on when to use this over related listing tools, but that is a minor gap for such a simple 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%, and the input schema already documents all five parameters with clear descriptions, defaults, and constraints. The description's mention of pagination and sorting adds no meaning beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.
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 and resource: list folders within a QA Sphere project. It also adds the pagination and sorting capabilities, but it does not explicitly distinguish itself from sibling tools by name. The resource 'folders' is unique among the listed siblings, which makes the purpose reasonably clear.
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 phrase 'within a specific QA Sphere project' implies that projectCode is required, and the mention of pagination and sorting hints at when the optional parameters matter. However, there is no explicit guidance about when to choose this tool over alternatives like list_test_cases or upsert_folders, and no exclusions or when-not-to-use guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all projects from current QA Sphere TMS account (qasphere.com)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| projects | Yes | List of projects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation but does not explicitly confirm safety (no side effects, authentication needs, or rate limits). For a zero-parameter list tool, the behavioral disclosure is minimal and insufficient.
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, front-loaded sentence with 16 words. It contains no redundancy and every word adds value. It is optimally concise for the simplicity of the tool.
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 no parameters and an output schema exists, the description adequately states the return type (list of all projects) and source (current account). However, it could mention filtering or ordering if applicable, but the existing completeness is acceptable for a simple list.
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?
There are no parameters (input schema empty, schema description coverage 100%). The description correctly does not need to add parameter details. Baseline for zero parameters is 4, and the description fulfills this without overcomplicating.
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 the specific verb 'Get' and identifies the resource 'list of all projects' from 'current QA Sphere TMS account'. It clearly states the action and object, but does not differentiate from sibling tools like 'get_project' (single project) or other list tools, missing an opportunity to clarify when to use this one.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, limitations, or context. It merely states what the tool does, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List requirements linked to test cases in a project. Requirements are references to external documentation or specifications (like Jira issues) that test cases verify. Use this tool to find requirement IDs when you need to filter test cases by requirement using list_test_cases with the requirementIds parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Include optional fields like the number of test cases linked to each requirement | |
| sortField | No | Field to sort results by | |
| sortOrder | No | Sort direction (ascending or descending). Requires sortField. | |
| projectCode | Yes | Project code identifier (e.g., BDI) |
| Name | Required | Description |
|---|---|---|
| requirements | Yes | List of requirements defined in the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not mention permissions, pagination, rate limits, or whether results are limited to requirements with linked test cases.
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 that convey purpose and usage with zero wasted 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?
Includes practical context about external references and linkage to test cases for filtering. With output schema present, minimal gap.
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 clear descriptions for each parameter. Description adds no extra meaning to parameters 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?
States 'List requirements linked to test cases in a project' with specific verb and resource, and distinguishes requirements as external documentation references.
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 tells when to use: 'to find requirement IDs when you need to filter test cases by requirement using list_test_cases with the requirementIds parameter.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List test cases from a project in QA Sphere. Supports pagination and various filtering options. Usually it makes sense to call get_project tool first to get the project context.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by tag IDs | |
| draft | No | Filter draft vs published test cases | |
| limit | No | Maximum number of test cases to return (0-5000, defaults to 20). Use 0 to fetch only the total count | |
| types | No | Filter by test case type | |
| offset | No | Number of test cases to skip before returning results (defaults to 0) | |
| search | No | Search term to filter test cases | |
| folders | No | Filter by folder IDs | |
| include | No | Related data to include in the response (not present by default) | |
| sortField | No | Field to sort results by | |
| sortOrder | No | Sort direction (ascending or descending). Requires sortField. | |
| priorities | No | Filter by priority levels | |
| projectCode | Yes | Project code identifier (e.g., BDI) | |
| customFields | No | Filter by custom field values. Keys are custom field system names (without the `cf_` prefix); values are arrays of allowed values. | |
| requirementIds | No | Filter by requirement IDs | |
| templateTCaseIds | No | Filter filled test cases by their parent template test case IDs |
| Name | Required | Description |
|---|---|---|
| data | Yes | List of test cases |
| limit | Yes | Limit applied to the query |
| total | Yes | Total number of filtered test cases |
| offset | Yes | Offset applied to the query |
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 conveys the essential read-only listing behavior and mentions pagination and filtering, but these facts mostly restate what the schema already documents (limit, offset, filter parameters), and it does not disclose defaults such as whether draft test cases are returned by default or how multiple filters combine. The low-risk nature of a read-only list tool partially offsets this thinness.
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?
Three short sentences (~30 words) with the purpose front-loaded and no filler. The second sentence is slightly redundant with the schema's pagination/filter parameters, but it aids quick capability scanning, and the get_project hint earns its place as cross-tool guidance.
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 15-parameter tool with nested objects and an output schema present, the description delivers adequate high-level orientation and a useful sequencing hint, and return shapes are covered by the output schema. However, it lacks guidance on how filters combine and does not route users to get_test_case for single-case lookups, which would be valuable at this complexity level. Some additional orientation would push this higher.
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% and the parameter descriptions are rich (e.g., 'Use 0 to fetch only the total count', the customFields format caveat, sortOrder requiring sortField). The description adds only the generic phrase 'various filtering options,' which does not exceed what the schema provides, so the baseline 3 applies.
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 a specific verb ('List') and resource ('test cases from a project in QA Sphere'), and the phrase 'Supports pagination and various filtering options' clarifies the listing scope. It does not explicitly differentiate from siblings like get_test_case or list_test_cases_tags, which prevents a 5.
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 closing sentence provides actionable sequencing guidance: 'Usually it makes sense to call get_project tool first to get the project context.' This is genuine usage advice, but there is no when-not-to-use guidance or explicit comparison with alternatives such as get_test_case for a single case or list_test_cases_tags for tag-focused listing, so routing between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tags defined within a specific QA Sphere project.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Include optional fields like the number of test cases using each tag | |
| sortField | No | Field to sort results by | |
| sortOrder | No | Sort direction (ascending or descending). Requires sortField. | |
| projectCode | Yes | Project code identifier (e.g., BDI) |
| Name | Required | Description |
|---|---|---|
| tags | Yes | List of tags defined in the project |
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 states 'List all tags' without addressing pagination, authentication, side effects, or rate limits, leaving significant gaps for an agent.
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 that clearly states the tool's purpose with no extraneous information, earning its place efficiently.
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 simple list tool with a known output schema (not shown), the description is mostly complete. It could mention optional fields like sorting or inclusion of test case counts, but the schema compensates. Still, it lacks context about the output structure.
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 input schema has 100% description coverage, so the baseline is 3. The tool description adds no additional meaning beyond what the schema provides for the 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 uses the specific verb 'list' and resource 'tags' with a clear scope ('within a specific QA Sphere project'), effectively distinguishing it from sibling tools like list_test_cases or list_folders.
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 that the tool requires a project code by saying 'within a specific QA Sphere project', but it does not explicitly state when to use it versus alternatives or provide any exclusions or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing test case in QA Sphere. Only users with role User or higher are allowed to update test cases. Optional fields can be omitted to keep the current value.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | List of tag titles | |
| links | No | Additional links relevant to the test case | |
| steps | No | List of test case steps | |
| title | No | Test case title. In template test cases, may contain `${var}` placeholders that are substituted via `parameterValues` to produce filled test case titles. | |
| comment | No | Test case precondition (HTML format). DEPRECATED — prefer the `precondition` object | |
| isDraft | No | To publish a draft test case. A published test case cannot be converted to draft | |
| priority | No | Test case priority | |
| projectCode | Yes | Project code identifier (e.g., BDI) | |
| customFields | No | Custom field values to update. Only the specified keys are modified; others remain unchanged. | |
| precondition | No | Test case precondition: either `{sharedPreconditionId}` to reference a shared one, or `{text}` for a standalone precondition | |
| requirements | No | Test case requirements | |
| parameterValues | No | Full replacement of the template test case parameter values. Applies only when the target is a template test case: entries with `tcaseId` update the corresponding filled test case; entries without `tcaseId` generate a new one; any existing filled test case whose `tcaseId` is not present in this array will be deleted. To preserve existing filled test cases while appending, include their current `{tcaseId, values}` pairs. | |
| tcaseOrLegacyId | Yes | Test case identifier (can be one of test case UUID, sequence or legacy ID). Note: when the target is a `filled` test case, only `priority` can be updated directly; to change other fields, update the parent template or use `parameterValues`. | |
| filledTCaseTitleSuffixParams | No | Parameter names whose substituted values are appended to each filled test case title for disambiguation (e.g., pass `["env"]` to suffix titles with the `env` value). Applies only to template test cases. |
| Name | Required | Description |
|---|---|---|
| message | Yes | Success message |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses authorization and optional field behavior, but lacks detail on side effects (e.g., template test case parameter handling). Adequate but not rich.
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, front-loaded with purpose, no wasted 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?
Complex tool (14 params, nested objects) but description is simplistic; lacks guidance on template test cases, parameterValues, and return value.
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?
100% schema coverage means schema does heavy lifting; description adds minimal extra meaning beyond restating that optional fields can be omitted.
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?
Clearly states the verb ('update') and resource ('existing test case in QA Sphere'), and distinguishes from siblings like create_test_case.
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 role-based usage constraint and mentions optional field behavior, but no explicit when-not or alternatives beyond implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates or updates multiple folders in a single request using folder path hierarchies. Automatically creates nested folder structures and updates existing folders' comments. Returns an array of folder ID arrays, each representing the full folder path hierarchy as an array of folder IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| folders | Yes | Array of folder requests to create or update | |
| projectCode | Yes | Project code identifier (e.g., BDI) |
| Name | Required | Description |
|---|---|---|
| ids | Yes | One folder-ID array per input folder, representing the full path hierarchy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses creation/update, automatic nested structure creation, comment updates, and the return format. It does not cover potential side effects like permissions, but it is fairly transparent.
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, no extraneous information. Front-loaded with the primary action ('Creates or updates multiple folders'). Every sentence is necessary and well-structured.
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 no annotations and an output schema, the description covers the operation, behavior (nested creation, comment update), and return value. It could mention uniqueness of paths or error handling, but it is largely complete given the complexity.
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 value by explaining how path hierarchies work and that comments apply to leaf folders, which goes beyond the schema 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 clearly states the tool creates or updates multiple folders using folder path hierarchies, which distinguishes it from sibling tools like list_folders. The verb 'upsert' and resource 'folders' are specific and unambiguous.
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 usage for batch folder operations, but does not explicitly state when to use alternatives (e.g., single folder creation) or when not to use it. It mentions 'multiple folders in a single request,' which provides some guidance.
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.5.0list_folders11 fields changedInput schema / properties / limit / defaultPrevious value: -100New value: +20Input schema / properties / limit / descriptionPrevious value: -"Number of items per page"New value: +"Maximum number of folders to return (0-5000, defaults to 20). Use 0 to fetch only the total count"Input schema / properties / limit / maximumAdded value: +5000Input schema / properties / limit / minimumAdded value: +0Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Number of folders to skip before returning results (defaults to 0)",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / pageRemoved value: -{
- "description": "Page number for pagination",
- "type": "number"
-}Output schema / properties / limit / descriptionPrevious value: -"Number of items per page"New value: +"Limit applied to the query"Output schema / properties / offsetAdded value: +{
+ "description": "Offset applied to the query",
+ "type": "number"
+}Output schema / properties / pageRemoved value: -{
- "description": "Current page number",
- "type": "number"
-}Output schema / requiredPrevious value: -[
- "total",
- "page",
- "limit",
- "data"
-]New value: +[
+ "total",
+ "offset",
+ "limit",
+ "data"
+]list_test_cases10 fields changedInput schema / properties / limit / descriptionPrevious value: -"Number of items per page"New value: +"Maximum number of test cases to return (0-5000, defaults to 20). Use 0 to fetch only the total count"Input schema / properties / limit / maximumAdded value: +5000Input schema / properties / limit / minimumAdded value: +0Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Number of test cases to skip before returning results (defaults to 0)",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / pageRemoved value: -{
- "description": "Page number for pagination",
- "type": "number"
-}Output schema / properties / limit / descriptionPrevious value: -"Number of test cases per page"New value: +"Limit applied to the query"Output schema / properties / offsetAdded value: +{
+ "description": "Offset applied to the query",
+ "type": "number"
+}Output schema / properties / pageRemoved value: -{
- "description": "Current page number",
- "type": "number"
-}Output schema / requiredPrevious value: -[
- "total",
- "page",
- "limit",
- "data"
-]New value: +[
+ "total",
+ "offset",
+ "limit",
+ "data"
+]v0.4.1create_test_caseget_project3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / projectCode / patternPrevious value: -"^[A-Z0-9]+$"New value: +"^[A-Z0-9]{2,5}$"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "archivedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Project archival time (ISO 8601); null if the project is not archived"
+ },
+ "code": {
+ "description": "Project code (e.g., BDI)",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "Project creation time (ISO 8601)",
+ "type": "string"
+ },
+ "id": {
+ "description": "Unique identifier of the project",
+ "type": "string"
+ },
+ "links": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "text": {
+ "description": "Title of the link",
+ "type": "string"
+ },
+ "url": {
+ "description": "URL of the link",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Project links"
+ },
+ "overviewDescription": {
+ "description": "Project overview description (HTML)",
+ "type": "string"
+ },
+ "overviewTitle": {
+ "description": "Project overview title",
+ "type": "string"
+ },
+ "title": {
+ "description": "Project title",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Project last-update time (ISO 8601)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "code",
+ "title",
+ "overviewTitle",
+ "overviewDescription",
+ "links",
+ "createdAt",
+ "updatedAt",
+ "archivedAt"
+ ],
+ "type": "object"
+}get_shared_preconditionget_shared_stepget_test_case4 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / marker / descriptionPrevious value: -"Test case marker in format PROJECT_CODE-SEQUENCE (e.g., BDI-123)"New value: +"Test case marker in format PROJECT_CODE-TEST_CASE_SEQUENCE (e.g., BDI-123)"Input schema / properties / marker / patternPrevious value: -"^[A-Z0-9]+-\\d+$"New value: +"^[A-Z0-9]{2,5}-\\d+$"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "definitions": {
+ "__schema0": {
+ "additionalProperties": false,
+ "properties": {
+ "deletedAt": {
+ "description": "Date the step was deleted on (ISO 8601)",
+ "type": "string"
+ },
+ "description": {
+ "description": "Details of the step (HTML; only for standalone and shared_sub_step)",
+ "type": "string"
+ },
+ "expected": {
+ "description": "Expected result from the step (HTML; only for standalone and shared_sub_step)",
+ "type": "string"
+ },
+ "id": {
+ "description": "Unique identifier of the step",
+ "type": "number"
+ },
+ "isLatest": {
+ "description": "Whether this is the latest version of the step",
+ "type": "boolean"
+ },
+ "subSteps": {
+ "description": "Sub-steps of a shared step, each with type 'shared_sub_step' (present only on shared steps)",
+ "items": {
+ "$ref": "#/definitions/__schema0"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Title of the step (only for shared steps)",
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the step. Known values: \"standalone\" | \"shared\" | \"shared_sub_step\"",
+ "type": "string"
+ },
+ "version": {
+ "description": "Version of the step",
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "version",
+ "isLatest",
+ "type"
+ ],
+ "type": "object"
+ }
+ },
+ "properties": {
+ "authorId": {
+ "description": "Unique identifier of the user who added the test case",
+ "type": "number"
+ },
+ "comment": {
+ "description": "Test case precondition text (HTML). DEPRECATED — prefer the `precondition` object",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "Test case creation time (ISO 8601)",
+ "type": "string"
+ },
+ "customFields": {
+ "additionalProperties": {
+ "additionalProperties": false,
+ "properties": {
+ "isDefault": {
+ "description": "Whether the value is the default set by the system",
+ "type": "boolean"
+ },
+ "value": {
+ "description": "Current custom field value",
+ "type": "string"
+ }
+ },
+ "required": [
+ "value",
+ "isDefault"
+ ],
+ "type": "object"
+ },
+ "description": "Custom field values",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "files": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "fileName": {
+ "description": "Original file name",
+ "type": "string"
+ },
+ "id": {
+ "description": "File identifier",
+ "type": "string"
+ },
+ "mimeType": {
+ "description": "MIME type of the file",
+ "type": "string"
+ },
+ "size": {
+ "description": "File size in bytes",
+ "type": "number"
+ },
+ "url": {
+ "description": "URL of the file (missing for files uploaded via older routes)",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "fileName",
+ "mimeType",
+ "size"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "List of files attached to the test case"
+ },
+ "filledTCaseTitleSuffixParams": {
+ "description": "Parameter names whose substituted values are appended to each filled test case title for disambiguation (only for template test cases).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "folderId": {
+ "description": "Identifier of the folder where the test case is placed",
+ "type": "number"
+ },
+ "id": {
+ "description": "Unique identifier of the test case",
+ "type": "string"
+ },
+ "isDraft": {
+ "description": "Whether the test case is still in draft state",
+ "type": "boolean"
+ },
+ "isEmpty": {
+ "description": "Whether the test case is empty (has no precondition and steps)",
+ "type": "boolean"
+ },
+ "isLatestVersion": {
+ "description": "Whether this is the latest version of the test case",
+ "type": "boolean"
+ },
+ "legacyId": {
+ "description": "Legacy identifier of the test case (empty string if none is set)",
+ "type": "string"
+ },
+ "links": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "text": {
+ "description": "Title of the link",
+ "type": "string"
+ },
+ "url": {
+ "description": "URL of the link",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Additional links relevant to the test case"
+ },
+ "numFilledTCases": {
+ "description": "Number of corresponding filled test cases (only for template test cases)",
+ "type": "number"
+ },
+ "parameterValues": {
+ "description": "Parameter substitutions for filled test cases (only for template test cases)",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "tcaseId": {
+ "description": "ID of the filled test case",
+ "type": "string"
+ },
+ "tcaseVersion": {
+ "description": "Version of the filled test case",
+ "type": "number"
+ },
+ "values": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Parameter values substituted for this filled test case",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "tcaseId",
+ "tcaseVersion",
+ "values"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pos": {
+ "description": "Ordered position (0-based) of the test case in its folder",
+ "type": "number"
+ },
+ "precondition": {
+ "additionalProperties": false,
+ "description": "Test case precondition object (may be a shared or standalone precondition)",
+ "properties": {
+ "createdAt": {
+ "description": "Precondition creation time (ISO 8601)",
+ "type": "string"
+ },
+ "deletedAt": {
+ "description": "Precondition deletion time (ISO 8601)",
+ "type": "string"
+ },
+ "id": {
+ "description": "ID of the precondition",
+ "type": "number"
+ },
+ "isLatest": {
+ "description": "Whether the precondition's version is the latest",
+ "type": "boolean"
+ },
+ "projectId": {
+ "description": "Project id the precondition belongs to",
+ "type": "string"
+ },
+ "text": {
+ "description": "Precondition text (HTML format)",
+ "type": "string"
+ },
+ "title": {
+ "description": "Title of the precondition (only for shared preconditions)",
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the precondition. Known values: \"standalone\" | \"shared\"",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Precondition last-update time (ISO 8601)",
+ "type": "string"
+ },
+ "version": {
+ "description": "Version of the precondition",
+ "type": "number"
+ }
+ },
+ "required": [
+ "projectId",
+ "id",
+ "version",
+ "isLatest",
+ "type",
+ "text",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "priority": {
+ "description": "Priority of the test case. Known values: \"high\" | \"medium\" | \"low\"",
+ "type": "string"
+ },
+ "requirements": {
+ "description": "Test case requirements",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Requirement identifier",
+ "type": "string"
+ },
+ "text": {
+ "description": "Title of the requirement",
+ "type": "string"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "type": "string"
+ },
+ {
+ "const": "",
+ "type": "string"
+ }
+ ],
+ "description": "URL of the requirement"
+ }
+ },
+ "required": [
+ "id",
+ "text",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "seq": {
+ "description": "Sequence number of the test case within its project (assigned incrementally)",
+ "type": "number"
+ },
+ "steps": {
+ "description": "List of test case steps",
+ "items": {
+ "$ref": "#/definitions/__schema0"
+ },
+ "type": "array"
+ },
+ "tags": {
+ "description": "List of test case tags",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Tag identifier",
+ "type": "number"
+ },
+ "title": {
+ "description": "Tag title",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "templateTCaseId": {
+ "description": "Corresponding template test case ID (only for filled test cases)",
+ "type": "string"
+ },
+ "title": {
+ "description": "Title of the test case",
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the test case. Known values: \"standalone\" | \"template\" | \"filled\"",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Test case last-update time (ISO 8601)",
+ "type": "string"
+ },
+ "version": {
+ "description": "Version of the test case. Updates (except folder/pos) create a new version",
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "legacyId",
+ "version",
+ "type",
+ "title",
+ "seq",
+ "folderId",
+ "pos",
+ "priority",
+ "comment",
+ "files",
+ "links",
+ "authorId",
+ "isDraft",
+ "isLatestVersion",
+ "isEmpty",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+}list_custom_fieldslist_folderslist_projects2 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "projects": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "archivedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Project archival time (ISO 8601); null if the project is not archived"
+ },
+ "code": {
+ "description": "Project code (e.g., BDI)",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "Project creation time (ISO 8601)",
+ "type": "string"
+ },
+ "id": {
+ "description": "Unique identifier of the project",
+ "type": "string"
+ },
+ "links": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "text": {
+ "description": "Title of the link",
+ "type": "string"
+ },
+ "url": {
+ "description": "URL of the link",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Project links"
+ },
+ "overviewDescription": {
+ "description": "Project overview description (HTML)",
+ "type": "string"
+ },
+ "overviewTitle": {
+ "description": "Project overview title",
+ "type": "string"
+ },
+ "title": {
+ "description": "Project title",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Project last-update time (ISO 8601)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "code",
+ "title",
+ "overviewTitle",
+ "overviewDescription",
+ "links",
+ "createdAt",
+ "updatedAt",
+ "archivedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "List of projects"
+ }
+ },
+ "required": [
+ "projects"
+ ],
+ "type": "object"
+}list_requirementslist_shared_preconditionslist_shared_stepslist_test_cases10 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / customFieldsAdded value: +{
+ "additionalProperties": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": "Filter by custom field values. Keys are custom field system names (without the `cf_` prefix); values are arrays of allowed values.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Input schema / properties / include / descriptionPrevious value: -"Related data to include in the response"New value: +"Related data to include in the response (not present by default)"Input schema / properties / include / items / enumPrevious value: -[
- "steps",
- "tags",
- "project",
- "folder",
- "path"
-]New value: +[
+ "precondition",
+ "steps",
+ "tags",
+ "project",
+ "folder",
+ "path",
+ "requirements",
+ "customFields",
+ "parameterValues"
+]Input schema / properties / projectCode / patternPrevious value: -"^[A-Z0-9]+$"New value: +"^[A-Z0-9]{2,5}$"Input schema / properties / requirementIdsAdded value: +{
+ "description": "Filter by requirement IDs",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / sortOrder / descriptionPrevious value: -"Sort direction (ascending or descending)"New value: +"Sort direction (ascending or descending). Requires sortField."Input schema / properties / templateTCaseIdsAdded value: +{
+ "description": "Filter filled test cases by their parent template test case IDs",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / typesAdded value: +{
+ "description": "Filter by test case type",
+ "items": {
+ "enum": [
+ "standalone",
+ "template",
+ "filled"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "definitions": {
+ "__schema0": {
+ "additionalProperties": false,
+ "properties": {
+ "deletedAt": {
+ "description": "Date the step was deleted on (ISO 8601)",
+ "type": "string"
+ },
+ "description": {
+ "description": "Details of the step (HTML; only for standalone and shared_sub_step)",
+ "type": "string"
+ },
+ "expected": {
+ "description": "Expected result from the step (HTML; only for standalone and shared_sub_step)",
+ "type": "string"
+ },
+ "id": {
+ "description": "Unique identifier of the step",
+ "type": "number"
+ },
+ "isLatest": {
+ "description": "Whether this is the latest version of the step",
+ "type": "boolean"
+ },
+ "subSteps": {
+ "description": "Sub-steps of a shared step, each with type 'shared_sub_step' (present only on shared steps)",
+ "items": {
+ "$ref": "#/definitions/__schema0"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Title of the step (only for shared steps)",
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the step. Known values: \"standalone\" | \"shared\" | \"shared_sub_step\"",
+ "type": "string"
+ },
+ "version": {
+ "description": "Version of the step",
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "version",
+ "isLatest",
+ "type"
+ ],
+ "type": "object"
+ }
+ },
+ "properties": {
+ "data": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "authorId": {
+ "description": "Unique identifier of the user who added the test case",
+ "type": "number"
+ },
+ "comment": {
+ "description": "Test case precondition text (HTML). DEPRECATED — prefer the `precondition` object",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "Test case creation time (ISO 8601)",
+ "type": "string"
+ },
+ "customFields": {
+ "additionalProperties": {
+ "additionalProperties": false,
+ "properties": {
+ "isDefault": {
+ "description": "Whether the value is the default set by the system",
+ "type": "boolean"
+ },
+ "value": {
+ "description": "Current custom field value",
+ "type": "string"
+ }
+ },
+ "required": [
+ "value",
+ "isDefault"
+ ],
+ "type": "object"
+ },
+ "description": "Custom field values",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "files": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "fileName": {
+ "description": "Original file name",
+ "type": "string"
+ },
+ "id": {
+ "description": "File identifier",
+ "type": "string"
+ },
+ "mimeType": {
+ "description": "MIME type of the file",
+ "type": "string"
+ },
+ "size": {
+ "description": "File size in bytes",
+ "type": "number"
+ },
+ "url": {
+ "description": "URL of the file (missing for files uploaded via older routes)",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "fileName",
+ "mimeType",
+ "size"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "List of files attached to the test case"
+ },
+ "filledTCaseTitleSuffixParams": {
+ "description": "Parameter names whose substituted values are appended to each filled test case title for disambiguation (only for template test cases).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "folder": {
+ "additionalProperties": false,
+ "description": "Folder where the test case is placed",
+ "properties": {
+ "comment": {
+ "description": "Additional notes or description (HTML)",
+ "type": "string"
+ },
+ "id": {
+ "description": "Unique identifier for the folder",
+ "type": "number"
+ },
+ "parentId": {
+ "description": "ID of the parent folder (0 for root folders)",
+ "type": "number"
+ },
+ "pos": {
+ "description": "Position of the folder among its siblings",
+ "type": "number"
+ },
+ "projectId": {
+ "description": "ID of the project the folder belongs to",
+ "type": "string"
+ },
+ "title": {
+ "description": "Name of the folder",
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "id",
+ "parentId",
+ "pos",
+ "title",
+ "comment"
+ ],
+ "type": "object"
+ },
+ "folderId": {
+ "description": "Identifier of the folder where the test case is placed",
+ "type": "number"
+ },
+ "id": {
+ "description": "Unique identifier of the test case",
+ "type": "string"
+ },
+ "isDraft": {
+ "description": "Whether the test case is still in draft state",
+ "type": "boolean"
+ },
+ "isEmpty": {
+ "description": "Whether the test case is empty (has no precondition and steps)",
+ "type": "boolean"
+ },
+ "isLatestVersion": {
+ "description": "Whether this is the latest version of the test case",
+ "type": "boolean"
+ },
+ "legacyId": {
+ "description": "Legacy identifier of the test case (empty string if none is set)",
+ "type": "string"
+ },
+ "links": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "text": {
+ "description": "Title of the link",
+ "type": "string"
+ },
+ "url": {
+ "description": "URL of the link",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Additional links relevant to the test case"
+ },
+ "numFilledTCases": {
+ "description": "Number of corresponding filled test cases (only for template test cases)",
+ "type": "number"
+ },
+ "parameterValues": {
+ "description": "Parameter substitutions for filled test cases (only for template test cases)",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "tcaseId": {
+ "description": "ID of the filled test case",
+ "type": "string"
+ },
+ "tcaseVersion": {
+ "description": "Version of the filled test case",
+ "type": "number"
+ },
+ "values": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "Parameter values substituted for this filled test case",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "tcaseId",
+ "tcaseVersion",
+ "values"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "path": {
+ "description": "Folder path to the test case",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "comment": {
+ "description": "Additional notes or description (HTML)",
+ "type": "string"
+ },
+ "id": {
+ "description": "Unique identifier for the folder",
+ "type": "number"
+ },
+ "parentId": {
+ "description": "ID of the parent folder (0 for root folders)",
+ "type": "number"
+ },
+ "pos": {
+ "description": "Position of the folder among its siblings",
+ "type": "number"
+ },
+ "projectId": {
+ "description": "ID of the project the folder belongs to",
+ "type": "string"
+ },
+ "title": {
+ "description": "Name of the folder",
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "id",
+ "parentId",
+ "pos",
+ "title",
+ "comment"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pos": {
+ "description": "Ordered position (0-based) of the test case in its folder",
+ "type": "number"
+ },
+ "precondition": {
+ "additionalProperties": false,
+ "description": "Test case precondition object (may be a shared or standalone precondition)",
+ "properties": {
+ "createdAt": {
+ "description": "Precondition creation time (ISO 8601)",
+ "type": "string"
+ },
+ "deletedAt": {
+ "description": "Precondition deletion time (ISO 8601)",
+ "type": "string"
+ },
+ "id": {
+ "description": "ID of the precondition",
+ "type": "number"
+ },
+ "isLatest": {
+ "description": "Whether the precondition's version is the latest",
+ "type": "boolean"
+ },
+ "projectId": {
+ "description": "Project id the precondition belongs to",
+ "type": "string"
+ },
+ "text": {
+ "description": "Precondition text (HTML format)",
+ "type": "string"
+ },
+ "title": {
+ "description": "Title of the precondition (only for shared preconditions)",
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the precondition. Known values: \"standalone\" | \"shared\"",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Precondition last-update time (ISO 8601)",
+ "type": "string"
+ },
+ "version": {
+ "description": "Version of the precondition",
+ "type": "number"
+ }
+ },
+ "required": [
+ "projectId",
+ "id",
+ "version",
+ "isLatest",
+ "type",
+ "text",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "priority": {
+ "description": "Priority of the test case. Known values: \"high\" | \"medium\" | \"low\"",
+ "type": "string"
+ },
+ "project": {
+ "additionalProperties": false,
+ "description": "Project the test case belongs to",
+ "properties": {
+ "archivedAt": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Project archival time (ISO 8601); null if the project is not archived"
+ },
+ "code": {
+ "description": "Project code (e.g., BDI)",
+ "type": "string"
+ },
+ "createdAt": {
+ "description": "Project creation time (ISO 8601)",
+ "type": "string"
+ },
+ "id": {
+ "description": "Unique identifier of the project",
+ "type": "string"
+ },
+ "links": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "text": {
+ "description": "Title of the link",
+ "type": "string"
+ },
+ "url": {
+ "description": "URL of the link",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Project links"
+ },
+ "overviewDescription": {
+ "description": "Project overview description (HTML)",
+ "type": "string"
+ },
+ "overviewTitle": {
+ "description": "Project overview title",
+ "type": "string"
+ },
+ "title": {
+ "description": "Project title",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Project last-update time (ISO 8601)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "code",
+ "title",
+ "overviewTitle",
+ "overviewDescription",
+ "links",
+ "createdAt",
+ "updatedAt",
+ "archivedAt"
+ ],
+ "type": "object"
+ },
+ "requirements": {
+ "description": "Test case requirements",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Requirement identifier",
+ "type": "string"
+ },
+ "text": {
+ "description": "Title of the requirement",
+ "type": "string"
+ },
+ "url": {
+ "anyOf": [
+ {
+ "format": "uri",
+ "type": "string"
+ },
+ {
+ "const": "",
+ "type": "string"
+ }
+ ],
+ "description": "URL of the requirement"
+ }
+ },
+ "required": [
+ "id",
+ "text",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "seq": {
+ "description": "Sequence number of the test case within its project (assigned incrementally)",
+ "type": "number"
+ },
+ "steps": {
+ "description": "List of test case steps",
+ "items": {
+ "$ref": "#/definitions/__schema0"
+ },
+ "type": "array"
+ },
+ "tags": {
+ "description": "List of test case tags",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Tag identifier",
+ "type": "number"
+ },
+ "title": {
+ "description": "Tag title",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "templateTCaseId": {
+ "description": "Corresponding template test case ID (only for filled test cases)",
+ "type": "string"
+ },
+ "title": {
+ "description": "Title of the test case",
+ "type": "string"
+ },
+ "type": {
+ "description": "Type of the test case. Known values: \"standalone\" | \"template\" | \"filled\"",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Test case last-update time (ISO 8601)",
+ "type": "string"
+ },
+ "version": {
+ "description": "Version of the test case. Updates (except folder/pos) create a new version",
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "legacyId",
+ "version",
+ "type",
+ "title",
+ "seq",
+ "folderId",
+ "pos",
+ "priority",
+ "comment",
+ "files",
+ "links",
+ "authorId",
+ "isDraft",
+ "isLatestVersion",
+ "isEmpty",
+ "createdAt",
+ "updatedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "List of test cases"
+ },
+ "limit": {
+ "description": "Number of test cases per page",
+ "type": "number"
+ },
+ "page": {
+ "description": "Current page number",
+ "type": "number"
+ },
+ "total": {
+ "description": "Total number of filtered test cases",
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "page",
+ "limit",
+ "data"
+ ],
+ "type": "object"
+}list_test_cases_folderslist_test_cases_tags6 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / includeAdded value: +{
+ "description": "Include optional fields like the number of test cases using each tag",
+ "enum": [
+ "tcaseCount"
+ ],
+ "type": "string"
+}Input schema / properties / projectCode / patternPrevious value: -"^[A-Z0-9]+$"New value: +"^[A-Z0-9]{2,5}$"Input schema / properties / sortFieldAdded value: +{
+ "description": "Field to sort results by",
+ "enum": [
+ "created_at",
+ "title"
+ ],
+ "type": "string"
+}Input schema / properties / sortOrderAdded value: +{
+ "description": "Sort direction (ascending or descending). Requires sortField.",
+ "enum": [
+ "asc",
+ "desc"
+ ],
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "tags": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "description": "Tag identifier",
+ "type": "number"
+ },
+ "tcaseCount": {
+ "description": "Number of test cases using this tag (only when `tcaseCount` is included)",
+ "type": "number"
+ },
+ "title": {
+ "description": "Tag title",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "List of tags defined in the project"
+ }
+ },
+ "required": [
+ "tags"
+ ],
+ "type": "object"
+}update_test_caseupsert_foldersv1.0.0get_projectget_test_caselist_projectslist_test_caseslist_test_cases_folderslist_test_cases_tagsEach tool targets a distinct entity and action: projects, folders, test cases, tags, requirements, shared steps, and shared preconditions are all clearly separated. The get/list pairs are unambiguous because one returns details by ID while the other lists collection-level data.
Tool names mostly follow a consistent verb_noun pattern like list_projects, get_test_case, create_test_case, and update_test_case. Minor deviations include upsert_folders and list_test_cases_tags, which break the otherwise predictable naming slightly.
At 15 tools, the set is at the upper bound of a well-scoped server but every tool supports a clear purpose in the QA Sphere test case workflow. The count feels justified by the domain breadth rather than padded with redundant operations.
The main test case lifecycle is well covered with list, get, create, and update, but delete_test_case is missing, which is a notable gap for full CRUD coverage. Supporting entities like shared steps and preconditions are read-only, leaving no way to manage them through this server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Official MCP server for Qase — manage test cases, runs, suites, defects via AI tools.
An MCP server that provides access to Testiny projects, test cases and test runs
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hypersequent/qasphere-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
