A trainer describes, in order, the typical path from a host learning about a tool to the model reading that tool's output. Which ordering matches the MCP tool invocation flow with a human in the loop?
Select an answer to reveal the explanation.
Short Explanation
It's like ordering at a restaurant: you read the menu, pick a dish, have someone confirm the order, cook it, then serve it. Discovery comes first, approval comes before the call, and the result goes back to the model last. The trap is approval happening after the work is already done.
Full Explanation
The tools specification's message flow begins with discovery: the client sends tools/list and receives tool definitions. The host passes those to the model, the model selects a tool to use, and the client sends tools/call; the result returns to the client, which hands it to the model for processing. Layered onto that flow is the trust and safety guidance: there should always be a human in the loop able to deny tool invocations, with confirmation prompts and clear indicators when tools are invoked, and the host must obtain explicit user consent before invoking any tool. Approval therefore sits between the model's selection and tools/call. Selecting before tools/list is impossible, because the model cannot choose a tool it has never seen, and listing after the call is backwards. Calling the tool before the model selects it and before approval reverses cause and effect and defeats the human check. Starting with initialize uses the legacy handshake removed in 2026-07-28, and placing approval with the server after the result misses that consent belongs to the host before execution. Exam caveat: a host may cache tools/list results within their TTL, so discovery need not repeat before every call. Operational check: trace one invocation and confirm the approval prompt appears before the tools/call request leaves the client.