Agent-to-Agent Protocol Testing: How to Verify Your A2A Implementation

What Agent-to-Agent Protocol Testing Covers

Agent-to-agent protocol testing is the practice of verifying that an agent implementing the A2A specification correctly advertises what it can do, accepts work through a supported transport, moves tasks through valid states, and authenticates callers the way its own agent card claims it does.

That scope matters because A2A is deliberately opaque about internals. The protocol treats a remote agent as a black box, so the only contract you can test from the outside is the one the agent publishes. Everything you assert has to come from the card, the transport, and the task stream.

The A2A specification is at version 1.0.0, and it defines three protocol bindings: JSON-RPC, gRPC, and HTTP+JSON. Every field name and task state quoted below is taken from the protocol definition the project publishes in the open.

The Two Layers You Have to Test Separately

Teams that ship A2A agents usually test one layer and assume it covers the other. It does not. A schema-perfect agent can return confidently wrong answers, and a genuinely helpful agent can fail every conformance check in the suite.

Sections three through seven below cover the conformance layer. Section nine covers behavior. Both belong in the same pipeline, and the rest of this guide treats them as two suites rather than one. For the wider problem of verifying what a group of agents actually does once they are working together, see our guide to multi agent testing.

Start With the Agent Card

The agent card is a JSON document served at /.well-known/agent-card.json. It is public, unauthenticated, and machine-readable, which makes it the highest-value first test in any A2A suite: one HTTP GET tells you whether an agent is discoverable at all.

The version 1.0.0 schema marks eight card fields as required: name, description, supportedInterfaces, version, capabilities, defaultInputModes, defaultOutputModes, and skills. Provider details, documentation URL, security schemes, and signatures are optional.

The single biggest change from the 0.3.x era is that supportedInterfaces replaced the older url and preferredTransport pair. Each interface entry carries its own URL, protocol binding, and protocol version, so one agent can advertise several bindings at once.

We ran a discovery check against two agents publishing public cards on August 20, 2026. Both returned HTTP 200 and both still use the pre-1.0 card shape, which is exactly the version drift a conformance test is meant to surface:

A2A agent-card discovery check  (spec v1.0.0 required fields)
run: 2026-08-20

GET https://perkoon.com/.well-known/agent-card.json
  HTTP 200  (1387 ms)
  declared protocolVersion : 0.3.0
  supportedInterfaces      : (field absent - pre-1.0 shape)
  v1.0.0 required missing  : supportedInterfaces
  skills declared          : 4

GET https://openstoa.xyz/.well-known/agent-card.json
  HTTP 200  (615 ms)
  declared protocolVersion : (field absent)
  supportedInterfaces      : (field absent - pre-1.0 shape)
  v1.0.0 required missing  : supportedInterfaces, defaultInputModes, defaultOutputModes
  skills declared          : 5

Neither agent is broken. Both were built against 0.3.x, which was current when they shipped. The point is that a client written against 1.0.0 cannot rely on supportedInterfaces being present in the wild, so your test suite needs to assert the version it targets rather than assume the ecosystem has caught up.

For interactive checks, the A2A Inspector is a web tool that fetches an agent card, runs specification compliance checks against it, and exposes a debug console showing the raw JSON-RPC 2.0 messages exchanged with the agent.

Task Lifecycle Assertions

A task is A2A's unit of work. It carries a unique ID and moves through defined states, which makes the lifecycle the most testable part of the protocol: every transition is either legal or it is not.

Version 1.0.0 defines nine task states. The distinction that matters for testing is terminal versus interrupted, because they demand opposite client behavior.

The state most implementations get wrong is rejected. It is terminal and it means the agent decided not to do the work, which is different from failed, where the agent tried and could not. A client that retries a rejected task will loop forever, so assert that your client treats the two differently.

Test auth-required explicitly as well. It is an interrupted state rather than an error, so an agent that returns a transport-level 401 instead of moving the task to auth-required is not conformant even though the caller was, correctly, refused.

Interrupted states are also where delegation breaks in practice, because the work is now split across two agents and neither owns the whole outcome. Our guide to agent handoff testing covers the failure modes and test cases for work passing between agents.

Testing Streaming and Push Notifications

Both streaming and push notifications are optional capabilities, and that is the first thing to assert. An agent must declare capabilities.streaming as true before a client may call the streaming operations, and capabilities.pushNotifications as true before registering a webhook.

• Undeclared capability - Call the streaming operations against an agent that does not advertise streaming and assert it refuses cleanly rather than half-supporting the call.
• Event ordering - The specification requires operations to maintain event ordering in streaming delivery, so assert that status changes and artifact chunks arrive in sequence, not just that they all arrive.
• Webhook delivery - Push notifications are HTTP POSTs to a client-registered endpoint. Stand up a real receiver in the test and assert the payload lands, rather than trusting the registration call returning 200.
• Config lifecycle - Push notification configurations support create, get, list, and delete. A deleted config that still fires is a leak worth catching before production.
• Disconnect and resume - Long-running tasks are the reason push notifications exist. Drop the client mid-task and assert the update still arrives at the webhook.

Webhook tests are where most A2A suites stay shallow, because asserting a callback needs a reachable endpoint during the test run. Treat it as a real integration test with a real listener, the same way you would test any other async callback.

Auth and Transport Conformance

A2A servers must verify client identity through the security schemes they declare on their own card, and must reject invalid credentials with an appropriate error response. That gives you a precise negative test: read the declared schemes, then call the agent without them.

The specification supports API keys, HTTP auth, OAuth2, OpenID Connect, and mutual TLS. Whichever the card declares is the one your test must exercise, because an agent that advertises OAuth2 but silently accepts anonymous calls is the failure mode worth catching.

On transport, version 1.0.0 defines three bindings: JSON-RPC, gRPC, and HTTP+JSON. All implementations must provide functionally equivalent representations of the same data structures across every binding they support.

That single rule is the most useful cross-binding test you can write. Send the same task over each advertised binding and diff the results. If an agent returns richer artifacts over gRPC than over HTTP+JSON, it is not conformant, and any client that picked the wrong binding gets a degraded experience with no error to explain it.

Running the Official A2A TCK

The A2A Technology Compatibility Kit is a compatibility test suite that validates A2A Protocol implementations across gRPC, JSON-RPC, and HTTP+JSON transports. It is pytest-based and maintained in the open by the a2aproject organization.

Its most useful design decision is that tests are organized by RFC 2119 requirement level rather than by feature area, so you can gate a pipeline on absolute requirements while still seeing where you fall short of recommendations.

# Run only absolute (MUST) requirements against a running agent
./run_tck.py --sut-host http://localhost:9999 --level must

# Scope a run to a single transport binding
./run_tck.py --sut-host http://localhost:9999 --transport grpc

• MUST - Absolute requirements. A failure here is a hard failure and is the correct level to block a release on.
• SHOULD - Expected unless you have a valid reason to differ. Failures are recorded as expected failures rather than breaking the run.
• MAY - Genuinely optional. These tests skip when the agent has not declared the matching capability.

Every run writes four report formats to a reports directory: a machine-readable compatibility JSON, a compatibility HTML summary, a pytest HTML report, and JUnit XML. The JUnit output is what makes the suite drop straight into an existing CI reporting setup.

A2A vs MCP: What Changes When You Test Them

A2A and MCP get compared constantly and they are not alternatives. MCP connects one agent to tools and data. A2A connects agents to each other. A single system commonly runs both, and each needs a different test suite.

If you are building the tool-facing half of this stack, our guide to testing MCP servers covers schema drift and tool-selection evaluation in depth. For how the two protocols sit inside a wider architecture, see our explainer on multi-agent AI systems.

Testing What the Protocol Cannot See

Every check so far proves the wire contract holds. None of them read a single answer. An agent can pass the entire MUST tier and still invent a refund policy, treat two callers differently, or hand a customer information it should never have surfaced.

TestMu AI Agent Testing covers that second layer. You give it the agent's intended role and any supporting documentation, and it generates 60 to 100 or more test scenarios spanning happy paths, edge cases, adversarial inputs, and compliance situations, then runs them against the live endpoint.

More than 15 specialized evaluator agents run those scenarios in parallel, each owning one dimension: a hallucination hunter for invented facts, a bias detector for differential treatment, a data privacy guardian for PII exposure, an escalation handler for correct human handoff. Chat and voice agents score against 9 quality metrics, phone agents against more than 30 call metrics.

Results roll up to a production readiness verdict of green, yellow, or red, and every verdict cites the conversation turns that produced it. That evidence trail is what makes a behavior failure actionable rather than a score you have to interpret. For the scoring methods that sit underneath metrics like these, see our guide to LLM evaluation.

Two limits are worth knowing before you plan a run. Agents that stream partial responses are evaluated on the complete response rather than on streaming behavior itself, so token-level streaming quality needs your protocol suite instead. Agents in highly specialized domains such as medical diagnosis or legal analysis usually need custom validation criteria, because generic hallucination metrics miss domain-specific error modes.

One naming note, since A2A is an overloaded acronym. The testmu-a2a-cli documentation covers running these evaluations from the terminal, where the a2a refers to agent-to-agent testing, meaning our evaluator agents testing your agent. It is not an implementation of the Agent2Agent protocol described in this article.

Wiring Both Suites Into CI

Both layers emit JUnit XML and standard exit codes, so they compose into one pipeline stage without custom reporting glue. Run conformance first, because a broken card or transport makes behavior results meaningless. Our guide to continuous AI agent testing covers the wider pattern, from CI gate through to a production loop.

# 1. Protocol conformance - block the build on MUST-level failures
./run_tck.py --sut-host "$AGENT_URL" --level must

# 2. Agent behavior - evaluate answers, fail below the score threshold
testmu-a2a test \
  --agent "$AGENT_URL" \
  --spec "Support agent that handles billing and account questions" \
  --count 25 \
  --threshold 0.85 \
  --format junit \
  --output results/behavior.xml

Use environment variables rather than interactive login in CI. The behavior stage reads TESTMU_USERNAME and TESTMU_ACCESS_KEY, and the threshold flag converts a score into a pass or fail so the stage gates like any other test.

Point the behavior stage at a staging endpoint when your agent calls real external systems. An evaluation run drives real conversations, so an agent wired to a live payment processor will produce real side effects.

Once both suites are green in CI, the gap that remains is production drift. Our guides to agent observability and AI agent testing methodology cover trace-based monitoring and how simulation compares with LLM-as-a-judge scoring.

Conclusion

Start by fetching your own agent card and diffing it against the eight required fields for version 1.0.0. It takes one HTTP GET, and the two live agents checked for this article both failed that comparison, which tells you how common the gap is.

From there, add the official TCK at the MUST level to block releases on real conformance failures, then layer behavior evaluation on top so answer quality is tested as deliberately as schema shape. The protocol tells you the agents can talk. Only the second suite tells you they should be trusted to.