The Qase MCP Server connects AI assistants: Claude, Cursor, Codex, and any other MCP-compatible client, directly to your Qase workspace.
Using natural-language prompts, your AI tool can read and write test cases, runs, results, defects, suites, milestones, environments, and more, with no custom integration code.
It also supports QQL (Qase Query Language) for advanced searches across cases, runs, results, defects, and plans.
ℹ️ Official repository and full documentation:github.com/qase-tms/qase-mcp-server
Two ways to connect
Option | Best for | What you need |
Hosted MCP (Enterprise plan) | Enterprise plan users on Qase's standard cloud who want zero setup | Just your Qase login (OAuth) – no install, no API token |
Self-run | All other plans, local/custom setups, or Enterprise customers on dedicated cloud infrastructure | Node.js + your own Qase API token |
Option 1: Hosted Qase MCP (Enterprise plan only)
The hosted server is available on the Enterprise plan only. Connect to it at https://mcp.qase.io/mcp and sign in with your Qase account — no installation and no API token required, and the client handles the OAuth flow for you. On any other plan the sign-in still succeeds and your client still lists the tools, but every call it makes is refused, so use Option 2: Run it yourself below instead. That option works on every plan.
Use the address for the region your workspace is in. The two regions run separate servers, and the wrong one cannot reach your projects.
Your Qase workspace | MCP server address |
|
|
|
|
The steps below use the main-cloud address. On the EU cluster, use https://mcp-eu.qase.io/mcp instead and change nothing else.
Note: Enterprise workspaces on dedicated cloud infrastructure are the one exception. The hosted servers connect only to Qase's own cloud regions, so those workspaces must use Option 2: Run it yourself below as well.
Claude
Qase publishes an official Qase Test Management connector in Claude's directory.
In Claude, open Settings → Connectors and find Qase Test Management.
Click Connect and complete the Qase sign-in when prompted.
The directory connector uses the main cloud. On the EU cluster, add it by address instead: Settings → Connectors → Add custom connector, with https://mcp-eu.qase.io/mcp.
❗ we’re updating the official Claude connector. In the meantime, here are the instructions to create a custom connector.
Cursor
Add the server by URL in ~/.cursor/mcp.json (global) or .cursor/mcp.json(project). Cursor opens your browser to sign in; the tools appear once you authorize.
{ "mcpServers": { "qase": { "url": "https://mcp.qase.io/mcp" } } }
Codex
ChatGPT / Codex app: open Settings → MCPs → Add server, enter https://mcp.qase.io/mcp, and click Authenticate.
Codex CLI: add to ~/.codex/config.toml, then run codex mcp login qase and sign in via your browser.
[mcp_servers.qase] url = "https://mcp.qase.io/mcp" auth = "oauth"
Tip: Enter the URL exactly as shown, without surrounding quotes. A stray quote (or its encoded form %22) in the URL breaks OAuth. If a connection fails to authenticate, remove the server entry and re-add it, typing the URL by hand.
Any MCP client that supports remote servers with OAuth 2.1 connects the same way — just point it at https://mcp.qase.io/mcp.
Full per-client steps: docs/connect.md.
Active workspace
The connector operates on the workspace currently selected in your Qase UI. To work in a different workspace, just switch it in Qase, subsequent requests route to the new workspace automatically, with no need to reconnect or re-authorize.
Option 2: Run it yourself
Install the package and provide your own API token:
npm install -g @qase/mcp-server export QASE_API_TOKEN=your_api_token_here
Then point your MCP client's stdio config at the @qase/mcp-server binary.
Full install options, client configs (Claude Desktop, Cursor, Claude Code, Codex, OpenCode), environment variables, and transports (stdio / SSE / streamable-HTTP) are at docs/self-run.md.
What you can do with it
Once connected, ask your AI assistant to work with Qase in plain language. A few examples:
Task | Example prompt |
Bootstrap project context | “Show me the structure of project DEMO — suites, milestones, environments.” |
Create or update a test case | “Create a high-priority smoke test case in project DEMO titled 'Login with valid credentials'.” |
Report CI results | “Report these CI results for project DEMO: case 1 passed, case 2 failed with 'timeout error'.” |
Triage a failed test | “Create a critical defect for the login timeout failure in run #42.” |
Search with QQL | “Find all failed test results from the last 7 days in project DEMO.” |
Tools
Version 3.0.0 has 42 tools, and your client sees all of them as soon as it connects. Nothing is hidden or switched on later. Each tool carries a short description, so the full list costs your assistant about 28% less of its context than before. When your assistant needs the details of one tool, it reads them with qase_tool_help.
Group | Count | Description |
Read | 2 | Fetch any entity by type/ID, or bootstrap full project context in one call |
QQL | 2 | Search cases, runs, results, defects, and plans with Qase Query Language |
Write | 32 | Create, update, and delete cases (single, or up to 100 at once), runs, results, defects, suites, milestones, plans, shared steps, environments, custom fields, and attachments; link cases and runs to Jira issues; propose and manage test case reviews |
Composite | 3 | Multi-step workflows in one call: CI reporting, defect triage, regression run setup |
Escape hatch | 1 | Direct REST API access for any endpoint not covered above |
Meta | 2 |
|
Full tool-by-tool reference with parameters: docs/tools.md.
Upgrading from 2.x to 3.0.0
No tool was renamed and no argument changed, so your prompts and automation keep working. Version 3.0.0 supports the newer MCP protocol version (2026-07-28) and still serves clients on the older one (2025-11-25). What you notice:
Every tool is in your list from the start. If your prompts tell the assistant to "run discovery first", you can remove that line. Leaving it in does no harm.
A delete now asks for your confirmation in two steps: the server asks, your client shows you the prompt, and the call is repeated with your answer. Most clients do this for you. A confirmation is valid for ten minutes and only for the exact item you were shown.
The hosted server is already on 3.0.0, so you have nothing to do. A self-run server updates with npm update -g @qase/mcp-server. Full details: migration guide.
Upgrading from v1
v2 renames tools and changes response shapes as part of consolidating v1's 83 tools. If you’re moving from v1, follow the complete tool-mapping table and before/after examples in the migration guide: MIGRATION.md.
Troubleshooting
Something works through the API but not through MCP
Your role and your license type are not the cause. Qase applies the same permissions to the web app, the API and MCP, and an API token carries exactly the rights of the person who created it. When the same account can do something with a direct API call and not through your assistant, it is one of the three things below.
The hosted connector is available on the Enterprise plan only. Sign-in succeeds on any plan and your assistant shows a full list of tools, so the connector looks healthy — but every call it makes is refused, whatever the call is trying to do. Your API token is unaffected, because the public API has no such restriction, which is why direct API calls keep working. The refusal names your plan, and depending on your client it may also say you lack permission; that part is inaccurate and you can ignore it.
If you are not on Enterprise, use Option 2: Run it yourself above with your own Qase API token. It works on every plan, on dedicated infrastructure, and gives you everything your token can do — there is nothing to upgrade.
Deleting anything needs a client that can ask you to confirm. Every delete through MCP asks for your confirmation first. Your client can show that prompt if one of these is true:
It uses the newer MCP protocol version, 2026-07-28.
It supports MCP elicitation and keeps a long-lived connection to the server, as a self-run server started from your client does.
If neither is true, the deletion is refused before it reaches Qase, and the refusal says which requirement is missing. Claude Desktop is one such client today, so deletes from it are refused; everything else works normally there. This applies to the direct REST escape hatch as well, so there is no way around it from inside your assistant. Delete the item in the Qase web app, or use a client that meets one of the requirements, such as Claude Code.
If your client receives the confirmation request but never shows it to you, the result says the request was cancelled, not declined. Nothing is deleted.
Your assistant says a tool doesn't exist
From version 3.0.0, all 42 tools are listed when your client connects. If one seems to be missing, your server is older than 3.0.0, where some tools stayed hidden until qase_discover_tools switched them on. The hosted connector always runs the latest version; a self-run server updates with npm update -g @qase/mcp-server. After the update, start a new session so your client loads the full list.
If your assistant does not know which tool fits a task, ask it to run qase_discover_tools with a keyword for what you want, for example "milestone", "plan" or "review".
More
Connector not appearing, empty tool list, or OAuth failing? See docs/troubleshooting.md.
Report issues: GitHub Issues, via our live-chat, or at
[email protected]