MCP Local stdio vs Remote HTTP: Which Transport to Use at Work

MCP Local stdio vs Remote HTTP: Which Transport to Use at Work

Use stdio when the MCP server serves one person, runs on that person's machine and only reaches local resources. Use remote HTTP when several users or agents need the same server, when it touches company systems, and when you need per-user authentication, centralized logs and a single place to update. The choice is not about which transport is newer. It is about where the server runs, who is accountable for it, and what you can see when something goes wrong.

Key takeaways

• With stdio, the client launches the server as a local process and talks to it over standard input and output. No network is involved, but there is no central control either.
• With remote HTTP, the server is an independent service with its own address, authentication and lifecycle. You can govern it, but you now operate a service.
• Security, maintenance and observability weigh differently in each mode. Stdio spreads risk across many machines. HTTP concentrates risk in one place that must be well protected.
• Servers that reach customer data, ERP, CRM or any sensitive system tend to work better as remote servers with per-user permissions. Personal and developer tools tend to stay local.
• Start with one server, one read-only action, logs and an agreed success criterion. Then decide whether to expand, adjust or stop.

What changes between stdio and remote HTTP?

The Model Context Protocol defines how an AI application (the client) connects to tools and data sources (the servers). The transport is the layer that carries messages between the two sides, and the protocol specification describes two standard modes: stdio and HTTP (called Streamable HTTP in the current specification). Check the current text of the specification before you finalize an architecture decision, because this part of the protocol evolves.

With stdio, the client runs the server as a subprocess on the same machine. Messages travel through the process's standard input and output. When the client closes, the server ends with it. The server inherits the user's environment: variables, files, credentials and the operating system permissions of that person.

With remote HTTP, the server is a service that stays running somewhere (a company server, a cloud, a container) and answers requests from many clients. It has a URL, needs authentication, sits behind a load balancer or proxy, can have a single version, and is monitored like any other service.

This difference looks technical, but it decides three business questions: who can use the tool, who maintains it, and who can prove what it did.

Security: who has access to what

With stdio, the server runs with the permissions of whoever started it. That is simple and, for personal use, often enough. The problem appears at scale. If twenty people install the same server, there are twenty copies, possibly in different versions, each with credentials stored in configuration files or environment variables on a laptop. An API token pasted into a local file is a leak risk the company cannot see. If the key is shared by everyone, you also lose track of who did what. Storing and rotating secrets is covered separately in managing API keys and secrets for AI agents.

Stdio also carries a classic risk: installing a server means running third-party code on the user's machine, with that user's access. A malicious or compromised package can read files, variables and the local network. That is why auditing before installing is mandatory, as we describe in how to audit an MCP server before installing it at your company.

With remote HTTP, the code does not run on the user's machine, which reduces the exposure on the laptop. In exchange, you expose an endpoint. The protocol specification covers authorization for the HTTP mode based on OAuth, and it recommends precautions such as validating the origin of requests when a server runs locally. In practice, that means:

• authenticate each user or each agent instead of using one shared key;
• apply authorization per tool and per resource, following established principles such as the OWASP authorization guidance;
• keep the secrets for the connected system on the server, not on each person's device;
• expose the service only to the network or VPN that needs it, whenever possible.

There is also a risk that applies to both modes: prompt injection. If a tool returns text that comes from emails, web pages or customer messages, that text may contain malicious instructions. The transport does not solve this. What reduces the damage is limiting what the tool can do, requiring human approval for sensitive actions, and separating reading from writing. The OWASP list of top vulnerabilities in LLM applications is a good review checklist.

On data protection (LGPD): when the server accesses personal data, you need to know where that data travels and where it gets recorded. On a central remote server, it is easier to define purpose, retention and access. Across dozens of machines, local logs and caches can hold personal data that nobody has mapped.

Maintenance: who updates it and who answers when it breaks

Stdio is cheap to start. There is no server to provision, no domain, certificate or load balancer. The cost comes later: manual updates, diverging dependencies (runtime, Node or Python version), case-by-case support and the classic "it works on my machine". When the server's vendor fixes a security flaw, someone has to make sure every copy was updated.

Remote HTTP reverses this. There is an upfront operating cost: hosting, deployment, monitoring, secret rotation, a plan for downtime. In return, a fix becomes a single release. You control the version, you can roll back, you test before releasing, and you can cut off one person's access without touching their computer. If the tool depends on an LLM provider or an external API, it is also easier to handle limits and outages in one central place, a topic covered in handling LLM API rate limits and outages.

There is a third consideration: who will operate it. A remote service with no owner becomes debt. Before choosing HTTP, define who receives the alert, who approves changes and who shuts the server down during an incident. If the company has no such person or partner, it is better to admit the server is not ready to be remote yet. For hosting choices, where to host an AI agent: VPS, cloud or on-premise server helps compare the options.

Observability: what you can see

Observability, as the OpenTelemetry primer summarizes it, is the ability to understand the internal state of a system from the signals it emits: logs, metrics and traces. For MCP, the practical questions are: which tool was called, by whom, with which parameters, what was the result, how long it took and whether there was an error.

With stdio, those signals are produced on the user's machine. One important technical detail: because standard output carries the protocol messages, the server's logs must go to another channel (usually standard error or a file), otherwise they corrupt the communication. For the company, the result is that logs end up scattered. Reconstructing what happened in a conversation means asking each person for files, and that rarely works after an incident.

With remote HTTP, the server is the natural collection point. You record every call with the user identifier, tool, relevant parameters (masking personal data), result and latency, and send everything to the monitoring tool the company already uses. That enables alerts, audits and periodic review. If you need to standardize tracing of model calls, the OpenTelemetry semantic conventions for generative AI are a useful reference.

What should be in the log of a call, in any transport:

• who asked (user or agent) and in what context;
• which tool was called and whether it was a read or a write;
• parameters, with personal data masked;
• a summarized result or error code;
• whether there was human approval and from whom.

How to decide: a guide by type of server

Use the list below as a starting point. Each item describes a situation and the transport that usually makes the most sense.

• Personal productivity tool that reads the user's own folders: stdio, with an audited server and a pinned version.
• Development tool that acts on the local repository, used by one person at a time: stdio, with permissions and isolation from the development environment. See Claude Code security: permissions, sandbox and secrets for teams.
• Server that reaches ERP, CRM, customer database or finance: remote HTTP, with per-user authentication, per-tool permissions and central logs.
• Server shared by several agents (for example, WhatsApp support and an internal routine): remote HTTP, so rules and limits live in one place.
• Server that performs actions with external effect (sending a message, changing an order, issuing something): remote HTTP, with human approval and a record of the decision.
• Third-party server you have not audited yet: neither one until you audit it. If you must test, use an isolated environment and fictional data.
• One-week proof of concept: stdio is usually enough, as long as there is a recorded decision to migrate or discard.

One simple rule sums up the list: the more people, the more sensitive data and the more actions with real effect, the more the server belongs in remote. The more personal, disposable and confined to one machine, the more stdio is justified.

Illustrative scenario: from local to remote

Imagine, as an illustrative scenario, a services company that starts with an MCP server for CRM lookups running over stdio on one analyst's laptop. As a test, it works well: she asks the assistant about a contact's history and gets the answer.

When other people in sales ask for the same access, the problems appear. Each would need a CRM token on their own computer. Nobody knows which version of the server is installed on each machine. If someone leaves the company, the token stays valid until somebody remembers to revoke it. And there is no single place to see which queries were made.

The reasonable decision at that point is to move the server to remote HTTP, with per-user login, read-only permission and central logs. The server now holds the CRM credential, and people no longer have direct access to the token. To decide between MCP, direct API or webhooks for this integration, the article on how to integrate AI with your CRM covers the paths.

How this criterion fits our method

When we work with companies, we treat the transport choice as part of four steps. Map: which systems the server touches, who will use it and what data passes through it. Limit: start with read-only access, restrict tools and define where secrets live. Pilot: run one real workflow with logs and an agreed success metric. Transfer: hand over operations with documentation, a defined owner and an explicit decision to expand, adjust or stop. If the server is built for an internal system, start with how to build an MCP server for internal systems, read-only first. And for anyone configuring the client side, configure MCP in Claude Code explains the local, project and user scopes.

Frequently asked questions

Is stdio unsafe for company use? Not necessarily. It suits individual use with an audited server, a pinned version and low-privilege credentials. The risk grows when many machines hold their own credentials or when the server reaches sensitive systems without central logging.

Can I start with stdio and migrate to HTTP later? Yes, and it is a common path. To make it easier, keep the tool logic separate from the transport, avoid depending on local files, and document which permissions the server actually needs. That way the migration changes how the server is connected without rewriting the tools.

Does remote HTTP solve prompt injection? No. The transport protects communication and allows authentication and logging, but content returned by a tool can still contain malicious instructions. The defense comes from limiting actions, separating reads from writes, validating outputs and requiring human approval when the effect matters.

Who should own a remote MCP server? A person or team with clear responsibility for updates, alerts, access and shutdown during an incident. It can be the company's technology team or a partner with contracted operations. Without a defined owner, the server should stay in pilot and not move to broad use.

Sources

• Model Context Protocol: introdução
• OWASP: guia de autorização
• OpenTelemetry: conceitos de observabilidade
• OWASP Top 10 para aplicações com LLM