A transit authority is building an MCP server that exposes on-time-performance data to Claude. Roughly forty analysts across three offices will use it, it must authenticate each analyst against the agency's identity provider, and it needs to be patched centrally when the schedule feed changes. Which transport choice fits these requirements, and why?

MCP transports differ in where the server runs and who can reach it, so the choice follows from deployment requirements rather than from anything about the data itself. The transit authority's constraints, many users across three sites, authentication against the agency identity provider, and central patching when the schedule feed changes, are all statements about operations.

A remote HTTP MCP server is a deployed network service that many clients connect to, which is what lets it sit behind the identity provider, apply per-analyst authorization, log centrally, and be upgraded in one place when the feed changes. One deployment serves all forty analysts, and a schema change reaches every one of them the moment it ships.

Claiming stdio is the only transport that can return structured tool results is simply false, since both transports carry the same MCP messages; a local subprocess runs with the privileges of whoever launched it and performs no identity-provider authentication on its own, while leaving forty installations to patch; and treating transport as a latency detail ignores that it decides whether the server is a per-machine subprocess or a shared administered service.

Exam caveat: stdio is the better answer when the capability must touch local resources, such as files on that machine, a local database, or a CLI already installed there, so the question is where the capability lives rather than which transport is more modern. Operational check: revoke one analyst in the identity provider and confirm their next tool call is rejected without touching their laptop.