Compliance and conformance

This page states, precisely and without overclaiming, what "MCP-compliant" means for MCPG: which protocol versions it speaks, how that conformance is verified, and where the boundary of the claim sits. The short version — MCPG passes the upstream, third-party MCP conformance suite on both wire versions it serves, and that suite runs as a required gate on every CI build.

Dual-wire MCP support

MCPG serves two MCP wire versions concurrently, negotiated per session:

A single gateway accepts clients on either version; the version is selected at initialize time and the server responds on the negotiated wire for the life of the session.

How conformance is verified

We do not self-certify against a hand-written checklist. MCPG is tested against the upstream @modelcontextprotocol/conformance suite — the third-party conformance harness published by the Model Context Protocol project itself — run against a real MCPG built from the same commit. The harness drives the gateway over HTTP as an MCP client and asserts protocol behavior scenario by scenario.

This runs in CI as a dedicated, required job: a matrix over both wire versions (2025-11-25 and DRAFT-2026-v1), each booting a fresh gateway and running the suite's active scenario set. A regression on either wire fails the build — conformance is a merge gate, not a nightly afterthought.

Latest results

From the most recent harness run (suite @modelcontextprotocol/conformance, both wires, all active scenarios):

Both wires pass with zero failed checks. Coverage spans initialize and negotiation, tools (text / image / audio / embedded / mixed content, errors, progress, sampling, elicitation), resources (list / read / templates / subscribe / unsubscribe), prompts, logging, completion, ping, SSE multi-stream, and DNS-rebinding protection. The DRAFT-2026-v1 run adds the modern-wire scenarios: stateless server, caching, SEP-2164 resource-not-found, and the full input-required-result family (state, multi-round, tampered-state, capability checks).

The handful of DRAFT-2026-v1 advisory results are not failures: the warnings flag optional notification behaviors (e.g. emitting tools/list_changed or prompts/list_changed on subscription) the suite would like to see but the spec does not require, and the skips are checks the suite declines to run against the gateway's current capability set. None are MUST violations — the failed count is zero on both wires.

These numbers reflect a point-in-time run. The authoritative, always-current result is the conformance job on the latest CI build — it must be green for any change to merge. The per-scenario checks.json is uploaded as a build artifact so each result is independently inspectable.

What this claim does and does not cover

To keep the statement honest:

• It covers MCP protocol conformance — that MCPG, as an MCP server, behaves per the specification on both wire versions, as judged by the project's own third-party harness.
• It does not assert a formal certification, an audit opinion, or a third-party attestation (e.g. a SOC 2 report). It is a reproducible, CI-enforced engineering result, not a signed compliance certificate.
• Adjacent compliance — the controls a procurement team asks about (every access logged, tamper-evident records, identity verification, least-privilege plugin trust) are documented and enforced in MCPG; see Audit trail, Identity and authorization, and Plugin security. MCPG's audit lane is built to satisfy the logging requirements of SOC 2, HIPAA, PCI-DSS, GDPR, and ISO 27001, but MCPG itself does not issue framework certifications.

Reproducing it yourself

The harness is open and runnable against your own build — there is nothing proprietary in the verification path:

# from the repo root
nx run mcpg:conformance:2025-11-25
nx run mcpg:conformance:DRAFT-2026-v1
# or both, exactly as CI runs them:
nx run mcpg:conformance

Each run builds MCPG, boots it, runs the upstream suite, and prints a pass/fail/warn/skip summary. The same command is what the CI gate executes.