api-contract-qa
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QA_MCP_ROOT | No | Path to the project/service folder whose specs, consumer folders and reports the server may access (e.g. the service being checked). Specs and reports must live inside this project folder. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
API contract testing for OpenAPI 3.x, Swagger 2.0, GraphQL (SDL or introspection JSON), gRPC/protobuf (.proto), AsyncAPI 2.x/3.x and SOAP/WSDL 1.1; the format is detected automatically. Specs are project paths or git refs like origin/main:openapi.yaml. Operations are named 'GET /orders/{id}', 'QUERY order', 'RPC pkg.Service/Method', 'EMITS order.created' / 'RECEIVES order.cancel', or 'SOAP Port/Operation'. Use diff_contracts / assess_impact before merging a change, check_deployed_contract to compare a running service with the spec, check_live_conformance for HTTP responses, and generate_api_tests for REST tests. Results are deterministic. Put tokens in headers as ${ENV:NAME}, never literally.
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_operationsA | List the operations in a contract (OpenAPI, Swagger, GraphQL, .proto, AsyncAPI or WSDL; a project path or :). Also tells you the detected format. |
| diff_contractsA | Compare two versions of a contract (any supported format) and classify every change as breaking or compatible, with the rule, field path, before/after and severity. Example: base_spec='origin/main:openapi.yaml', head_spec='openapi.yaml'. |
| assess_impactA | Which known consumers a spec change breaks, and why (field-level when consumers list the fields they read/send). Verdict: breaking | breaking_no_known_consumers | compatible; needs_human when 2+ consumers or a high-criticality consumer break. Consumers come from .qa-mcp/consumers.yaml. |
| discover_consumer_usageC | Scan a consumer service's source code (inside the project) for calls to the provider, with file and line as evidence, and draft its consumers.yaml entry. HTTP paths, GraphQL query documents (exact fields read), gRPC stub calls, SOAP client calls, and AsyncAPI topic names. |
| check_live_conformanceB | Call a running endpoint (e.g. endpoint='GET /orders/{id}', path_params={'id': '1001'}) and check status, content type and the JSON body against the spec's response schema. Header values may use ${ENV:NAME}. |
| check_deployed_contractA | Compare what a running service publishes with the spec file: GraphQL introspection (url = the GraphQL endpoint), a WSDL URL (e.g. http://host/orders?wsdl), or a published OpenAPI/Swagger/AsyncAPI document (e.g. http://host/v3/api-docs). Verdict: matches | drift | incompatible. gRPC is not supported (needs reflection). Header values may use ${ENV:NAME}. |
| generate_api_testsA | Generate contract tests (status + JSON schema) for some or all endpoints: pytest + httpx, or Java REST Assured (JUnit 5). Returns the files; write them with write_test. |
| write_testB | Write a generated file under tests/ or src/test/ only. Won't overwrite unless asked. |
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
Each tool has a distinct role in a logical pipeline: list, diff, assess, discover, check live, check deployed, generate, write. The only pair with surface overlap is check_live_conformance vs check_deployed_contract, but the descriptions clearly separate request/response validation from pulling a published contract document, so misselection risk is low.
All eight names are snake_case verb_noun (list_operations, diff_contracts, assess_impact, discover_consumer_usage, check_live_conformance, check_deployed_contract, generate_api_tests, write_test). The two check_* tools even form a clean parallel pair.
Eight tools is well within the ideal 3-15 range and each maps to a concrete step in contract QA rather than padding. Generation and file writing are sensibly split rather than merged into one overloaded tool.
Coverage spans the full lifecycle: inspect, diff, impact, discover consumers, validate live and deployed, generate and write tests. Minor gaps: discover_consumer_usage only drafts a consumers.yaml entry with no tool to persist or manage entries, and gRPC conformance is explicitly unsupported, but agents can work around both.