Development got faster. Testing should not get thinner!
QA Vault is the MCP-first test management system for teams that ship at agent speed. Your judgment stays the standard. Agents carry the volume: retrieving, maintaining, running and triaging the cases you approved.
Ask what the suite already knows.
Describe what you want to test. QA Vault finds relevant cases, even when they use different words.
› We’re adding shared reports. Check whether we already cover: can someone see another team’s private data?✓ Project rules read⚙ get_project_rules { "project": "ACME" }← { "rules": [], "count": 0 }✓ Suite searched by meaning⚙ smart_search_cases { "project": "ACME", "query": "Can someone see another team’s private data?" }← { "count": 3, "strong": 2, "related": 1, "case_ids": [207, 214, 128], "cases": [ { "id": 207, "title": "Member cannot open another workspace’s project", "relevance": "strong" }, { "id": 214, "title": "API key is limited to its issuing workspace", "relevance": "strong" }, { "id": 128, "title": "Viewer cannot change project content", "relevance": "related" } ] }✓ Strong matches read in full⚙ get_test_case { "case_id": 207 }← { "case_number": 207, "priority": "high", "automation": "automated", "preconditions": "Two workspaces exist. The user is a member of workspace A only.", "steps": [ { "action": "Paste the direct URL of a workspace B project.", "expected_result": "Not-found page; no title, cases or members of the project are rendered." }, { "action": "Reload with the network panel open.", "expected_result": "The project request returns an authorization error." } ] }● Already covered. ACME-207 checks that a member cannot open another workspace’s project, and ACME-214 covers the same boundary for API keys. ACME-128 is about editing rights, not visibility, so it doesn’t count. Nothing to create — shared reports should reuse ACME-207’s precondition. Want me to draft the one new case for the report link itself?›
The agent asks the same index you did, through the QA Vault MCP server. It reads the whole case before deciding what to add, so approved intent is reused instead of duplicated.
The suite’s meaning lives on the server.
The agent only pays for the answer.
Every case is stored twice as meaning inside QA Vault: its own text, and a short semantic profile an agent writes for it. A question is compared with both, on the server, and the ranked handful comes back over MCP. No suite to read into context, no vectors to compute, no tokens burned on cases that don’t matter.- CASES READ
- 205
- TOKENS SPENT
- 155,000≈ estimate
Still guessing which ones matter.
- CASES RETURNED
- 2of 205, ranked
- TOKENS SPENT
- 230≈ estimate
ACME-207 strong · ACME-214 related.
Token costs measured on a real project: one case read in full ≈ 750 tokens; one search reply ≈ 230. Suite size illustrative. Rounded.
- SEARCH BEFORE YOU WRITECheap enough to check for duplicates on every new case, not just when you remember to.
- SWEEP AFTER EVERY CHANGEMaintenance finds every affected case by meaning, including the ones whose titles never mention the change.
- FROM A DEFECT TO ITS CASESPaste a bug report and get the cases covering that area, ranked, without reading the suite.
- ASK IN ANY WORDSPlain language or industry terms both land, because the profile carries the phrasings the case itself never uses.
SEARCH IS ONE TOOL OF MANY
The product changed.
Now the cases change, through the same MCP.
Development changed an existing flow. A QA Engineer opens a session and the agent finds the affected cases, stages a reviewed changeset, applies what the engineer approved, and turns it into a run. Pick a stage to see what happens.INPUTThe invitation model changed: one user can now belong to several workspaces.
› PR #482 changed invitations: a user can now join several workspaces. Find every case this touches.⚙ get_project_rules { "project": "ACME" }⚙ smart_search_cases { "project": "ACME", "query": "journeys affected when one user can join several workspaces" }← { "count": 6, "strong": 4, "related": 2, "case_ids": [184, 186, 190, 207, 128, 233] }✓ Six cases read in full● 4 affected by their steps, not their titles. ACME-207 asserts “member of workspace A only” in its precondition — that is the one a title scan would miss.›
The agent takes the project rules, reads the change, and gathers every affected case. It judges by the steps, not the titles: no case is edited or dismissed unread.
get_project_rulessmart_search_casessearch_test_casesget_test_caseEvery tool the agent can call, grouped by what it does.
A QA Engineer in AI-speed development works next to the agent, inside the IDE. Not writing the product code: opening the repository, running the session, reading the changeset, saying “go”. The keyboard is the same. The judgment is still yours.
Okay… so what is left for me?
The decisions.
And reading between the lines.
The agent writes the cases, keeps them current and runs them. Every approval is still yours. But your most valuable hour is not spent checking what the agent covered. It is spent with the artifacts in front of you, reading between the lines: the case that should exist and doesn’t. No model does that for you.
GOOD TO HAVE YOU HERE.// qa-vault: project=ACME case=184// source: Accept an invitation to a second workspace (v4)
The test case is the spec.
The E2E test is its mirror.
Cases written with QA Vault skills are scenarios: what the user does and what they must see, never how the screen is built. That makes every case a finished specification for an E2E test. The generated test repeats the case step by step and checks the same expected results. What is covered reads the same for a developer, a QA Engineer and a stakeholder, whatever the stack.
Accept an invitation to a second workspace
- Sign in as a member of workspace A.The projects page of workspace A opens.
- Open the invitation link for workspace B.An “Accept invitation” screen names workspace B.
- Click “Accept”.Workspace B opens. The workspace switcher lists A and B.
- Reload the page.The session stays in workspace B.
// qa-vault: project=ACME case=184 // source: Accept an invitation to a second workspace (v4) import { test, expect } from '../fixtures'; test('accept an invitation to a second workspace', async ({ page, member, invite }) => { // 1. Sign in as a member of workspace A. await member.signIn(page); await expect(page.getByRole('heading', { name: 'Projects' })).toBeVisible(); // 2. Open the invitation link for workspace B. await page.goto(invite.url); await expect(page.getByRole('heading', { name: 'Accept invitation' })).toContainText('Workspace B'); // 3. Click “Accept”. await page.getByRole('button', { name: 'Accept' }).click(); await expect(page.getByRole('combobox', { name: 'Workspace' })).toHaveText('Workspace B'); // 4. Reload the page. await page.reload(); await expect(page.getByRole('combobox', { name: 'Workspace' })).toHaveText('Workspace B');});
- SCENARIO, NOT CHECKLISTOne case is one complete journey with many steps, the way a person would run it.
- CONTRACT, NOT IMPLEMENTATIONSteps name what the user sees and gets. Labels and flows, no selectors, no endpoints.
- MIRROR, NOT TRANSLATIONThe test keeps the case’s numbering, steps and expected results. Same words on both sides.
Loud screens cost attention. This one spends it carefully.
Every control in QA Vault is still there. Only what deserves your eye is allowed to be bright: the case you are reading, the verdict you owe, the change waiting for review. Everything else steps back. We spent years in tools where most of the screen was never used, and every unused control still asked to be looked at. QA Vault was built the other way round.Quiet is not a taste. It is where the work went. Every control that stepped back is an operation an agent now runs through MCP. The screen keeps what still needs a person.
- Searching before writing anything
smart_search_casessearch-test-cases - Checking a new case against what exists
find_related_casescreate-test-cases - Updating cases after a change
maintain-test-casesbulk_update_test_cases - Filing run results, case by case
bulk_record_resultsrun-automated-tests - Keeping automation status honest
automate-test-casesupdate_test_case - Filing defects and linking them to cases
create_defectsuggest_cases_for_defect
The app is one door. The MCP is another. The third is the practice itself: authored skills that give your agent a default process from the first minute.
FAQ
Your current tool stores test cases as records: titles, fields, keywords. QA Vault stores what each case means, so it understands a question the way a colleague would. Ask about a change in plain words and the few cases that matter come back, ranked, instead of hundreds of near matches. The agent never reads the whole suite to find them, so every request stays small and every answer stays sharp.
Yes, a local copy, so the agent can work from it. The code is the source it reads, and it is the only true record of what was actually built. A Jira ticket says what was asked for; a specification says what was planned, often months ago. The codebase says what is really there. Testing against it closes the gap between the plan and the product, and that is what puts QA in a far stronger position than before.
It reads the code and the task, thinks critically about both, and writes scenario-based test cases with you. You approve them, and only then they go into the vault. That loop runs on whatever you point it at: a feature from scratch, a change a developer just pushed, a ticket that was just closed. Within it, the agent searches what already covers the area, creates what is missing, maintains what went stale, and runs the cases it was asked to run. The volume is its. The verdict is yours.
Any client that speaks MCP. The authored skills give that agent a default QA process from the first minute: authoring, maintenance, automation, runs and triage.
Yes. There is a free read-only role for exactly that: a product manager, a lead, a client who wants to know where quality stands without doing the work. No codebase on their machine, no seat to pay for. In a Pro workspace they connect their own agent over MCP and ask in plain words: what is covered, what was run this week, what failed and why. The answers come from the same vault the team works in, so everyone reads the same picture.
DEVELOPMENT GOT FASTER.
QUALITY IS STILL YOUR CALL.