A team divides work for a new MCP integration among the server developer, the host application developer and the end user. Who is responsible for implementing the consent and approval UI shown before a tool runs?
Select an answer to reveal the explanation.
Short Explanation
MCP is the plumbing, and plumbing can't ask anyone's permission. The host is the app your users actually look at, so you, the host developer, build the consent screens, servers describe what they offer, and users make the call. Expecting the protocol to pop up dialogs is the trap.
Full Explanation
In MCP's architecture the host is the AI application that creates and manages clients, coordinates the model, and enforces security policies and user consent. The specification states that MCP itself cannot enforce security principles at the protocol level and that implementors should build robust consent and authorization flows; the tools specification says applications SHOULD keep a human in the loop, show which tools are exposed, and present confirmation prompts. The consent UI is therefore the host developer's job, while the end user makes the decisions it presents. Server developers declare capabilities and describe tools, and annotations such as destructiveHint are untrusted hints a host may use when deciding whether to prompt; they do not define dialogs. End users do not write rules into a server's capabilities, which are declared by the server describing what it supports. The transport layer moves JSON-RPC messages over stdio or Streamable HTTP and has no user interface at all. Exam caveat: the protocol deliberately does not mandate a specific user interaction model, so hosts differ in how they present prompts while still being responsible for them. Operational check: in a host build, trigger a tool flagged destructive and confirm the host shows a confirmation naming the server, the tool and its inputs before anything is sent.