Checkpoint — MCP Interoperability and Trust

Before moving from tool/context interoperability into agent-to-agent collaboration, make sure the MCP half of the level forms one coherent boundary.

You should be able to explain why a protocol reduces custom adapter coupling without removing local policy. Compatibility answers whether two systems understand the same communication rules. Trust answers whether the remote endpoint, capability, credentials, and returned data are acceptable for the current principal and task.

For this course, MCP is pinned to the 2026-07-28 release. You should know the practical consequence of that pin: the core is stateless request/response, and examples that depend on the older session/handshake model should be checked before reuse. A client may use server/discover for capability information, but discovered capabilities still pass local filtering.

You should also be able to distinguish a tool from a resource. A side-effecting tool needs execution controls such as argument validation, authorization, approval where required, operation identity, and tracing. A resource read focuses more on scope, provenance, freshness, caching, and safe treatment of returned content. Both remain untrusted remote inputs.

Finally, describe the security layers around an MCP endpoint: configured endpoint identity, narrow credentials, local capability mapping, minimized request data, validation of returned content, and audit evidence. Successful protocol parsing is only the first layer.

Self-check

You are ready to continue if you can answer:

1. Why is protocol compatibility not the same as authorization?
2. Which MCP release is this course using?
3. What changed about the core session model in that release?
4. What should a client do with newly discovered capabilities?
5. How do tool and resource risk controls differ?
6. Why should remote returned text not override local policy?

If one answer is vague, rerun the relevant deterministic Lab and explain the failed fixture before continuing.

Check your reasoning with an applied interoperability case

Imagine an MCP endpoint passes the protocol-version check and discovery returns a new refund_order tool.

Do not treat discovery as authorization. The client should map the remote capability to a locally allowed capability set, validate its schema, check the current principal and workflow state, and require approval if local policy says the side effect needs it. Returned text stays untrusted data even though it arrived through a valid protocol message.

The same case separates the main ideas:

• compatibility means both sides understand the pinned protocol rules;
• authorization decides whether this caller may use this capability;
• the course pins MCP to the 2026-07-28 release, so older session assumptions must not be copied in unnoticed;
• a tool can create effects, while a resource is primarily read as data, so their controls differ;
• remote capabilities and content never override local policy merely because parsing succeeded.

Next Lesson

Continue with L13.7 — Agent-to-Agent Communication Concepts.