MCP Server: What It Is and How to Choose One

At its core, an MCP server does three things: it advertises what it can do (its tools and resources), it accepts structured calls from a connected client, and it returns results the client feeds back into the model's context. Everything else, what's behind that interface, a file system, a search API, a graph database, is an implementation detail the protocol specification deliberately doesn't constrain.

That's a deliberate design choice. A knowledge graph memory server and a server that just reads local files both look identical from the client's perspective: a list of tools it can call. The protocol's job is standardizing that interface, not standardizing what's behind it.

A local MCP server runs as a process on your machine, usually launched by the client itself over stdio. It's simple to set up for personal use and keeps everything on-device, but it's inherently single-user: nothing it stores or does is visible to anyone else, and it has to be reinstalled and reconfigured on every machine that needs it.

A remote MCP server runs as a hosted HTTP service, reachable by URL and typically authenticated with an API key. That makes it naturally multi-client and multi-user: a whole team's coding agents, chat sessions, and automated jobs can all point at the same endpoint and share the same underlying state. For anything that needs to persist and be shared, like memory, remote is almost always the right shape.

Most early MCP servers were stateless: they wrapped an existing API (search, file access, a ticketing system) and didn't retain anything between calls. That's a fine model for a tool, but it's the wrong shape for memory, where the entire point is that facts persist and accumulate across many separate conversations.

A memory-oriented MCP server has to manage state carefully: what to store, how to index it for retrieval, and how to avoid unbounded growth. This is also where memory-management discipline matters most, since a server that keeps every session's raw output in memory indefinitely without compaction or eviction will eventually become slow and expensive to query.

"Remote" and "self-hosted" are often used interchangeably, but they answer different questions. Remote describes how a client reaches the server: over a URL rather than a local process. Self-hosted describes who operates that server: you, running it on your own VM, container, or cluster, rather than a vendor running it for you. A self-hosted MCP server is still remote from the client's point of view; the difference is entirely about who owns the box.

The tradeoff is the usual build-vs-buy one. A self-hosted MCP server gives you full control over data residency, network isolation, and upgrade timing, which matters for regulated data or strict compliance requirements. A vendor-hosted MCP server removes that operational burden, patching, scaling, uptime, but means trusting someone else with whatever flows through it, so it's worth checking where the data is stored, whether it's encrypted at rest and in transit, and whether you can export it if you ever need to switch.

The most common mistake is treating every MCP server as interchangeable because they all expose the same tool-call interface. A search server and a memory server look identical from a client's tool list, a name, a description, a schema, but one is stateless and disposable while the other holds data an agent can't easily regenerate. Losing a stateless tool server's connection for an hour is a minor annoyance; losing a memory server's data is a real loss, and the two deserve very different levels of scrutiny before you adopt them.

The second common mistake is skipping the authentication review because a single shared API key feels simpler to set up. That works fine for a solo user, but a team that grows past a handful of people usually needs per-user or per-org scoping, an audit trail of who connected when, and a way to revoke one person's access without rotating the key for everyone else. Checking for that up front is cheaper than migrating off a server that can't support it later.

Before wiring a new tool into an agent's context, run through a short list. Does it authenticate with a scoped, revocable credential rather than a static shared secret everyone copies into their config? Does it keep one organization's data separate from another's, or would a bug or a misconfigured export leak one team's memory into another team's session? Is there a log of what was read and written, so a bad answer can be traced back to whether it came from bad data or bad reasoning rather than staying a mystery? These aren't abstract concerns; they're the difference between an integration worth trusting with real work and one worth keeping at arm's length.

It's also worth asking what happens on failure. If the connection drops mid-session, does the client retry cleanly, or does a partial write leave inconsistent state behind that nobody notices until it causes a wrong answer weeks later? A service that's transparent about its retry and consistency behavior, and that lets you inspect exactly what got stored, is far easier to debug in production than one that just returns a green checkmark and hopes for the best. None of this shows up in a five-minute demo. It only surfaces once real usage starts, which is exactly why it's worth checking before committing to one option over another.

For anything beyond a personal, single-machine setup, a few things matter most: whether the server is remote and multi-tenant (so a whole team can share it), whether it authenticates properly per user or per organization, and whether it exposes enough structure, provenance, timestamps, source, to make its data trustworthy rather than a black box.

Retrieval quality matters just as much as storage. An MCP server backing AI agent memory that only supports exact keyword lookup will miss paraphrased queries, and one that only supports vector similarity will miss precise, structured facts. The better-performing servers in production combine multiple retrieval strategies rather than relying on one.

stored runs a hosted, remote MCP server behind a single URL and a per-org API key: no local process to run, no infrastructure to maintain, and every teammate's client connects to the same endpoint by default. That endpoint isn't stateless; it's backed by a live memory graph with hybrid retrieval, so a search call returns ranked results across graph relationships, vector similarity, and keyword matches in one query.

Because it's multi-tenant from the ground up, an organization's memory stays scoped to that organization, with owner, admin, and member roles controlling who can read and write it, while the underlying protocol connection looks exactly the same to Claude, Cursor, or Claude Code either way.