A platform team places a gateway between its hosts and several back-end MCP servers. Hosts connect to the gateway, and the gateway forwards calls to the back ends. How should the team reason about the gateway's protocol obligations?
Select an answer to reveal the explanation.
Short Explanation
A gateway wears two hats at once. Facing the hosts it's a server, and facing each back end it's a client, so you follow the rules for both. Passing tokens straight through is the trap.
Full Explanation
MCP defines roles by behavior on each connection. A gateway that accepts connections from hosts answers their requests, so on that side it is an MCP server and must meet server obligations such as validating inputs, publishing accurate capabilities, and, on HTTP, acting as an OAuth resource server that validates token audience. On the other side it opens connections to each back end, so it is an MCP client there, with one client per back-end server, attaching protocol version and capabilities to every request and respecting each back end's capabilities and errors. Treating the gateway as a transparent relay outside the protocol ignores that it parses and re-issues MCP messages and therefore takes on both sets of duties. Calling it a host misplaces responsibility; consent belongs to the host application the user works in, and a gateway still speaks the protocol on both sides. Forwarding each host's access token unchanged is token passthrough, which the specification forbids: a server must accept only tokens issued for itself and must obtain separate credentials for any upstream service. Exam caveat: when aggregating tools from several back ends, the gateway faces the same naming-collision problem a host does and should disambiguate. Operational check: confirm the gateway validates tokens issued for its own audience and uses distinct credentials for each back-end connection.