You can prototype an impressive agent in a notebook, but you can’t run one in production without a transport strategy. The Model Context Protocol standardizes how agents call tools and access memory, but it intentionally does not define how bytes move between systems. That responsibility sits with your architecture. Most teams treat transport as an implementation detail, and default to whatever works in a development container. That shortcut becomes technical debt the moment the system faces real traffic. 

The symptoms are predictable: 

• Latency becomes inconsistent under load. 

• Streams stall without clear failure signals. 

• Security boundaries blur between internal and external systems. 

These are not edge cases. They are the inevitable outcome of using transport designed for convenience rather than reliability.

In a production environment, transport failure creates availability incidents. Model failures create incorrect answers or stop the system from working. Transport failure can also produce a bad output while the system stays online. Because of this, transport design belongs in reliability engineering, not just in application plumbing. 

Transport defines how quickly agents respond, how failures propagate, how systems recover, and how safely tools and memory services are exposed. When transport design conflicts with infrastructure reality, agents appear unstable even when tool logic and model behavior are correct. Stability in agent systems is determined at boundaries, not inside components.

This post examines the three dominant MCP transport models used in production systems. 

• stdio MCP provides process-level isolation and the lowest possible latency for same-host execution. 

• HTTP with Server-Sent Events enables cluster-scale orchestration, shared tool services, and internal memory systems. 

• HTTPS with Server-Sent Events enforces encryption and identity guarantees across trust boundaries, including customer, partner, and multi-organization environments.

You will learn where each model fits operationally, the real cost of running each at scale, and how mature agent platforms combine all three into a hybrid routing architecture. The goal is not to pick one transport; the goal is to match transport to the boundary, so that performance, reliability, and security remain predictable as systems scale from workstations to clusters to the internet edge.

Postgres as an MCP tool execution platform

Postgres is shifting from a passive storage engine to an active tool execution surface for agent systems. Through MCP servers such as our MCP server for Postgres, database functions, extensions, administrative operations, and query workflows become callable tools exposed through a standardized interface. This turns Postgres into part of the agent control plane, where SQL execution, extension logic, and data access happen as tool invocations rather than indirect application calls. In this model, the database is no longer only a persistence layer. It acts as a deterministic execution environment with transactional guarantees, auditability, and strong consistency, making it a natural backend for agent memory, tool orchestration, and operational automation.

Why transport becomes a database reliability boundary

Once Postgres is exposed through MCP as a tool service, transport directly influences database reliability, latency stability, and failure propagation. Transport failures surface upstream as latency spikes, retry storms, or connection floods against the database, even when Postgres itself is healthy:

• Poor streaming behavior can hold connections open and exhaust pools

• Misconfigured retries can amplify load and create cascading availability incidents

• Certificate or identity failures can block tool access while the database remains operational, creating partial outages that are difficult to diagnose

Because of this, transport selection is not an application detail. It is part of database reliability engineering, affecting SLOs, capacity planning, and operational recovery behavior across agent driven systems.

What MCP Transport Must Handle

Your agent does not just call a tool once. It calls tools in tight loops, streams partial results, retries, runs under load, ...it runs in places with different trust boundaries.

A transport layer must support:

• Low-latency request/response cycles for real-time interactivity.

• Streaming tokens or events for long-running processes.

• Backpressure controls so a fast sender cannot overwhelm a slow receiver, protecting system stability.

• Authentication and authorization to control access to tools.

• Observability, tracing, and correlation across calls to diagnose complex failures.

• Failure isolation so a problem in one tool cannot take down the entire agent.

If you select a transport that does not match your boundary, scaling model, or security model, you will need to rebuild it later.

Three MCP Transport Models

The models differ in where the server runs and how messages are routed. stdio runs as a child process, as messages flow through stdin and stdout pipes, delimited by newlines. HTTP with SSE runs as a network service inside a trusted network. HTTPS with SSE runs as a network service across a trust boundary; TLS is not optional there. Treat each boundary model as a tool; just choose the one that fits the edge you are crossing.

The stdio MCP

The stdio MCP runs over a process pipe. The agent launches the MCP server as a child process, writing JSON-RPC messages to the server's stdin, while the server writes responses to stdout. The OS handles buffering and scheduling.

• The agent starts the server binary as a subprocess.

• Agent sends MCP JSON-RPC frames over stdin.

• The server reads, runs the tool, and then writes a JSON-RPC response to stdout.

• The agent reads from stdout, matches the response to the request ID, and then continues.

Use stdio when the tool runs on the same host, and you want the lowest-overhead path.

It fits local tool execution for development, supporting database-sidecar tools that run alongside a local database. It fits GPU inference adapters on a workstation, with CLI automation that must run offline. It fits well into secure air-gapped environments.

Latency is the lowest achievable without shared memory, providing strong throughput for request response patterns. Overhead is minimal because there is no network stack. Security is OS process isolation plus any additional sandboxing you add.

Failure Model

When the tool process crashes, the pipe closes. The agent detects it and restarts the child process. Recovery can be fast, depending on the state; if the tool:

• stores its state in memory, it is lost on restart. 

• keeps state on disk, you can recover, but you must design for it. 

• has long-running work, you need a cancel path so restarts do not duplicate work.

Operational notes you should not skip

• You will need a watchdog for the child process, with per-call timeouts, even on a pipe. Make sure you provide a backpressure policy. 

• Limit concurrent tool calls to prevent resource exhaustion. Limit the max response size to avoid blocking the pipe and stream results when possible. 

• You also need log capture. In stdio, the spec reserves stderr for logs. Capture it and correlate it with request ids.

• MCP messages are strictly newline-delimited JSON-RPC. Ensure your parser handles partial reads and buffering correctly.

When stdio is the wrong choice

stdio starts to hurt when you want shared access, scaling, or remote control.  stdio doesn't support load balancing across hosts, so you cannot share a single tool server across many agents without extra plumbing. Monitoring stdio configurations from outside the host is also more difficult.

HTTP with SSE MCP

HTTP with SSE exposes MCP endpoints over TCP using Server-Sent Events. The agent connects to a service address, often via Kubernetes DNS. The agent uses two channels; the GET channel establishes a persistent connection for receiving messages via SSE, while the POST channel handles ephemeral client-to-server JSON-RPC messages.

The process is fairly simple: 

• An agent opens an HTTP GET connection to the SSE endpoint (e.g., /sse).

• The server accepts and keeps the connection open, sending an initial endpoint event containing the URI for the message POST endpoint.

• The agent sends HTTP POST requests with MCP JSON-RPC messages to the provided endpoint.

• The server processes the request and then pushes the JSON-RPC response over the open SSE channel.

• Messages are correlated via the JSON-RPC id field. The agent matches the id in the SSE event payload to the id of the POST request.

This dual-channel approach enables server-push notifications without the complexity of full WebSockets. HTTP keeps the network boundary inside a trusted zone. That zone can be a VPC, a cluster, or a mesh segment. It is still a network. You still need to plan for failure.

HTTP with SSE is suitable for Kubernetes internal services. It fits service mesh environments. It fits shared tool clusters. It fits horizontal scaling for heavy tools.

Performance Characteristics

For this transport model, latency is moderate due to network hop overhead, while throughput stays high when connections are pooled and reused. Overhead includes TCP transport, HTTP headers and request parsing. Security depends on both network policy and service authentication, often using tokens. Additionally, you must also validate the Origin header to prevent DNS rebinding attacks.

Configuring for Production

You should configure connection pooling to handle concurrency, and use Postgres parameters to streamline performance and functionality. A good starting configuration might set: 

• the maximum number of connections (max_connections) to roughly 10-15 per CPU core for optimal throughput.

• connection timeouts (connect_timeout) to around 600 seconds.

• idle timeouts (idle_session_timeout) to 300 seconds to clean up stale sessions. 

• hard request timeouts (transaction_timeout) to 30 seconds as a baseline. 

Use HTTP/2 or StreamableHTTP if available to multiplex requests and reduce connection overhead by up to 60%.

Failure Model 

HTTP provides you a mature ecosystem for retries, load balancing, and timeouts. It also gives you more ways to fail.

Common failure cases can result from a number of issues: 

• DNS issues, incorrect service names, and stale endpoints can prevent agents from reaching the intended service.

• Load balancer configuration may route traffic to unhealthy instances, causing intermittent failures.

• Slow or overloaded instances can lead to queue buildup and request timeouts.

• User retry storms can amplify load and make a bad situation worse. Deliberate retry logic is essential, but you should never retry blindly.  You can use bounded retries with jitter to avoid synchronized retry spikes.

• Retry only safe operations, or use idempotency keys to prevent duplicate effects.

• Implement circuit breakers so a failing tool does not consume all available agent time.

Connection pooling matters: If you don't reuse connections, you will pay extra latency per call. You also risk running out of ephemeral ports under load. Keep connections alive when you can and cap the pool size to avoid overloading the tool server.

HTTPS with SSE MCP

HTTPS with SSE MCP is HTTP over TLS; this basically means the Model Context Protocol is transported using standard, encrypted web infrastructure. This model is useful when the call crosses a trust boundary. That can be the public internet, a partner network, or a cross-organization boundary inside a large company.

TLS adds two things you need across boundaries:

• Encryption in transit

• Identity verification through certificates

When using this model:

• The agent performs a TLS handshake with the server.

• The  agent validates the server certificate chain and hostname.

• The agent sends HTTP requests over the encrypted channel.

• The server replies over the same channel.

• Optional mTLS also authenticates the client at the transport layer.

HTTPS with SSE is suitable for customer-facing tool endpoints, and fits well into multi-tenant SaaS agent infrastructure, zero-trust architectures, and compliance-regulated environments.

Latency is higher on new connections due to the TLS handshake, but throughput stays high with keep-alive and session resumption. The overhead for this model includes encryption, CPU costs and certificate validation. Be sure you're using strong transport security, with durable authentication that provides strong assurances that your users are really who they authenticate as.

Failure Model 

The hard failure case is certificate expiration; this can take you down fast. You will need to implement certificate expiration alerts, automate certificate rotation, use staging and canary rollouts for new certificates, and maintain clear runbooks for emergency rotation.

You also need to handle: 

• TLS version mismatch. 

• Bad cipher suite config. 

• Clock skew that breaks certificate validity checks. 

• Revocation and CA chain issues in some environments.

Choosing between stdio, HTTP, and HTTPS

Use this checklist to avoid most bad choices.

Use stdio: When the tool runs on the same host as the agent. You want fast iteration and low overhead, but you do not need shared access across many agents. You can accept process-level isolation as the main boundary.

Use HTTP with SSE: When the tool must serve many agents within a trusted network with a mesh or gateway that provides tracing and retries. You need load balancing and autoscaling, but can enforce service authentication with tokens and network policy.

Use HTTPS with SSE: When the call crosses a trust boundary. You handle customer or regulated data, exposing a tool endpoint to partners or clients. For HTTPS with SSE, you need transport-level identity and encryption.

One hard rule: If the network is not fully trusted, use HTTPS. If you are not sure, treat it as untrusted.

The pgEdge MCP Server

The pgEdge Postgres MCP server repo contains a real MCP tool server wired for both local and network execution; you can run the same database tool layer through stdio for subprocess speed or through HTTP and HTTPS endpoints for cluster and external access. You get a design suited for Postgres driven agent tools where SQL, extensions, or admin actions sit behind MCP, with token authentication for internal service traffic and TLS support for secure endpoints, which makes your Postgres layer act like a first-class tool service instead of a passive database.

Future direction

As you design your system, there are additional considerations we didn't mention, but that you should consider:

• WebSockets are not the primary focus of this blog, but they are a logical concern for bidirectional heavy lifting. 

• HTTP/3 and QUIC can cut latency for encrypted traffic in some paths. This can also change failure modes and what you can observe in the network. 

• Persistent streaming transports can cut per-call overhead for chatty tools. 

• Hardware TLS acceleration can reduce CPU cost for high-throughput TLS services. 

Be sure you choose your transport architecture by boundary. Bound retries. Bound concurrency. Observe everything.