What Is an MCP Server? A Plain-English Guide

The Model Context Protocol is an open standard for connecting AI applications to external systems. Before it existed, every pairing of an assistant and a system needed its own integration: your CRM had to be wired into one chat app, then again into the next one, then again into whatever your team adopted six months later. MCP replaces that with one contract. A system implements the protocol once, and any compliant client can use it.

An MCP server is the side of that contract that owns the capability. It advertises what it can do, receives calls, does the work, and returns a result the model can read. It is deliberately unglamorous software: most useful MCP servers are a thin, well-typed shell around something that already existed.

The important consequence is who chooses. The model is not hard-wired to a fixed menu of functions decided at build time. It discovers the tool list at run time, reads the descriptions, and picks. That is why a good server spends more care on its tool descriptions than on almost anything else.

There are four moving parts and it is worth keeping them straight, because most confusion about MCP is really confusion about which piece someone means.

Servers speak over one of two transports. A local server runs on your own machine and talks over standard input and output, which is how filesystem and local-database servers work. A remote server is reached over HTTP, which is how a hosted service exposes itself to many users at once. The tools look identical to the model either way.

Most of the MCP servers written so far wrap systems the user already controls: their files, their repository, their issue tracker, their warehouse. The value is convenience, and the data is as trustworthy as whatever put it there.

A data MCP server has a harder job, because it is answering questions about the outside world. The web changes underneath it, sources disagree, pages get truncated silently, and a model that receives a confident-looking answer has no way to tell a fact from a plausible sentence. Convenience is not the product. Evidence is.

That changes the shape of the return value. A data server should hand back the value, the URL it was read from, the date it was observed, and an honest confidence marker when sources conflict or a single origin is all there is. It should also return an explicit empty rather than a guess. Those four habits are what let an agent do something consequential with the answer instead of merely summarising it.

The scraper.io MCP server is a remote Streamable HTTP server with ten typed tools: list_monitors, get_monitor, create_monitor, update_monitor, pause_monitor, resume_monitor, list_alerts, get_evaluation, list_channels and check_now. Read-only agents can be issued read-only keys; creating or changing a monitor requires an explicit write scope, and every call is isolated to a single workspace.

Connecting a remote server to a desktop client is a configuration file, not a build step. The block below is the Claude Desktop configuration we publish on the MCP page, where a copy button gives you the same thing with the exact endpoint for your workspace already filled in.

Clients that speak Streamable HTTP natively skip the bridge entirely and take a url plus an Authorization header. The pattern is the same everywhere: name the server, point at the endpoint, attach a scoped key, restart the client, and the tools appear in its tool list.

Here is the part people usually have to imagine. The block below is a trimmed result shaped from three real rows in the Frontier Lab Founders feed — people leaving major AI labs to start companies — as an agent would receive them.

Three things in that payload matter more than the values. Every row carries its own sources with the date each was observed, so the agent can cite rather than assert. Confidence is a field, not a tone: CONFIRMED means two or more independent origins, SIGNAL means a single origin, and the difference is visible to the model before it decides what to do. And a null is a null — Gabriel Petersson's capital is unknown, so it is returned as unknown rather than as a number that would read as fact.

An agent given this can behave sensibly. It can act on the confirmed row, flag the single-origin one for a human, and refuse to state a raise amount it was never given. An agent given three sentences of prose with no provenance can only sound confident.

An MCP server is not a competitor to your API; it is usually a layer over it. The API defines what is possible, and the server defines what a model is allowed to do, in language a model can read, with the authority scoped to the key in play. If you already have an API, most of the work of an MCP server is deciding which ten operations are worth exposing and describing them well.

The comparison with a retrieval index is more interesting. A RAG corpus is a snapshot: you embed documents once, and from then on the model answers from a frozen copy whose age it cannot see. That is fine for a policy handbook and quietly wrong for prices, filings, deprecations and contract notices, where the whole question is what changed this week.

The rule of thumb is simple. Use retrieval for stable knowledge you own. Use an MCP server for facts that move, and prefer one that hands back the source line with the value. If you want to see the underlying sets before wiring anything up, the live feeds are the same data these tools serve.