k11 API Functional QA
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QA_MCP_ROOT | No | Path to your project root containing the .qa-mcp/api-test.yaml configuration file. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Functional API testing. Tests are YAML flows in tests/api/: chained HTTP calls ('call: POST /orders'), values saved with 'save' and reused as ${name}, checks under 'expect' (status, json paths, headers, schema, time), read-only database checks ('db: SELECT ...' with :params), fixtures and cleanup. Use list_environments first, draft_flow for a user story, generate_negative_tests for rejection cases, write_flow to save, run_flows to run. Data-changing calls are refused on environments that don't allow writes; never put secrets in flows, use ${ENV:NAME}.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_environmentsB | Environments (base URL, whether writes are allowed and why), auth profiles, databases and fixtures from .qa-mcp/api-test.yaml, plus the flows in tests/api/. |
| draft_flowB | Turn a user story or acceptance criteria into scenarios, the spec operations most likely involved, and a flow skeleton to complete (chain IDs with save/${...}, add value and db checks). |
| generate_negative_testsA | Negative and boundary tests for one operation (e.g. 'POST /orders'), derived from the spec, including nested fields and array items: missing required fields, wrong types, values outside enums and min/max/length/item limits, missing parameters, no credentials, unknown IDs. Every case must get a 4xx, never a 5xx; boundary cases that must be accepted clean up after themselves. base_values supplies real values for the valid parts (e.g. {"customerId": "${fixture.customer.id}"}) with fixtures=["customer"]. Save the result with write_flow. |
| write_flowA | Save a YAML flow under tests/api/ after validating it. Won't overwrite unless asked. |
| run_flowsB | Run flows (default: everything in tests/api/) against an environment. Returns per-flow results with the failing checks and the request/response or query evidence; writes Markdown, JSON and JUnit reports. |
| call_apiA | Make one request (e.g. call='GET /orders/{id}', path_params={'id': '1001'}) to explore an API while writing tests. Same guardrails as flows: writes only where allowed, secrets masked, schema checked when a spec is set. |
| query_dbA | Run one read-only query (SELECT/WITH/SHOW/EXPLAIN) against a configured test database, with :named params. Masked columns are shown as •••. Use it to find test data and write db checks. |
| export_pytestA | Turn a flow into a plain pytest + httpx test (database checks included), so the suite can live without this tool. Returns the code; with write=true saves it under tests/ (never overwriting). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Most tools occupy clearly distinct steps of the QA workflow: discovery (list_environments), exploration (call_api), authoring (draft_flow, generate_negative_tests, write_flow), execution (run_flows), data (query_db) and export (export_pytest). The only soft overlap is between draft_flow (produces a skeleton) and write_flow (persists it), which an agent could momentarily conflate since both concern flow files. Descriptions largely resolve this by explaining the pipeline order.
Every tool follows the same snake_case verb_noun pattern (list_environments, draft_flow, write_flow, run_flows, call_api, query_db, export_pytest), with generate_negative_tests as the only longer variant and still the same convention. Verb choice maps predictably to action type (list/draft/generate/write/run/call/query/export). No camelCase or stylistic mixing.
Eight tools is well within the ideal 3-15 range and each one maps to a discrete step in the API-QA lifecycle, so nothing feels padded. No redundant aliases or duplicate execution paths exist.
The surface covers the full authoring-to-execution loop plus DB access and a pytest escape hatch, which is strong lifecycle coverage. The gap is around existing flows: there is no tool to read, edit, or delete a saved flow (write_flow refuses to overwrite), so revising an existing test requires external file access. Minor but real dead end for iterating on a failing flow.