Local vs remote MCP servers
A local MCP server runs on your own machine as a child process the host launches and talks to over stdio (stdin/stdout); a remote MCP server runs somewhere else and is reached over the network using the Streamable HTTP transport (or the older HTTP+SSE pairing), usually behind OAuth 2.1. The protocol — JSON-RPC 2.0, the same capability handshake, the same tools/resources/prompts — is identical either way; only the transport, the deployment, and the trust boundary differ. Local servers expose your filesystem and credentials to whatever code you ran; remote servers move the code off your machine but hand your data to a third party over the wire.
Transport is the real difference (stdio vs Streamable HTTP)
MCP is an open JSON-RPC 2.0 protocol introduced by Anthropic: a host runs one MCP client per server, performs a capability handshake, then discovers and calls that server's tools, resources and prompts. What changes between local and remote is the transport — the channel those JSON-RPC messages travel over — not the message format or the primitives.
Local servers use the stdio transport. The host spawns the server as a subprocess and exchanges JSON-RPC messages over the process's stdin and stdout. There is no port, no URL, and no network hop; the server lives and dies with the host that launched it. This is the default for desktop integrations (for example a server configured in Claude Desktop's config that runs via npx or uvx).
Remote servers use an HTTP-based transport. The current standard is Streamable HTTP: a single HTTP endpoint the client POSTs JSON-RPC requests to, with the server able to stream responses and server-initiated messages back (using Server-Sent Events as the streaming mechanism when needed). The older two-endpoint HTTP+SSE transport — a separate SSE channel for server→client messages plus a POST endpoint for client→server — is now legacy but still seen in the wild. A remote server is addressed by URL and is typically protected by OAuth 2.1 or a bearer token.
Local MCP servers: how they run and what they expose
A local server is just a program on your machine that speaks MCP over stdio. The host passes it a command and arguments (and often environment variables holding API keys), launches it, and pipes JSON-RPC through it. Because it executes with your user's privileges, it can read your files, reach localhost services, and use any credential you handed it — which is exactly the appeal (filesystem access, local databases, dev tooling) and exactly the risk.
The trust boundary for a local server is your own machine. Latency is negligible and your data never leaves the device, but you are running third-party code locally: a poisoned npm/PyPI package, a tool description carrying hidden instructions, or a server that quietly exfiltrates over an outbound call is operating with full local context. "Local" means private transport, not safe code.
Local servers are also harder to audit at scale precisely because they aren't network-reachable — there is no URL to point a scanner at. They are evaluated as a repository or package (source, maintenance, license, adoption, documentation) rather than by probing a live endpoint.
Remote MCP servers: how they run and what they expose
A remote server runs on infrastructure you don't control and is reached over HTTPS at a URL. The host's MCP client opens the Streamable HTTP (or legacy HTTP+SSE) transport, authenticates — commonly via OAuth 2.1, sometimes a static bearer token — and then runs the identical capability handshake and tool/resource/prompt discovery. Updates ship server-side, so you don't install or update anything locally.
The trade-off inverts the local one. Your machine's filesystem and local secrets stay out of reach, but every request and every piece of data you pass to a tool crosses the network to a third party, and the operator can change the server's behavior at any time. Because the client re-fetches tool definitions per session rather than pinning a reviewed copy, a remote server can silently alter its tools after you approved it — the rug-pull problem.
Remote is the model for hosted, multi-tenant MCP services and for sharing one server across a team. It also makes auditing tractable: a live URL can be probed directly, its handshake validated, its real tools, resources and prompts inspected, and its responses exercised — which is why live-endpoint scoring assumes a remote (HTTP) transport.
Which to choose, and the security implications of each
Pick local (stdio) when the server needs your filesystem, a local database, or developer tooling, when latency must be near-zero, and when you want your data to stay on the device. Pick remote (Streamable HTTP) when a server should be centrally hosted and updated, shared across a team or product, or kept off end-user machines — accepting that data now transits to a third party and that authentication and transport security matter.
The security questions differ by transport but the core risks do not. Both can carry tool poisoning (hidden instructions in tool metadata or outputs), both can leak hardcoded secrets, both can assemble the lethal trifecta (untrusted-content ingestion + sensitive-data access + an exfiltration or destruction path). Local adds the risk of arbitrary code running with your privileges; remote adds network exposure, an authentication surface (OAuth/token handling), and behavior you can't see source for and that can change underneath you.
A practical rule: treat every MCP server — local or remote, first- or third-party — as untrusted until audited, and re-check it over time. The transport tells you where the boundary is; it does not tell you whether the server is safe.
How CheckMCP handles it
CheckMCP computes a vendor-neutral MCP Score (0-100, grade A-F) and matches the method to how each server is reachable. For a remote server it probes the live endpoint directly — Streamable HTTP or legacy HTTP+SSE, optionally behind Bearer/OAuth — validates the JSON-RPC capability handshake, inspects the real tools, resources and prompts, and scores seven weighted pillars: security (20), tool design (18), schemas/descriptions (16), reliability (14), context-cost/token (12), compliance (12), and coverage/use-case (8). The security pillar runs an OWASP MCP Top 10 pass (tool poisoning, hardcoded secrets, command injection, the lethal trifecta, and more), with hard caps that floor the grade at D if a secret is found in a tool schema and at F if the handshake fails. Opt-in behavioral evals exercise read-only tools with canary inputs to catch prompt-injection and data-exfiltration in tool responses. A local (stdio) server usually has no URL to probe, so CheckMCP scores it as a repository/package across four pillars: maintenance (40), license (25), adoption (20), documentation (15). You run it with uvx checkmcp <url> (open-source, MIT, stdlib-only), use the web app at checkmcp.dev, or wire the GitHub Action (uses: H129hj/checkmcp@v1) into CI to fail a build on a score regression or rug-pull. For remote servers, an in-band Gateway sits in front and blocks tool-poisoning and drift before they reach your agent (passive and active modes), with drift monitoring over time.