A host team is writing the client-side checklist for calling tools on third-party MCP servers. Which set matches what the tools specification says clients SHOULD do?
Select an answer to reveal the explanation.
Short Explanation
You're the one carrying results into the model's ears, so you check them first, you don't wait forever, and you keep a record. That's the client's job list. The trap is the server's list, which covers the same worries from the other side.
Full Explanation
The tools specification lists client recommendations alongside server obligations. Clients should prompt for user confirmation on sensitive operations, show tool inputs to the user before calling the server, validate tool results before passing them to the LLM, implement timeouts for tool calls, and log tool usage for audit purposes. Validating results matters because tool output from a third-party server can be malformed or adversarial and flows straight into the model's context; timeouts prevent hung calls and resource exhaustion; audit logs show which tools ran, when and with what arguments. Sanitizing outputs, rate limiting and access control are server MUST-level duties, performed where the tool runs, not by the client. Trusting readOnlyHint from third-party servers violates the rule that annotations are untrusted unless the server is trusted, public caching of tool results ignores per-user data, and forwarding tokens to upstream APIs is token passthrough, which the authorization rules forbid. Relying wholly on the server, retrying without limit and logging only failures abandons validation, bounded retries and a complete audit trail. Exam caveat: these are SHOULD-level duties, so they are best practice rather than strict requirements. Operational check: confirm the host enforces a per-call timeout, validates structuredContent against outputSchema and writes an audit log entry for every call.