A server author wants the server's tools to behave consistently whichever MCP host connects to it, including hosts the author has never tested. Which approach best supports that portability?
Select an answer to reveal the explanation.
Short Explanation
Write to the standard, not to one host's quirks, and you'll work in any host that speaks MCP. The trap is sniffing clientInfo to fake portability, which the spec warns against.
Full Explanation
Portability in MCP comes from the shared specification. A server that exposes its functionality through standard tools, resources and prompts, and that reads the io.modelcontextprotocol/clientCapabilities carried in each request to decide what it may use, behaves predictably in any conforming host. If a feature needs a capability the client did not declare, the server returns MissingRequiredClientCapabilityError or falls back to core behaviour rather than guessing. Branching on clientInfo is discouraged: it is self-reported, unverified, intended for display, logging and debugging, and the specification says implementations should not use it to change behaviour. Assuming every host supports MCP Apps or Tasks ignores that extensions are disabled by default, require explicit opt-in on both sides, and vary by host according to the client matrix. Requiring server/discover before every request misreads the protocol: servers must implement discover, but calling it is optional for clients, and in a stateless protocol a server must not keep host profiles keyed to earlier calls. Exam caveat: hosts legitimately differ in user interface, such as how prompts appear, so the server should not depend on presentation details. Operational check: run the server against two different hosts and a minimal test client that declares no optional capabilities, and confirm core results are equivalent.