Guides · Infrastructure
MCP Servers Explained: What They Are and How They're Hosted
Updated 2026-07-27 · ~10 min read
What is an MCP server?
An MCP server is a program that exposes tools, data and prompts to an AI assistant through the Model Context Protocol (MCP) — an open standard introduced by Anthropic in November 2024 and since adopted across the industry. On its own, a large language model can only reason over what already sits in its context window. An MCP server gives that model a structured, permissioned way to reach the outside world: query a database, call a REST API, read a document, or take an action inside a live application. MCP is often described as a "USB-C port for AI" — one consistent interface in place of a different bespoke integration for every tool and data source.
Under the hood the protocol speaks JSON-RPC 2.0. A client sends typed requests; the server answers with typed results. That uniformity is what lets a single assistant talk to dozens of unrelated systems without custom glue code for each one, and it is why MCP has become the de facto integration layer for agentic AI.
How the MCP architecture works
Three roles make up an MCP deployment. The host is the AI application the user interacts with — a desktop assistant, an IDE, or a chat product. Inside it, an MCP client manages a one-to-one connection to each server. The MCP server is the component that actually exposes capabilities. Servers offer three primitives:
Tools
Actions the model can invoke — "create a page", "run a query", "send an email".
Resources
Readable context — files, database rows, API responses, documentation.
Prompts
Reusable templates for common, repeatable workflows.
The model decides what to do; the server governs what is possible and enforces the rules. That separation is the whole point: the server is the trust boundary, not the model.
How are MCP servers hosted? Local vs remote
Hosting is where MCP moves from theory to production, and it starts with one fork in the road: local or remote. This choice drives the transport, the security model, and the operational burden.
Local (stdio) hosting
A local server runs as a subprocess on the same machine as the host application, communicating over standard input and output (the stdio transport). The client launches the server, pipes JSON-RPC messages across stdin/stdout, and shuts it down when finished. There is no network, no TLS and no authentication layer, because the server inherits the privileges of the local user. This is the right model for personal productivity, developer tooling and anything that needs direct access to local files or applications — simple, fast and private, but it only serves the one machine it runs on.
Remote (HTTP) hosting
A remote server runs as a long-lived web service that many users and clients reach over the internet. Modern remote servers use the Streamable HTTP transport introduced in the 2025 spec revisions, which replaced the earlier HTTP+SSE design. It uses a single endpoint that can optionally upgrade to a Server-Sent-Events stream when the server needs to push incremental results, and it supports stateless operation for easier scaling. Remote hosting is what makes an MCP server a product rather than a personal tool — and it introduces the real engineering: authentication, concurrency, state and uptime.
The four ways to host a remote MCP server
1. Self-hosted on a VPS or dedicated server
The most direct option: run the server (typically a Node.js or Python process) on a virtual private server or dedicated box, behind a reverse proxy such as Nginx or Caddy that terminates TLS. A process manager — systemd, PM2 or a Docker restart policy — keeps it alive. You get full control over the runtime, CPU, memory and network, at the cost of owning patching, scaling and monitoring yourself. This is the classic choice when a server needs persistent connections, heavy compute, or access to private infrastructure.
2. Containerised and orchestrated
Packaging the server as a Docker image makes it reproducible and portable; running it under Kubernetes (or a managed container service) adds horizontal scaling, rolling deploys, health probes and secret management. Containers also provide a natural sandbox boundary — valuable when a server exposes tools that execute code or touch sensitive systems. This is the standard for teams already operating a container platform.
3. Serverless and edge
Platforms such as Cloudflare Workers, AWS Lambda and Vercel let an MCP server scale to zero when idle and fan out globally under load, billing only for actual invocations. Cloudflare in particular offers first-class remote-MCP hosting, using Durable Objects to hold per-session state and built-in OAuth for authorisation. The trade-off is statelessness: because any request may hit a fresh instance, session state must be externalised — to a store like Redis, a Durable Object, or a database — rather than held in process memory. For bursty, globally distributed workloads this is often the most cost-effective and lowest-latency option.
4. Managed MCP platforms and registries
A growing ecosystem of platforms and registries will host, list or one-click-deploy MCP servers for you, handling the transport, TLS and auth plumbing so you ship capability rather than infrastructure. This is the lowest-operations path and the fastest route from a working server to a shared, discoverable endpoint.
| Hosting model | Best for | Trade-off |
|---|---|---|
| Local / stdio | Personal + dev tools | One machine only |
| VPS / dedicated | Full control, persistent | You own the ops |
| Containers / K8s | Teams, scaling, sandboxing | Platform overhead |
| Serverless / edge | Bursty, global, scale-to-zero | Must externalise state |
| Managed platform | Least ops, fastest ship | Less low-level control |
State, sessions and scaling
A remote server can be stateful or stateless. Stateful servers track a conversation using an Mcp-Session-Id header issued on initialisation, which is convenient but complicates horizontal scaling: requests for a session must either return to the same instance (sticky routing) or read shared state from an external store. Stateless servers treat every request independently, which makes them trivial to scale behind a load balancer and is a natural fit for serverless. The right choice depends on whether your tools need continuity across calls — a long-running job or a multi-step transaction leans stateful; a simple lookup or one-shot action can stay stateless.
How do you secure a remote MCP server?
Because a remote server can act on real systems, security is not optional. The MCP specification standardised on OAuth 2.1 for authorisation: the server behaves as an OAuth resource server, accepting scoped access tokens so a client is granted only the specific permissions a user approved. Beyond auth, a production deployment should enforce TLS everywhere, validate and sanitise all tool inputs, rate-limit clients, apply least-privilege scopes to every tool, sandbox code-executing tools inside containers, manage secrets in a vault rather than in code, and log every invocation for audit. Local HTTP servers should bind to localhost and validate the Origin header to defend against DNS-rebinding attacks. The guiding principle: the model is an untrusted caller, so the server — not the model — is the security boundary.
Reliability and observability
A hosted MCP server is production software and deserves production hygiene: health-check endpoints and readiness probes, structured logging of every request and tool call, metrics on latency and error rates, alerting on failures, and graceful handling of client disconnects during long streams. For anything that changes live systems, the highest-value additions are a preview step (show the diff before acting), reversible operations with a rollback path, and an audit trail tying each change back to the request that caused it. These turn an AI that can act into an AI you can trust to act.
Where Signalto fits
Signalto is a working example of MCP applied to a concrete business problem. Signalto is an AI-visibility platform built on a simple thesis — "SEO drives traffic. GEO controls answers" — because customers increasingly research businesses through assistants like ChatGPT, Claude and Perplexity before they ever visit a website. Its MCP server connects a live site to those assistants so the AI can read the site, benchmark it against the competitors that are winning the answer, and implement approved content and structured-data fixes inside a single conversation.
Crucially for a system that edits real sites, every change is previewed before it lands, snapshotted for rollback, governed by granular access control that can be revoked instantly, and fully logged — exactly the reliability discipline described above, delivered over MCP. You can read more on the Signalto homepage and about the integration itself on the Signalto MCP page.
Frequently asked questions
What is the difference between a local and a remote MCP server?
A local server runs as a subprocess on your own machine over the stdio transport, with no network or authentication — it inherits your local permissions and only serves that machine. A remote server runs as an HTTP web service that many clients reach over the internet, and therefore requires TLS, OAuth authorisation and concurrency handling.
What transport do modern remote MCP servers use?
Streamable HTTP, introduced in the 2025 revisions of the MCP specification. It uses a single endpoint that can upgrade to a Server-Sent-Events stream when needed and supports stateless operation. It replaced the earlier two-endpoint HTTP+SSE transport.
How are MCP servers authenticated?
Remote servers use OAuth 2.1: the server acts as an OAuth resource server and accepts scoped access tokens, so a client receives only the permissions the user approved. Local stdio servers do not authenticate separately — they run with the local user's privileges.
Do MCP servers need to run 24/7?
Remote servers effectively need to be continuously reachable, though serverless and edge hosting can scale to zero and cold-start on demand to save cost. Local servers only run while the host application launches them for a session.
Where should I host an MCP server?
Use local/stdio for personal and developer tools; a VPS or container for full control and persistent workloads; serverless or edge (for example Cloudflare Workers) for scale-to-zero and global low latency; and a managed MCP platform when you want the least operational overhead.
How much does it cost to host an MCP server?
Local servers are free — they run on your own machine. A small remote server on a VPS starts around a few dollars a month; containerised and Kubernetes deployments cost more but scale further; serverless/edge hosting bills per invocation and can be near-zero when idle. The real cost driver is usually the downstream systems the server calls, not the server process itself.
The takeaway
An MCP server is the bridge between an AI model and the real systems it needs to read and act on. Hosting it well is what separates a demo from a product: choose local for privacy and simplicity, or remote — self-hosted, containerised, serverless or managed — when the capability must be shared, secured and scaled. Whichever path you take, the servers that earn trust are the ones built with authentication, preview, rollback and audit from the start.
Related: MCP Minecraft mod — what "MCP" actually means · all guides
Written and maintained by ServerHostingReviews. Links to Signalto are editorial references to a relevant product.