A QA MCP server: give your AI the test runbook

Model Context Protocol is the standard way to hand an assistant a set of tools it can call. A QA MCP server exposes the runbook itself: the checks, the results per platform, and the issues testers raised. Your assistant reads them the same way a person reads the board, and writes back to the same place.

qarunbook ships one at https://qarunbook.com/api/mcp. It speaks streamable HTTP, it is free, and the handshake and tool list answer without a token so directories and clients can see what it offers before anyone signs in.

The loop it closes

Testing usually breaks down at the handover. A tester writes “payment page 404s after you abandon checkout” in a spreadsheet, someone fixes it, and nobody knows whether the fix was ever checked on the platform it broke on. The runbook makes that mechanical:

1. A tester records a fail on a check, on one platform, with a screenshot.
2. Your assistant calls list_issues, reads what they wrote, and fixes the code.
3. It calls resolve_issue.
4. The check underneath goes back to needs retest — not to passing. Status is derived, not stored, so nothing can mark its own homework.

That last step is the whole design. A fix is a claim until a human confirms it on the platform the bug was reported on.

The tools

Fourteen, split by what they touch. Every one carries a title and an honest hint about whether it changes data.

Read

• list_apps — the apps in the runbook and their platform codes
• progress — passing, failing, untested and not-applicable counts
• list_issues — what testers raised, newest first
• list_checks — filter to failing, untested, or awaiting retest
• get_check — one check in full, with its issues

Add

• create_app, import_plan — start an app, or paste a whole markdown test plan
• add_section, add_check — extend the plan
• add_issue — raise what you found

Change

• set_result — record a pass or fail on a platform
• resolve_issue — mark an issue fixed
• edit_issue, update_check — correct wording, or mark a check not applicable on a platform so it stops counting against coverage

Connecting it

Sign in, open Connect your AI, and copy your token. Then one of these. The token is per person, so every result carries a name.

claude mcp add qa-runbook --transport http https://qarunbook.com/api/mcp \
  --header "Authorization: Bearer qarb_your_token_here"

In Claude Desktop: Settings → Connectors → Add custom connector, with the URL above and an Authorization: Bearer header.

// ~/.cursor/mcp.json
{
  "mcpServers": {
    "qa-runbook": {
      "url": "https://qarunbook.com/api/mcp",
      "headers": { "Authorization": "Bearer qarb_your_token_here" }
    }
  }
}

# ~/.codex/config.toml
[mcp_servers.qa-runbook]
url = "https://qarunbook.com/api/mcp"
http_headers = { Authorization = "Bearer qarb_your_token_here" }

What to ask it

Once connected, the useful prompts are boring, which is the point:

• “What is failing on iOS for Smart Invites?”
• “Read the open issues, fix the two that are in this repo, and mark them fixed.”
• “Where is testing up to before we ship?”
• “Import this test plan and tell me what it does not cover.”

When you do not need this

If one person writes the code and does the testing, a checklist in a file is enough. This earns its place when results come from more than one person, on more than one platform, and someone has to decide whether a release is safe. It also does not replace automated tests — it covers the manual pass that runs alongside them, which is where release decisions actually get made.