Remote vs local (stdio) MCP servers: trust, auth and what to watch for

A local (stdio) MCP server runs as a subprocess on your own machine, under your own operating-system permissions, with no network involved. A remote MCP server runs on someone else's infrastructure and is reached over HTTP, which means it needs its own authentication story the way any hosted API does. Of the 320 servers Vouchity tracks, 279 run remotely and 41 run locally — remote outnumbers local by roughly 6.8:1 in the wild — and the two categories carry genuinely different risks, so the same trust checklist gets applied differently to each.

Local (stdio) servers: you trust the code, not the network

A stdio server is typically launched by your MCP host as a child process — an npx, uvx or plain binary invocation — and communicates over stdin and stdout: the server reads newline-delimited JSON-RPC messages from stdin and writes its responses to stdout, one message per line, with nothing else allowed on that channel. There is no listening port, no exposed endpoint, and no third party in the loop at runtime. If the process crashes, the client is expected to restart it and simply retry; there is no session to recover, because the whole exchange is stateless between requests. The entire threat model collapses into one question: do you trust the code you just downloaded? Supply-chain risk is the dominant concern — an unmaintained dependency, a compromised package version, or a tool that silently does more than its description says, all running with whatever permissions your user account already has.

For a local server, weight the transparency and maintenance signals most heavily: is the source public and readable, is there a license, has anyone touched it recently. A local server with a small, focused, well-documented tool surface from a maintained, licensed repo is about as safe as installing any small open-source CLI tool — which is to say, not risk-free, but a known and manageable category of risk. See how to vet an MCP server for the full five-point checklist this maps onto.

Remote servers: you're also trusting the network and the operator

A remote MCP server — over Streamable HTTP, or the older SSE transport — adds two things a stdio server doesn't have: a network boundary, and an operator who keeps running after you stop looking. The spec itself is explicit about the resulting obligations: it says servers should implement proper authentication for all connections, should validate the Origin header on every request to prevent DNS-rebinding attacks, and — if running locally for development — should bind only to localhost rather than every network interface. That guidance exists because, without it, the server is reachable by anything that can reach the network it sits on.

Right now, 114 of the 279 remote servers Vouchity tracks declare no authentication requirement at all — which means the tool is reachable by anyone who has, or guesses, the endpoint, not just by you. A remote server that doesrequire auth is making an explicit claim about who's allowed to call it, which is a meaningfully stronger security posture than an open endpoint, even before you get to what the tools themselves can do. Vouchity's security signal treats an unauthenticated remote server as a direct penalty for exactly this reason; see the full weighting in our methodology.

Transport also matters on its own. 277 of the servers we track support Streamable HTTP, which the MCP project introduced in March 2025 specifically to replace the earlier HTTP+SSE transport — that older transport has been formally deprecated since that revision and is now flagged for eventual removal from the spec. 9servers in the registry still declare the legacy SSE transport, which isn't automatically disqualifying, but it's worth checking whether a server you're relying on has migrated, since an unmaintained SSE-only integration is a mild maintenance signal in its own right. See MCP security fundamentals and the sourced picture across the whole registry in MCP server security in 2026.

MCP vs a plain API: why not just call the REST API directly?

A remote MCP server is very often, underneath, a thin layer in front of an ordinary REST API — so it is fair to ask why that layer exists at all, instead of just calling the API. The answer isn't a transport trick; it's standardized discovery and delegation. With a plain API, a developer reads the documentation once, picks the endpoints the app needs, maps the parameters, and hardcodes that call into the codebase. The integration work happens at build time, by a human, and it happens again for every new API the app wants to use.

MCP inverts who does that mapping and when. Every compliant server exposes a tools/list method (and, where relevant, resources and prompts) that any MCP client can query at connection time — no bespoke glue code per server. The model itself then reads each tool's name, description and input schema and decides at runtimewhich one to call and with what arguments, based on what the user actually asked for. Vouchity's own explainer on what MCP iscovers this "USB-C for AI applications" framing in more depth: one connector shape, many devices on either end, instead of a bespoke cable for every pairing. That's the actual value proposition — one client integration (Claude Desktop, Claude Code, Cursor, or any other MCP host) works against any MCP server without per-server code, and the same server works unmodified across every one of those clients.

Tools aren't the whole story either: MCP also standardizes resources (read-only data the model can pull into context, the rough equivalent of a GET endpoint with a stable URI) and prompts(reusable, parameterized templates the server author ships alongside the tools). A plain REST API has none of that metadata in a form a model — or a generic client — can introspect; it has whatever the developer's documentation happens to say, in whatever format that happens to be. The tradeoff is that this convenience only shifts the trust question, it doesn't remove it: instead of trusting your own hardcoded call, you're trusting the server's description of the tool to be accurate, and trusting the model to interpret it correctly — which is exactly the mechanism a prompt-injection attack tries to abuse.

What to check for each

• Local: public source, a real license, recent commits, a tool surface that matches the description, and — if it needs credentials — that it reads them from your own secret store rather than hardcoding or logging them.
• Remote:everything above, plus a declared auth mechanism, a clear statement of what data the operator retains, which transport it speaks (Streamable HTTP over a lingering SSE-only integration is the better sign), and — if it's free and open — some sense of who is actually running the infrastructure and why.

Choosing between them for the same job

When a tool is offered both ways — say, a search or database integration with both an npx local package and a hosted remote endpoint — the decision usually comes down to who else needs access and how much you trust the operator versus your own machine. A single developer wiring an agent into their own laptop has little reason to add a remote hop and an operator's trust story when the local package does the same job with a smaller blast radius. A team sharing one integration across many users, or an agent running somewhere with no filesystem of its own, has the opposite calculus — the remote server's auth and hosting become the whole point. Our guide to using MCP servers in Claude and Cursor walks through both connection styles in practice.

Vouchity tracks the transport for you

Every server on the registrylists its supported transports and, for remote servers, whether authentication is required — both feed directly into its Trust Score. If you're deciding between a local and a remote option for the same job, check both scores side by side on the trust leaderboardbefore you decide which trust model you'd rather take on.