Your team ships an HTTP MCP server on Monday. By Thursday, security flags it: no authentication layer, exposed on the internal network, trusting that internal means safe. The rewrite takes a sprint. The transport choice was wrong from the start, and nobody caught it because nobody asked the transport question before they asked the implementation question.
Transport is not a deployment detail you configure at the end. It sets your authentication model, your latency floor, and — if you operate under APRA CPS 230 or the Australian Privacy Principles — your audit trail. Pick it in the first conversation, not the last.
The three transports and what each one actually solves
stdio is the right default for developer-facing tools. The MCP runs as a child process alongside Claude Code or whatever client is invoking it. Communication happens over standard input and output. Authentication is implicit: the OS user is trusted, and there is no network surface, no endpoint to enumerate, and no token to leak. For any MCP that runs on a single developer's machine (a code review tool, a local document analyser, an internal knowledge base query tool), stdio is the right answer, and choosing anything else adds complexity without adding safety.
HTTP is the right choice when the MCP needs to serve multiple users from a central host, aggregate connections to SaaS connectors, or persist tool state across sessions. The moment you move to HTTP, you own the authentication layer. Bearer tokens copied from a config file into a chat interface are not authentication. Pair HTTP transport with OAuth2 and scope claims. Not because it is best practice in the abstract. Because if you operate under the Australian Privacy Principles or APRA CPS 230, a compliance audit will eventually ask who authorised which tool call, and your interaction logs need to answer that question.
Server-Sent Events make sense when the tool needs to push partial results or progress updates before the tool call finishes. Think long-running document analysis, streaming policy data from a legacy system, or an agent surfacing intermediate steps to keep the user from assuming it has hung. SSE is not a performance upgrade over HTTP. It is a different user experience contract, and most enterprise use cases do not need it.
stdio. Local, single-user, zero network surface. Use for developer tooling and single-machine MCP servers.
HTTP. Multi-user, server-hosted, requires an auth layer you build and own. Use for shared internal APIs and SaaS aggregators.
SSE. Streaming, long-lived connections. Use only when partial results or live updates are a concrete user requirement, not a speculative one.
The auth trap that catches Australian enterprise teams
The most common mistake on Australian financial services MCP builds is shipping HTTP without authentication, behind an internal-network-only assumption. Internal networks leak. A misconfigured VPN rule, a contractor with broader access than intended, a lateral movement from an unrelated breach. These are not hypothetical scenarios, and the 2024 financial services incident reports confirmed it repeatedly.
Building OAuth2 into an HTTP MCP server from day one adds roughly $15,000 in engineering time. Retrofitting it after a compliance review surfaces gaps in your CPS 230 access-control obligations costs between $80,000 and $150,000 when you include the audit response, the remediation sprint, and legal review of interaction logs. The marginal cost of doing it right the first time is not a rounding error. It is ten to one.
The 'we will add auth later' position is a financial services liability waiting to activate. If your MCP has access to client data and runs without authentication, you are not building a proof of concept. You are building an incident report.
The MCP Transport Ladder
The decision has three rungs. Start on the lowest one that solves your current problem. Move up only when a concrete requirement forces you.
Rung 1: stdio. Start here for any developer-facing tool, proof of concept, or single-user MCP. No auth burden, no network exposure, fast to iterate.
Rung 2: HTTP with OAuth2. Move here when the MCP needs to serve multiple authenticated users, be shared across a team, or maintain state across sessions. Build the auth layer before you write the first endpoint. Not after.
Rung 3: SSE. Move here only when streaming is a stated user requirement backed by real feedback, not a speculative performance improvement or an engineer's preference.
When to stay on stdio longer than you think
Most Australian enterprise teams overshoot. They default to HTTP because it feels more production-ready, ship without auth because they are moving fast, and then spend two weeks in a security review before the internal pilot can proceed. stdio is a production transport for the right use case. A Claude Code MCP that helps your engineering team write consistent internal documentation does not need OAuth2, a central host, or a streaming interface. It needs to run reliably on the developer's machine and return useful output.
The pressure to ship HTTP first is almost always social, not technical. It feels more serious. It does not make the tool better.
Stay on stdio when the MCP is developer-facing and runs on a single machine.
Stay on stdio when the user base is one person or one team and multi-user access has not been confirmed as a real requirement.
Move to HTTP when you have confirmed users beyond the initial developer, compliance obligations requiring access logs, or session state that cannot live on a single machine.
Move to SSE when a specific user, in a specific workflow, has told you they need intermediate results before the tool call completes.
A Sydney financial services scenario
A Sydney financial services firm building a CRM-to-Claude MCP for 200 advisers does not start with SSE. They start with stdio for the proof of concept: two weeks, one developer, validates that the integration produces useful output against real CRM data. They move to HTTP with OAuth2 for the internal pilot: four to eight weeks, a cohort of 20 advisers, access logs that satisfy the CPS 230 audit question. They consider SSE only when adviser feedback identifies streaming claims data as a concrete workflow problem. Not before that conversation happens.
The sequence matters. Getting the transport wrong at rung one resets the sequence. Our AI Readiness Assessment maps the right architecture before the first line of code is written. If you are mid-build on an MCP that has outgrown its transport, the AI Automation Services team has rebuilt enough mismatched transport layers to know exactly where to look.
Start with the simplest transport that solves the problem in front of you. Move up when a real user requirement forces it. Build auth before the first multi-user deployment, not after the first incident.
