Why Interoperability Matters

Goal

Explain how a shared protocol reduces custom integrations while keeping version checks, validation, trust, and authorization explicit.

Why shared rules matter

Imagine three agent apps that each use four outside services. If every app invents a different request format for every service, the team must maintain many custom adapters. A shared protocol reduces that repeated work.

A protocol is an agreement about communication. It can define operation names, data shapes, IDs, version rules, errors, discovery, and security fields. It does not decide your business policy. Your application still decides which remote systems to trust and which actions a user may perform.

without a shared protocol: app A ↔ custom adapter ↔ service X
with a shared protocol:    app A ↔ documented boundary ↔ service X

So compatible and trusted are different. A server can speak the right protocol and still advertise an action that this user must not call. A remote agent can also return perfectly shaped but false or malicious data. The harness must check both the protocol contract and local policy.

Version and trust are separate

Version checks are part of interoperability too. If the client expects one release and the endpoint implements another, silently continuing can cause confusing errors. The Level 13 project records the expected MCP release and A2A version with each fixture.

MCP and A2A solve related but different problems. MCP exposes context and capabilities such as tools and resources. A2A supports task-oriented communication between independent agent systems.

Use different protocols for different boundaries

For example, a travel assistant might use MCP to read a calendar and A2A to delegate a longer itinerary task to a travel agent. The calendar call is one capability call. The remote travel agent can keep task state and return artifacts later. The parent harness should trace both, but it should not pretend their lifecycles are identical.

A protocol boundary also helps testing. Save structured requests and responses as fixtures. Then you can test a version mismatch, unknown capability, malformed message, policy denial, or remote failure without calling the real service every time.

Test the boundary, not just the happy path

The tradeoff is another dependency. Specifications change, implementations can lag, and optional features may differ. That is why this level pins exact versions.

Use two checks in order. First: Is this message valid for the expected protocol version? Second: Should this caller and task be allowed to use it or trust its result? Keeping those questions separate makes upgrades easier to reason about.

Predict

A remote endpoint speaks the expected protocol version but advertises a destructive operation. What should the local harness conclude?

Protocol compatibility is satisfied, but local authorization must still decide whether that operation is permittedThe operation is automatically trusted because the protocol data is validThe client should execute the operation once to learn whether it is safe

Run the local Lab

Run:

python3 labs/notebooks/level-13/l13-01-interoperability.py

The script compares compatibility and authorization separately.

1. Run it unchanged. Confirm that ok ends in call, version-mismatch is rejected for compatibility, and policy-denied is rejected for authorization.
2. In the ok case, find "expected":"2026-07-28". Before editing, predict what will happen if only that expected version changes while observed stays "2026-07-28".
3. Change only the ok case's expected value to "2025-11-25", then rerun.
4. The formerly valid case should now report compatible: False and reject the version mismatch while its capability is still authorized. Explain why protocol compatibility and permission are independent checks.

Loading lab…

Quick Check

1. What does a shared protocol mainly reduce?

The possibility that specifications or implementations will change over timeThe need for any local authorization or input validation once endpoints are compatibleThe need for every pair of systems to invent private message formats

2. Why pin a protocol version in tests?

To test compatibility against one known rule setBecause version metadata replaces capability and policy checksBecause older versions are usually insecure

3. Which statement best separates MCP and A2A in this course?

MCP connects hosts to tools and context; A2A connects separate agentsMCP handles local files; A2A handles cloud-hosted agentsThey are identical wire protocols with different names

0 of 3 questions answered.

Explain it back

Describe one system that uses both an MCP capability and an A2A remote agent. Explain which validation and authorization checks belong at each boundary.

Key Takeaways

• Interoperability reduces private adapter coupling.
• Compatibility is not the same as trust or authorization.
• Version pinning makes protocol behavior testable.
• MCP and A2A serve related but distinct integration roles.
• Protocol fixtures improve failure and upgrade testing.

Next Lesson

Next, L13.2 — Tool and Resource Protocols distinguishes callable capabilities from retrievable data.

References

• Model Context Protocol, 2026-07-28 Specification.
• Model Context Protocol, 2026-07-28 Specification Release.
• Agent2Agent Protocol, v1.0.0 Specification.