A server team is preparing to expose a payments tool to external MCP clients and drafts its security obligations. Which set matches what the tools specification says servers MUST do?
Select an answer to reveal the explanation.
Short Explanation
Picture a vault's security desk: check what comes in, check who's asking, limit how fast they can ask, and clean up what goes out. That's the MUST list you sign up for when you run a server. The trap is the host's checklist, which looks similar but belongs on the other side of the wire.
Full Explanation
The tools specification's security considerations divide duties between the two sides. Servers must validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitize tool outputs. Those four duties apply regardless of which client calls the tool, because a server cannot assume the host will enforce anything on its behalf; MCP itself cannot enforce security principles at the protocol level. The set built around annotations, clientInfo and public caching gets each item wrong: annotations are hints that clients treat as untrusted, clientInfo is self-reported and unverified and should not drive security decisions, and per-user payment data must never be cached with a public scope. The set about confirmation prompts, showing inputs and validating results lists client recommendations, which are SHOULD-level duties of the host, not server obligations. Marking a tool destructive and relying on hosts delegates the server's own controls to parties it cannot verify, and the protocol blocks nothing based on that hint. Exam caveat: for a remote HTTP server, OAuth-based authorization with audience-validated tokens is how access control is commonly applied, while stdio servers take credentials from the environment. Operational check: test the payments tool with malformed input, an unauthorized caller and a burst of calls, and confirm each is rejected or throttled.