An MCP server runs for many users across the company. Which transport and auth approach fits?
Why A is the answer
Streamable HTTP, with OAuth for authentication tokens
Stdio is for local processes on one machine. Remote servers use Streamable HTTP, and MCP recommends OAuth to obtain tokens.
In detail
- Stdio is for local processes on one machine.
- Remote servers use Streamable HTTP.
- MCP recommends OAuth to obtain tokens.
- Validate tokens on the server for every request.
Use case
An illustrative scenario, not a real incident.
A company-wide MCP server must know who is calling. Streamable HTTP with OAuth gives each user a token, so access can be checked and logged.
See it in different ways
stateDiagram-v2 [*] --> HowManyApps HowManyApps --> DirectTool: one app HowManyApps --> McpServer: many apps McpServer --> Stdio: local process McpServer --> StreamableHttp: remote, with OAuth
sequenceDiagram participant P0 as Client participant P1 as Auth server participant P2 as MCP server P0->>P1: Sign in P1-->>P0: Token P0->>P2: Request with token P2-->>P0: Result
Key point: Remote servers use Streamable HTTP, with OAuth for tokens.
Why the other options are wrong
- B. Stdio on a single server, reached by users through a shared remote desktop
- A shared remote desktop is not a server transport.
- C. A public HTTP endpoint protected by a hidden and hard-to-guess address
- A hidden address is not authentication.
- D. Stdio on each laptop, with a shared key stored in a project file
- A shared key in a project file cannot identify users, and it can leak.