What is an MCP server, actually?

A language model on its own cannot read your files, query your database, or remember yesterday. It produces text. Everything else — every action, every lookup — happens because some program outside the model went and did it.

Before the Model Context Protocol, every one of those connections was bespoke. If you wanted Claude to read your Notion and ChatGPT to read your Notion, you wrote two integrations against two different plugin systems, and neither survived the vendor's next release. MCP is the agreement that ends that: one server, any client that speaks the protocol.

The shape of it

There are three parties. The host is the app you actually use — a desktop assistant, an IDE, a chat interface. The client lives inside the host and manages one connection. The server is the thing you or someone else wrote, and it holds the capability: access to a filesystem, a Postgres instance, a calendar, a memory store.

They talk JSON-RPC 2.0. That is not a detail worth dwelling on, but it is worth knowing, because it means the whole thing is inspectable. You can read the messages. There is no magic layer where the model "decides" something you cannot see.

The sequence is dull on purpose: the client connects, the two sides exchange capabilities, the client asks what the server offers, and from then on the model can request one of those things by name. The server executes. The result comes back as text the model reads.

The three things a server can expose

Almost every server you will meet uses the first one and ignores the other two. All three are worth understanding, because the difference is about who decides.

• Tools — functions the model may call on its own initiative. `search_memory`, `create_issue`, `run_query`. The model reads your description of the tool and decides when it applies. This is where the power is, and where the risk is.
• Resources — data the *host* reads and puts into context. A file, a record, a document. The model does not trigger it; the application does. Less autonomy, more predictability.
• Prompts — reusable templates the user picks deliberately. Closest to a slash command.

One consequence people discover late: a tool's description is not documentation, it is instructions to the model. If a tool is never called when it should be, the fix is usually not the code — it is that the description failed to tell the model what situation it belongs to. We rewrote ours for exactly this reason and the call rate changed immediately.

Local or remote: the choice that matters

Two transports exist, and picking between them decides most of what your setup feels like.

stdio runs the server as a child process on your own machine. The host launches a command, talks to it over standard input and output, and kills it on exit. Nothing leaves the device. It is the right answer for anything touching local files, and it is why the filesystem and git servers work the way they do. The cost: it exists only on that machine. Your laptop and your phone do not share it, and the server is only alive while the app is.

HTTP runs the server somewhere reachable. The host connects over the network, usually authenticating with OAuth 2.0. Now every device sees the same server, and a hosted service can be one. The cost: you are trusting whoever runs it, and you should know where it runs — which is the subject of another article here.

For memory specifically, this is not a close call. A memory that only exists on one laptop is a notebook. The entire point of the thing is that the assistant you open on another device already knows.

What a server can do to you

An MCP server is code you granted the right to act. Treat it accordingly.

A local server runs with your user's permissions — it can read anything you can read. A remote one receives whatever the model sends it, which over time is a great deal about you. And a tool description is model-facing text, so a server can shape how the assistant behaves, not merely answer it.

Four questions worth asking before installing one:

1. Can I read the source, or is this a binary from a stranger?
2. What permissions does it hold — a single directory, or my whole home?
3. If remote: who operates it, in which country, and can I delete my data?
4. Does it write, or only read? A read-only server has a much smaller blast radius.

The ecosystem is young and mostly built by individuals in good faith. That is not the same as audited. The official registry and the community lists are discovery tools, not endorsements.

When you should write one

The bar is low — a server exposing two tools is a short file in Python or TypeScript, and the SDKs handle the protocol. The real question is whether a tool is the right shape for what you want.

It usually is when the assistant needs to *act* on a live system, or fetch something that changes. It usually is not when you just need the model to know a fixed body of text — pasting that in, or exposing it as a resource, is simpler and more reliable than teaching the model to go ask for it.

If you want the details, the specification is short and readable, which is rare and says something good about the project.

Pryzm is a remote MCP server whose single job is memory: it stores what you tell it and retrieves the relevant parts later, in any client that speaks the protocol. If you would rather run your own, several free self-hostable memory servers exist and we list them in our comparison.