Skip to content
MAF Learning Hub
Advanced Govern Discover Duration: 30 min

Protocol conformance and spec validation

Prerequisites: multi-broker-test-pyramid

Regression asks “did behavior break over time?” Conformance asks a different question entirely: “does the wire format match the exact protocol spec the broker expects?” This is independent of business logic, and it needs its own purpose-built suite.

What you will learn

  • How to validate A2A/MCP wire conformance per protocol version.
  • How to validate agent cards and MCP tool specs independent of runtime.
  • Why cross-version interoperability needs explicit coverage.

Protocol conformance testing (A2A, MCP)

Validate that the actual wire format matches the exact protocol spec version the broker expects. Mismatched versions - for example a client speaking A2A 0.3.0 against a broker expecting 1.0 - can cause hard failures such as missing required fields, even when routing and business logic are otherwise correct.

  • Maintain explicit coverage per protocol version in use across the estate, since different agents/brokers may be pinned to different A2A versions during a migration window.
  • Validate any externally connected A2A agent against the official A2A specification for the version it claims to support, before it is allowed to connect to a broker.

Use the A2A Schema Validation Policy and MCP Schema Validation Policy as fast-fail gates: send a deliberately malformed request or response and confirm the policy rejects it, rather than only trusting that it silently works.

# Conformance case: assert malformed A2A is rejected, not silently accepted.
case: a2a-missing-required-field
send:
  jsonrpc: "2.0"
  method: "message/send"
  # 'params.message' intentionally omitted to violate the v0.3.0 schema
  params: {}
expect:
  gateway_policy: a2a-schema-validation
  result: rejected            # hard-fail gate; must NOT reach the broker
  error_contains: "required"

Agent card / MCP spec validation

Agent cards and MCP server tool specs need schema/spec validation independent of runtime behavior:

  • Is the card well-formed?
  • Do declared skills/capabilities match what the agent actually does?
  • Does the MCP server’s declared tool spec match what it actually returns?

Run this whenever a card or spec is published or changed, catching a malformed or inaccurate spec before it reaches production discovery. This is the assurance counterpart to cataloging agents in Discover and catalog agents in Exchange.

Cross-version interoperability

Where multiple A2A protocol versions coexist, test that your client/broker correctly handles both - not just the version you assume is standard. Use mocking tooling that supports multiple protocol versions and streaming (SSE) so combinations can be tested without depending on live infrastructure for every pairing. The configurable A2A mock from Isolating agents with reusable A2A mocks is a natural home for these version-specific fixtures.

Forward-looking

The conformance-case YAML is illustrative. Confirm exact policy identifiers, error shapes, and supported protocol versions against the official Included Policies directory and the A2A/MCP schema validation policy docs before use.

Where to go next

Wire format is only one property. Next, validate topology, auth, and policy consistency: Graph-level, auth, and governance testing.

References