A shared MCP server must serve your whole company from one deployment. Which transport fits?
Why A is the answer
Streamable HTTP
Stdio connects local processes on one machine. Remote servers use Streamable HTTP, and MCP recommends OAuth for tokens.
In detail
- Stdio connects local processes on one machine, so it cannot serve a company from one deployment.
- Streamable HTTP is the MCP transport for remote servers.
- MCP recommends OAuth to obtain tokens for these remote connections.
- A remote server needs real authentication, because it is reachable over a network.
Use case
An illustrative scenario, not a real incident.
A company wants one MCP server for its internal knowledge. Stdio would mean a local process on each laptop. Streamable HTTP gives one deployment that every engineer connects to, using OAuth for tokens.
See it in different ways
flowchart TD
A{"Where does the server run?"} -->|"Same machine"| B["Stdio"]
A -->|"Remote"| C["Streamable HTTP"]
C --> D["OAuth for tokens"]flowchart LR H["Host"] --> C1["Client 1"] --> S1["Server 1"] H --> C2["Client 2"] --> S2["Server 2"] H --> C3["Client 3"] --> S3["Server 3"]
flowchart TD
Q{"Where does the server run?"}
Q -->|"On the user's machine"| A0["Stdio"]
Q -->|"One shared deployment"| A1["Streamable HTTP with OAuth"]Key point: Stdio is local, and Streamable HTTP is for shared remote servers.
Why the other options are wrong
- B. Stdio, launched as a subprocess on each engineer's own laptop
- That is a separate local process per engineer, which is not one shared deployment.
- C. Reading and writing a shared file on a network drive for each request
- A shared file is not an MCP transport, and it would be fragile.
- D. Standard input piped between machines through an SSH connection
- Piping stdio through SSH is not the standard remote transport, and it does not scale to a company.