API, data & performance

Why a tester should care

Two distinct jobs, and it's worth separating them because they have different value profiles.

Job one: API testing proper. Generate a collection from an OpenAPI spec, add contract assertions to every request, and find the endpoints where the implementation drifted from the documentation. That drift is a defect class most teams never systematically test for, because doing it by hand across 80 endpoints is nobody's idea of a good week.

Job two: state setup for UI tests. Less glamorous, more valuable day to day. Reaching "user with a pending refund on an order older than 30 days" through the UI takes six screens and ninety seconds; through the API it takes one call and 200 ms. Multiply by every test in your suite and it's the difference between a suite that runs in four minutes and one that runs in forty.

Tool surface

Wire it up

Postman offers a hosted remote server (recommended — nothing to install, OAuth-based) and a local npm package for air-gapped or proxy-constrained setups.

claude mcp add --transport http postman https://mcp.postman.com/minimal

{
  "mcpServers": {
    "postman": {
      "command": "npx",
      "args": ["-y", "@postman/mcp-server", "--region", "us"],
      "env": {
        "POSTMAN_API_KEY": "${POSTMAN_API_KEY}"
      }
    }
  }
}

Workflows

1 · Contract drift detection

This is the single highest-value prompt in this guide. It finds real defects, it takes seconds, and almost nobody does it manually.

2 · Negative-test generation

Authorisation bypass — "another tenant's resource id" — is where multi-tenant products break, and it's the case human testers skip most often because it's tedious to set up.

3 · State setup for the UI suite

4 · Mock-first frontend testing

Error-state UI is chronically under-tested because triggering a real 429 is hard. A mock makes it trivial, and error states are where users actually get stuck.

Gotchas

• Shared workspaces mean shared consequences. putCollection overwrites. Have the agent work in a personal workspace and promote deliberately.
• Secrets in environments. Ask for an environment's contents and you may get an API key printed into the transcript. Use secret-type variables and avoid dumping environments wholesale.
• Collection ≠ execution. The MCP server manages Postman resources; running a collection in CI is still Newman or Postman CLI. Don't assume "run the collection" means what you think it means — check what your chosen setup actually executes.
• Generated tests over-assert on the happy path. Status 200 and a schema check is a starting point, not a test. Push for business-rule assertions.

Why a tester should care

The barrier to performance testing was never the tooling — k6 scripts are ordinary JavaScript. It was that writing a realistic load profile means thinking about ramp shapes, think time, correlation of dynamic tokens, and threshold definitions, and most teams give up and run 100 flat VUs against one endpoint, which measures nothing useful.

An agent that can draft "ramp to 200 VUs over 5 minutes, hold 10, ramp down, with p(95) under 800ms and error rate under 1%" from a sentence removes that barrier. Whether the resulting numbers mean anything still depends entirely on whether your load model resembles reality — and that judgement stays yours.

Tool surface

Minimal by nature. Typically execute_k6_test (script path, duration, VUs) and execute_k6_test_with_options (arbitrary CLI flags), sometimes plus a script-generation helper. The real surface is k6 itself: stages, thresholds, checks, scenarios, and the metrics output.

Wire it up

winget install k6 --source winget
k6 version

{
  "mcpServers": {
    "k6": {
      "command": "uvx",
      "args": ["k6-mcp-server"],
      "env": {
        "K6_BIN": "k6",
        "K6_SCRIPTS_DIR": "./perf"
      }
    }
  }
}

Workflows

1 · Draft the load profile from a requirement

"Save it, don't run it" should be your default with this server, every time, without exception.

2 · Review before execute

3 · Interpret the results

"Where in the ramp did it degrade" is the question that distinguishes a capacity limit from a leak. Degradation at a fixed VU count is saturation; degradation over time at constant load is a leak.

4 · Regression comparison

Gotchas

• Generated scripts miss correlation. Agents happily hardcode a session token from an example. Real load tests must extract tokens, ids, and CSRF values from responses. Review for this specifically — it's the most common defect in generated k6 code.
• Think time gets forgotten. Without sleep(), 200 VUs generate load no real population of 200 users ever would, and your results are meaningless.
• Local runs are load-generator-bound. Your laptop is not a load generator. Past a few hundred VUs you're measuring your own machine.
• Long runs block. A 30-minute soak inside a conversation is awkward. Run those in CI and have the agent read the output afterwards.

Why a tester should care

Almost every weak UI test has the same flaw: it asserts on what the UI says happened rather than on what happened. The UI can show "Saved" while the write silently failed, landed in the wrong tenant, or skipped the audit trail. Database access gives your tests an oracle the application didn't produce — the single biggest quality upgrade available to a functional suite.

For Supabase specifically there is a second, sharper use: Row Level Security verification. RLS policies are security controls expressed as SQL, they're easy to get subtly wrong, and the failure mode is cross-tenant data exposure. Being able to ask "which tables have RLS disabled" and to run the same query as two different roles is a security test you can run in a sentence.

Tool surface

Wire it up

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": [
        "-y", "@supabase/mcp-server-supabase@latest",
        "--read-only",
        "--project-ref=<staging-project-ref>"
      ],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "${SUPABASE_ACCESS_TOKEN}"
      }
    }
  }
}

Both flags matter and they do different jobs. --read-only means no tool call can mutate data. --project-ref pins the server to one project, so a confused agent cannot reach your production instance even if it names it. Set both.

For plain Postgres, use a dedicated read-only role rather than trusting a flag:

CREATE ROLE qa_agent_ro LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE app_staging TO qa_agent_ro;
GRANT USAGE ON SCHEMA public TO qa_agent_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO qa_agent_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO qa_agent_ro;

Workflows

1 · Verify what the UI claimed

Three assertions the UI cannot fake. This is what a real functional test looks like.

2 · Multi-tenant isolation

3 · Migration verification

4 · Test-data reconnaissance

5 · Correlate a UI failure with a server error

Gotchas

• Query results land in the context window. SELECT * on a big table is both a context problem and a privacy problem. Always constrain columns and add a LIMIT.
• PII discipline. Even in staging, if the data is a production copy it is production data. Ask for aggregates and shapes, not raw customer rows.
• The reference Postgres MCP server was archived. Several community successors exist with different feature sets. Verify maintenance before trusting one with a connection string.
• Testing through the database creates coupling. Assertions on internal schema break when the schema legitimately changes. Assert on the columns that encode business meaning, not on every field.
• Don't let it write fixtures into shared environments. If it needs to seed, give it a branch or an ephemeral database, not the team's staging instance.

What it actually does

Set the expectation correctly and this server is useful; set it wrongly and you'll be frustrated for an hour. The reference Fetch server retrieves a URL and converts HTML to markdown for the model to read. It is a content retrieval tool, not an HTTP client. It does not give you arbitrary methods, custom auth headers, or response-time assertions.

For real API testing use Postman MCP, or have the agent write a script. Use Fetch for what it's good at: pulling documentation, changelogs, spec pages, or a status endpoint's JSON into context so the agent can reason about it.

Tool surface

One tool: fetch, taking a URL, an optional max_length, a start_index for paging through long documents, and a raw flag to skip markdown conversion. That's the whole thing.

Wire it up

{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch", "--user-agent", "qa-agent/1.0"]
    }
  }
}

Requires uv. There is a --ignore-robots-txt flag; leave it off.

Workflows

1 · Read the docs the agent needs

2 · Health-check sweep

3 · Pull a spec into context

Gotchas

• Not an HTTP client. No POST bodies, no custom auth headers, no timing assertions.
• JS-rendered pages come back empty. Use Playwright or Puppeteer for SPAs.
• Content is untrusted. A fetched page saying "ignore previous instructions" is an injection attempt, and a fetch tool is the cheapest possible delivery mechanism for one.
• Long documents truncate. Use start_index to page rather than assuming you got everything.