An internal knowledge-base tool must serve about 2,000 employees, with central updates and per-user access control, from a single deployment managed by the platform team. How should it be delivered as an MCP server?
Select an answer to reveal the explanation.
Short Explanation
One kitchen feeding the whole office beats a hot plate on every desk. The trap is stdio: it's great for local, single-user tools, but it can't give you one central deployment with per-user tokens.
Full Explanation
Streamable HTTP lets a server run as an independent process that handles many client connections at a single MCP endpoint, which matches one centrally managed deployment serving thousands of users. Because it is HTTP-based, it should use MCP authorization: the server acts as an OAuth resource server, each employee's client obtains a token for that server's audience, and scopes enforce per-user access while updates ship once. Installing a stdio server on every laptop multiplies deployments and update work, and a shared service password removes individual identity and makes revocation all-or-nothing. The authorization specification explicitly does not apply to stdio; stdio servers retrieve credentials from the environment, so pairing stdio with OAuth on every message misreads the spec. HTTP+SSE from 2024-11-05 is deprecated and new implementations should not adopt it, and Mcp-Session-Id belongs to earlier revisions; the current protocol is stateless and identifies users through authorization, not sessions. Exam caveat: a remote server should still validate Origin and use HTTPS. Operational check: confirm an unauthenticated request returns 401 with a WWW-Authenticate header pointing to protected resource metadata, and that two employees' tokens carry different subjects in the server's audit log.