QA guide

Use this page as a short everyday checklist. For examples, open the plain-language cookbook.

Everyday workflow

mcprigor check tests/acceptance.mcpr
mcprigor test tests/acceptance.mcpr
mcprigor test tests/acceptance.mcpr --html report.html

Or use the browser:

mcprigor workspace .

Test structure

MCP Test 1
Suite: "Customer service"
Server: node dist/server.js

Test: "An active customer can be found"
  Call tool "find_customer" with:
    customerId: "C-100"

  Expect "structuredContent.status" equals "active"

A file needs:

A suite name
A Server command or MCP URL
One or more named tests
At least one action in each test

Actions

Call tool "name" with:
  input: value

Read resource "scheme://resource"

Get prompt "name" with:
  argument: value

Send "ping"

Expectations

Expect it succeeds
Expect an error
Expect "field" equals value
Expect "field" does not equal value
Expect "field" contains value
Expect "field" exists
Expect "items" has 3 items
Expect "field" is a string
Expect "field" matches "pattern"

Arrays use indexes such as items[0].name.

Variables

Save "structuredContent.id" as "createdId"

Use it later:

Call tool "get_item" with:
  id: "${createdId}"

Setup and cleanup

Setup:
Call tool "create_fixture"

Steps:
Call tool "verify_fixture"

Cleanup:
Call tool "delete_fixture"

Cleanup is attempted even after a failed step. Keep it safe to repeat.

Data tables

For each row:
  | caseId | input | expected |
  | first  | 2     | 4        |
  | second | 3     | 6        |

Use values as ${row.input} and ${row.expected}.

Good QA practices

Assert stable business fields, not entire responses.
Use exists for generated IDs.
Avoid exact timestamp and token assertions.
Give tests behavior-focused names.
Keep each test independently repeatable.
Add cleanup for created data.
Validate with check before running.
Review snapshots and contract updates in pull requests.
Keep credentials in environment variables.