A SaaS vendor ships one MCP server. Months later, a new AI host that the vendor has never tested launches with MCP support. Why can that host use the vendor's server without any change by the vendor?
Select an answer to reveal the explanation.
Short Explanation
It's like a new phone working with your old Bluetooth speaker — neither maker had to talk to the other, because both follow the same standard. Your server speaks MCP, the new host speaks MCP, and that's the whole deal. No adapters, no per-host plugins.
Full Explanation
MCP's interoperability comes from a shared, openly specified protocol. A server that implements the specification correctly exposes its tools, resources and prompts through standard methods, and any conforming host can create a client, call server/discover or send requests with the required _meta, list primitives and invoke them. Neither party needs to know about the other in advance, which is why an untested host can use an existing server. Downloading the vendor's SDK and generating an adapter misplaces the effort; SDKs help developers implement the protocol, but interoperability happens on the wire, not through per-server code generation in the host. Detecting the host from clientInfo and loading a host-specific plugin contradicts the guidance that clientInfo is self-reported, unverified and should not change server behaviour, and it would reintroduce the per-host work MCP removes. A registry that translates servers into proprietary formats is not how MCP works; registries help people find servers, but hosts speak MCP directly to them. Exam caveat: interoperability still depends on shared protocol versions and capabilities, so a host speaking only a revision the server does not support will get an UnsupportedProtocolVersion error. Operational check: test the server with a second, independent MCP host and confirm discovery, listing and tool calls work without any vendor change.