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.
Note: Enterprise workspaces on dedicated cloud infrastructure are the one exception. The hosted server reaches Qase through our standard API base URL, 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.
❗ 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
v2 ships 41 tools, consolidated from v1's 83 for lower token usage and better accuracy. Your client sees 17 of them when it connects. The other 24 stay hidden until your assistant activates them with qase_discover_tools, which keeps the default list small. If something you expect is missing, see Troubleshooting below.
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 | 1 |
|
Full tool-by-tool reference with parameters: docs/tools.md.
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, using the MCP elicitation capability. If your client does not support it, the deletion is refused before it reaches Qase, and the refusal says so. 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 supports elicitation.
A tool you expect may simply be hidden. Only 17 of the 41 tools are listed when your client connects; the rest are activated on demand. See the next section.
Your assistant says a tool doesn't exist
Ask it to run qase_discover_tools with a keyword for what you want — for example "delete", "milestone", "plan", "custom field" or "review". That searches the full catalogue and switches on what matches for the rest of the session. Every delete, along with test plans, milestones, environments, shared steps, custom fields, project creation and the test case review tools, starts out hidden this way.
If discovery reports the tool as activated and your assistant still cannot call it, your client built its tool list when it connected and has not rebuilt it. Update to version 2.6.0 or later, which fixes this and also moves the most-used tools into the list you get from the start. The hosted connector always runs the latest version; a self-run server updates with npm update -g @qase/mcp-server. Starting a new session also picks up anything already activated.
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]
