Remote vs local MCP servers: which one to run

The short answer: stdio for personal tools, HTTP for shared services

Choose the transport from the operating model, not from taste. stdio is a local child process. Streamable HTTP is a service endpoint. The protocol messages can be the same, but the risks move to different places.

The MCP transport documentation says a transport is a binding for framing, delivery, request metadata, cancellation, and termination. It does not change MCP message semantics. That sentence matters because teams often ask whether HTTP MCP is more capable than stdio MCP. It is not more capable by definition. It is more operable as shared infrastructure, and more exposed as infrastructure.

The first cut is simple. If the server reads a local repository, calls a local build tool, shells out to a local CLI, or uses credentials that live in one user’s environment, start with stdio. The MCP client launches the server as a subprocess. JSON-RPC messages pass over stdin and stdout. The machine boundary is obvious, even if it is not a complete security boundary.

If the server is a company service, use Streamable HTTP. One endpoint can serve many users and many MCP hosts. You can put authentication in front of it, capture logs in one place, rate-limit abusive clients, rotate credentials centrally, and roll back one deployment instead of cleaning up a dozen laptops.

The tradeoff is not local versus secure. Local code can be malicious or over-permissioned. Remote code can be well-governed or dangerously exposed. The real decision is where you want to pay: host installation, version drift, and per-machine secrets, or web operations, auth design, and incident response.

The real problem is ownership, not transport

The symptom is familiar. You have an MCP server that works on one machine. It reads a few files, calls an API, and returns useful context to Claude, Cursor, or another host. Then a second person wants it. Then a third person wants a different host. Then someone asks where the logs are. That is the moment when “just run the server” turns into an architecture decision.

A local stdio server hides most web operations. There is no public route. There is no TLS certificate. There is no OAuth metadata endpoint. There is no load balancer. The MCP host starts a child process and talks to it through standard input and standard output. For one user, this is boring in the best way.

The same model becomes awkward when a team needs shared behavior. Every user has to install the server. Every host config has to be updated. Every machine has its own logs, if logs exist at all. Every environment may have a different package version, shell profile, node runtime, Python path, or credential helper. When a bug ships, the fix has to reach every machine that runs it.

A remote HTTP server flips the problem. Installation becomes a URL and an auth flow. Updates happen once. Logs collect in one place. The service can enforce policy before it calls a downstream API. That is attractive, but it is not free. You now operate an HTTP service that handles model-driven requests. You need origin checks, authentication, authorization, session strategy, rate limits, and a plan for bad tool calls.

The question to ask is not “remote or local MCP server?” Ask who owns the server at 2 a.m. If the answer is the user, stdio can be right. If the answer is an engineering or platform team, remote HTTP can be right. If nobody owns it, do not put it on the network.

How local stdio MCP servers actually work

The 2025-11-25 MCP transport specification defines the stdio transport as communication over standard input and standard output. The client launches the MCP server as a subprocess. The server reads JSON-RPC messages from stdin and writes JSON-RPC messages to stdout. Messages are newline-delimited. The server can write logs to stderr, but stdout must contain only valid MCP messages.

That last rule is not cosmetic. If a server prints a startup banner to stdout, the host may try to parse it as JSON-RPC. If a library writes a warning to stdout, the protocol stream can break. For stdio servers, stdout is the wire. stderr is where diagnostic output belongs.

A minimal host-side config often looks like this in shape, even though each host has its own exact file name and schema:

{ "mcpServers": { "content-local": { "command": "node", "args": ["/Users/alex/tools/content-mcp/server.js"], "env": { "CMS_API_TOKEN": "from-keychain-or-managed-env", "BRAND_GUIDE_PATH": "/Users/alex/work/brand/guide.md" } } } }

That config tells you most of the security story. The server runs as the user who launched the host. It can usually read files that user can read. It can call programs that user can call. It can see environment variables that the host passes into the process. If the server shells out to git, npm, gh, psql, or a CMS CLI, those programs run with the local user’s permissions.

The upside is direct local access. A repository-aware server can inspect files without uploading them to a remote service. A developer tool can use an existing local toolchain. A data analyst can point the server at a local directory. There is no network endpoint for an attacker to scan.

The downside is package and host trust. You are installing executable code on a user’s machine. If the server package is compromised, the impact is local but real. If the config passes a broad API token, the server can misuse it. If every teammate installs the server by hand, you will see version drift.

How remote Streamable HTTP MCP servers actually work

Streamable HTTP is the network transport for MCP. The 2025-11-25 MCP transport specification describes an independent server process that exposes a single MCP endpoint. Clients send JSON-RPC messages as HTTP POST requests. The server can return JSON directly or use request-scoped server-sent events for streaming. The server may also support HTTP GET for server-to-client streaming.

The same specification describes session behavior. During initialization, the server may assign an MCP-Session-Id. If it does, the client must include that session ID in later requests. That small header changes operations. If the server is stateful, your load balancer, workers, and session store have to agree on where session state lives.

The MCP C# SDK transport documentation makes this operational split plain. It distinguishes stateless Streamable HTTP from stateful Streamable HTTP and notes that stateful mode requires session affinity. Stateless mode has fewer scaling constraints because any instance can handle a request without prior session memory.

A remote endpoint shape might look like this:

https://mcp.example.com/mcp

The client no longer starts a subprocess. It calls a service. That service has a deployment pipeline, network policy, TLS termination, request logs, health checks, abuse controls, and rollback. It may sit behind a gateway. It may use OAuth. It may call downstream APIs with service credentials or per-user credentials.

This model fits shared tools. A marketing team can connect several MCP hosts to one content workflow. A platform team can expose an internal database assistant with central auditing. A SaaS product can publish one MCP endpoint instead of asking users to install a binary.

The cost is that the MCP server is now web infrastructure. The transport specification says Streamable HTTP implementations must validate Origin headers to prevent DNS rebinding attacks, should bind only to localhost when running locally, and should implement authentication. Those are not optional chores once the server is reachable beyond one machine.

The security tradeoff: endpoint exposure versus local execution

Security gets easier in one column and harder in another. stdio removes the exposed HTTP endpoint. That is a real benefit. There is no route to scan, no CORS policy to get wrong, no bearer token on an inbound web request, and no public session cookie to defend. The server is reachable through the local host app that launched it.

But stdio does not sandbox the tool. It is local execution. The server inherits the risk of the package, the runtime, the user account, the filesystem, and the environment. The MCP authorization specification says HTTP-based transports should conform to the MCP authorization specification where supported. It also says stdio implementations should not follow that HTTP authorization spec and should retrieve credentials from the environment.

That means a stdio deployment needs plain old endpoint controls. Use a trusted install channel. Pin versions where you can. Keep secrets out of casual dotfiles. Prefer keychains, managed environment injection, or short-lived credentials over tokens pasted into host configs. Keep the server’s filesystem scope narrow. If the server only needs a project directory, do not point it at the user’s home directory.

Remote HTTP gives you central controls. You can enforce authentication before a request reaches tools. You can make authorization decisions per user and per action. You can log every tool call in one place. You can reject requests from unknown origins. You can rotate downstream credentials once. You can disable one user without touching their laptop.

Remote HTTP also creates web-specific failure modes. The MCP transport specification calls out Origin validation to prevent DNS rebinding. The MCP security best practices call out confused-deputy risks for MCP proxy servers that connect to third-party APIs. They also warn against token passthrough, where an MCP server accepts client-supplied tokens and forwards them downstream without validating that the tokens were issued for the MCP server.

Token passthrough is tempting because it feels simple. It pushes identity work to someone else. It also weakens auditability and can let a token minted for one audience reach another service. Treat the MCP server as a resource server with its own audience and policy, not as a blind pipe.

The ops tradeoff: distribution versus service ownership

Operations are where remote MCP often wins. One deployment is easier to reason about than twenty local installs. You can see error rates, latency, auth failures, and tool-call volume in one place. You can roll out a fix and know which version is live. You can put the service behind the same incident process as the rest of your company systems.

That benefit only appears if you operate it like a service. A remote MCP server needs health checks that exercise more than the root route. It needs structured logs that separate user identity, client identity, tool name, downstream request ID, and decision outcome. It needs a rate limit that protects the server and the downstream APIs it calls. It needs a rollback path that does not depend on editing every user’s host config.

State also matters. If the server uses MCP sessions and stores session data in process memory, horizontal scaling needs sticky routing or a shared session store. Sticky routing can be fine for an internal tool. It becomes a harder choice when you need rapid failover or many regions. Stateless Streamable HTTP avoids that class of problem, but it pushes you to store all durable context outside the worker or require each request to carry enough context to run independently.

Local stdio has a different ops tax. The tax is distribution. How do users install the server? How do they update it? How do you revoke a bad version? How do you know which machines still run it? How do you collect enough logs to debug a failure without asking a user to paste terminal output into chat?

For developer teams, device management can make stdio viable at scale. If you already manage laptops, package versions, environment injection, and logs, the local model is not chaotic. If your users are outside your company or spread across unmanaged machines, remote HTTP is usually easier to support.

The cost of remote HTTP is central blast radius. A bad deploy can affect every client at once. A bad auth rule can expose shared data. A downstream API outage can break every connected host. Centralization helps you fix incidents faster, but it also gives incidents a bigger target.

A practical decision table for MCP transport choice

Use this checklist before you decide. It is written for the person who has to own the server after the demo works. Each row names the cost, the boundary, and the result you should expect if the choice is correct.

Do not treat the table as a scoring system. A single hard requirement can decide the transport. If the server must read a local repository that cannot leave a laptop, stdio may win even if central logging would be nice. If the server must serve five host apps for a whole department with audited approvals, remote HTTP may win even if a local prototype was faster.

Hypothetical example: a marketing content MCP server

Consider a hypothetical 12-person marketing team. They want an MCP-accessible content workflow. It should remember brand rules, draft content, and require a human approval step before publishing. There are two plausible designs.

Option A is a local stdio server named content-mcp. Each marketer installs it in their MCP host. The server reads a local brand guide, stores drafts in a local workspace, and calls a publishing CLI when the user approves. This is a good fit if each marketer works independently and the company already manages endpoint secrets well. It is a poor fit if the team needs one shared memory, one approval log, or one place to disable publishing access.

The main local risk is credential sprawl. If the publishing token sits in an environment variable on each laptop, revocation and rotation become operational tasks. If one user runs an old server version, that user may bypass a policy added later. A project folder helps organize drafts. It does not prove isolation unless the design also uses OS permissions, containers, separate credentials, or separate storage rules.

Option B is a remote Streamable HTTP server at a single MCP endpoint, such as https://example.com/mcp. The server authenticates users, stores shared brand memory centrally, records approval decisions, and calls the publishing API from a controlled backend. This is a good fit if the team needs shared memory, central policy, and auditability.

The main remote risk is service exposure. The endpoint needs auth. It needs Origin validation. It needs a rule against token passthrough. It needs per-user authorization before publish. If the MCP server proxies to a third-party CMS, it needs to avoid confused-deputy flows by making consent and client identity clear.

Neither option is pure. The local version can still call remote APIs. The remote version can still receive sensitive prompts and files. The difference is where you put the boundary that your operators can see and enforce.

Failure modes to name in the runbook

The failures are different enough that your runbook should name them. A stdio server fails like a local process. A remote Streamable HTTP server fails like a web service. Both can fail like an agent tool, which means the model may call the wrong tool, pass the wrong argument, or ask for an action the user did not mean to approve.

For stdio, the first class of failures is stream pollution. Anything written to stdout that is not an MCP message can break the protocol stream. Keep logs on stderr. Turn off noisy startup banners. Be careful with libraries that print warnings.

The second stdio failure is environment confusion. The host may launch the server with a different PATH than your terminal. A command that works in a shell may fail inside the MCP host because node, python, git, or a credential helper is not found. Write configs with absolute paths when the host requires it. Pass only the environment variables the server needs.

For remote HTTP, the first class of failures is auth ambiguity. A client is authenticated, but the server does not know which downstream actions that user can take. Fix that with explicit per-tool authorization checks. Do not assume login means publish, delete, export, or invite.

The second remote failure is session routing. If the server issues MCP session IDs and stores state in memory, a later request may land on a different worker. The result can look like random initialization loss. Use sticky routing, shared session state, or a stateless design.

The third remote failure is proxy confusion. The MCP security best practices discuss confused-deputy risks when an MCP proxy connects to third-party APIs. If the server cannot explain which client requested access, which user consented, and which downstream audience receives the token, the design is not ready for production.

What the transport does not solve

Transport is not policy. The 2026 MCP transport documentation is clear that transport does not change message semantics. A dangerous tool remains dangerous over stdio. A safe tool does not become safe just because it is behind HTTPS. You still have to design permissions, approval gates, input validation, output handling, and downstream scopes.

Transport is not a sandbox. A local server can read what its process can read. A remote server can access what its service credentials can access. A workspace, project, client folder, or memory namespace may be useful product organization. It is not a security boundary unless there is an enforced mechanism behind it, such as separate credentials, process isolation, storage isolation, or policy checks.

Transport is not consent. A human approval step can block a publish action, a payment, a destructive database change, or a message send. That approval has to be bound to the actual action. “Approve this draft” is not the same as “approve publishing this draft to this site with this account now.”

Transport is not observability. Remote HTTP makes central observability easier, but only if you log the right fields. stdio makes local debugging simple, but only if the host preserves stderr and the server emits useful errors. Neither transport gives you an audit trail by default.

Transport is not data governance. If prompts include personal data, confidential source code, unreleased financial numbers, or regulated content, the transport choice is only one control. You still need data retention rules, access rules, deletion behavior, and a record of which systems receive the data.

Do not use remote HTTP just because it looks more professional. Do not use stdio just because it avoids web security. Use the model whose failure you are prepared to own.

Remote MCP production checklist

A remote MCP server needs a short preflight before it goes beyond localhost. The MCP transport specification says Streamable HTTP implementations must validate Origin headers to prevent DNS rebinding, should bind only to localhost when running locally, and should implement authentication. Start there.

Then define identity. Who is the user? Who is the MCP client? Which host is making the request? Which downstream account will be used? These questions matter most when the MCP server calls another API. The MCP security best practices warn against token passthrough and confused-deputy patterns. If the MCP server accepts a token, it should validate that the token was issued for the MCP server as the intended audience. If it proxies to another system, it should keep consent clear.

Define session strategy before scale. If you issue MCP-Session-Id and keep state in memory, write down the routing rule. If any worker can handle any request, write down where the state lives. If you choose stateless Streamable HTTP, write down what each request must include and where durable context is stored.

Define logs before the first incident. For each tool call, capture the authenticated user, client identity where available, tool name, decision result, downstream request ID if one exists, and approval ID if a human gate was involved. Do not log secrets or full sensitive payloads by default. Redaction is part of the design, not a clean-up task.

Define deployment behavior. How do you roll back? How do you drain sessions? What happens to in-flight streaming responses? What error does a user see when auth fails? A good MCP tool can still feel broken if the host receives an opaque HTTP 500 for every policy denial.

This checklist sounds like normal web service work because that is what remote MCP is. The MCP part defines how clients and servers exchange tool messages. The remote part makes you an operator.

Local stdio production checklist

A local stdio server needs a different preflight. First, decide how the binary or package gets installed. If users copy a command from a README, expect drift. If you can ship through device management, a package registry with pinned versions, or a signed binary, you will have fewer unknowns.

Second, decide how credentials enter the process. The MCP authorization specification says stdio implementations should retrieve credentials from the environment rather than following the HTTP authorization spec. That does not mean every token belongs in a plain host config. Prefer managed environment injection, a keychain, a credential helper, or short-lived local auth where the host supports it.

Third, define filesystem scope. If the server needs one repository, configure one repository. If it needs a brand guide, pass that path. Avoid defaults that scan the entire home directory. The model may ask for broad context, but the server does not have to provide it.

Fourth, keep stdout clean. JSON-RPC messages go to stdout. Logs go to stderr. If the runtime or framework prints to stdout by default, change it before users install the server. This is one of the easiest local failures to prevent and one of the most confusing to debug after the fact.

Fifth, make version visible. Add a tool or resource that reports the server version and config source without exposing secrets. When a user says “it works for Sam but not for me,” you need to know whether they are running the same server.

Sixth, write the uninstall path. Local tools linger. Host config entries remain after a package is removed. Tokens remain after a project ends. A local MCP server is still software on an endpoint, and endpoint hygiene applies.

Where Agentik fits in this decision

Agentik’s public corpus describes Agentik OS as an AI operating system installed into existing MCP hosts such as Claude, Claude Code, Cursor, ChatGPT, Codex, and Hermes. It documents MCP calls staying on https://mcp.agentik-os.com/api/mcp. That supports describing Agentik as a remote MCP-connected operating layer, not as a local stdio server.

The same public corpus describes shared memory, skills, objects, specialized agents, and a human approval gate. Those are workflow controls. They matter for teams that need coordinated work across agents and hosts. They do not, by themselves, prove sandboxing, air-gapping, tenant isolation, or a legal compliance posture. If a deployment needs those properties, ask for the specific mechanism and the current documentation.

This distinction is the point of the article. Remote MCP can be the right fit for a shared operating layer because it centralizes state, access, and approvals. Local stdio can be the right fit for a personal tool because it stays near the user’s files and processes. The transport does not make the product safe. The controls around the transport do.

If you connect Agentik or any other remote MCP service to your host, review it like infrastructure. Identify the endpoint, the auth model, the approval model, the data that flows through it, and the logs you can inspect. If you run your own local server beside it, review that local server like endpoint software. Identify the package source, the secrets it receives, and the files it can read.

The decision rule you can put in a design doc

Use local stdio when the server is personal, close to the filesystem, and cheap to reinstall if it breaks. Use remote Streamable HTTP when the server is shared, policy-heavy, and worth operating as a service.

The hard cases are mixed. A developer tool may need local repository access and central policy. A publishing tool may need shared approvals and local drafts. In those cases, split the system. Keep the local reader local. Put the shared approval and publishing service behind remote HTTP. MCP does not require one server to do every job.

Write down the boundary before writing more code. For stdio, the boundary is the local process and the user account. For remote HTTP, the boundary is the authenticated service endpoint and its downstream permissions. Once that sentence is clear, the transport choice usually follows.

• Pick stdio if install control, local file access, and per-user credentials are acceptable costs.
• Pick Streamable HTTP if central auth, central logs, central upgrades, and multi-host access are required.
• Do not treat either transport as a sandbox, consent system, or audit log by itself.
• For sensitive tools, decide only after listing credentials, authorization, logs, approval gates, data separation, origin checks, token handling, session strategy, and downstream scopes.