A team writes its MCP host and client in one programming language using that language's official SDK, and its servers in another language with a different official SDK. What should they expect about interoperability?
Select an answer to reveal the explanation.
Short Explanation
Two people can talk on the phone in the same language even if they bought different handsets. MCP's core is that shared language, but the optional add-ons only work when you've checked both handsets support them.
Full Explanation
MCP defines a single wire protocol: JSON-RPC 2.0 messages with per-request metadata over standard transports, specified by a schema that serves as the source of truth. Any conforming implementation, regardless of language or SDK, can exchange core messages with any other, which is the portability the protocol exists to provide. Extensions are different. SDKs may implement extensions but are not required to for protocol conformance, SDK maintainers choose which extensions they support, and extensions are disabled by default and need explicit opt-in. Teams must therefore confirm that both SDKs support any extension they plan to use, such as Tasks or MCP Apps, and fall back when one side lacks it. No official SDK uses a private wire format; each implements the same JSON-RPC protocol, and a proprietary format would break conformance. Conformance does not require implementing every extension. Protocol versions are revision dates such as 2026-07-28, declared on each request and negotiated per request, so SDK release numbers are irrelevant. Exam caveat: the protocol revision each SDK supports still matters, because a client and server need at least one revision in common. Operational check: call server/discover to compare supported versions and advertised extensions with what the client declares in its per-request capabilities.