A public MCP server exposes a search tool. Logs show one caller issuing thousands of tools/call requests per minute, many with oversized and malformed arguments. Which server-side control does the tools specification require for this situation?
Select an answer to reveal the explanation.
Short Explanation
Picture a ticket counter with no queue and no ID check — that's your server right now. You need a line (rate limiting) and someone checking every form (input validation). Annotations and cache hints won't save you, because a hostile caller simply ignores them.
Full Explanation
The tools specification lists four things servers MUST do: validate all tool inputs, implement proper access controls, rate limit tool invocations, and sanitize tool outputs. Rate limiting bounds how much work a single caller can force the server to perform, and input validation rejects oversized or malformed arguments before they reach the tool's business logic; a bad argument value is reported as a tool execution error so a well-behaved model can correct itself. Tool annotations are hints that describe behavior for clients; idempotentHint says repeated calls with the same arguments have no additional effect, which neither limits a caller nor reduces load, and clients must treat annotations from untrusted servers as untrusted anyway. A ttlMs value is a freshness hint for cached list results, not a throttle, and an abusive caller does not need to rediscover a tool to keep calling it. readOnlyHint signals that a tool does not modify its environment, which if anything makes a host less inclined to prompt. Exam caveat: these MUSTs are server-side; clients separately SHOULD implement timeouts and confirmations. Operational check: send a burst of calls and an oversized argument from a test client and confirm throttling responses and a validation error appear.