A remote server unlocks its administrative tools whenever the io.modelcontextprotocol/clientInfo name in the request _meta equals a well-known client product. What is wrong with this design?
Select an answer to reveal the explanation.
Short Explanation
Checking clientInfo is like letting someone into the server room because their name badge is handwritten "IT." Anyone can write anything. If you're gating admin tools, base it on who's authorized, not what the client calls itself.
Full Explanation
Every request may carry io.modelcontextprotocol/clientInfo, the client's name and version, and results may carry serverInfo. The specification states both are self-reported by the sender and not verified by the protocol, are intended for display, logging and debugging, and should not be used to change behaviour or relied on for security decisions. A malicious client can claim any product name, so gating administrative tools on it grants those tools to anyone who copies the string. Access decisions for a remote server belong to MCP authorization: validate the bearer token, confirm its audience, and use its scopes and subject to decide what the caller may do. Adding a version check fails for the same reason; the version is just another self-reported string. Treating MCP-Protocol-Version as authentication fails by concept, since that header only states which protocol revision the request uses and must match the _meta value; it identifies no one. Switching to serverInfo fails because serverInfo describes the server to the client, is also unverified, and carries no signature. Exam caveat: tools/list may vary by the authorization presented, so a server can hide admin tools from callers whose scopes do not permit them. Operational check: send a request claiming the trusted product name with a low-privilege token and confirm the admin tools remain unavailable.