What Is an MCP Server?

An MCP server is a program that exposes tools, data, and prompts to an AI model over the Model Context Protocol (MCP). If a large language model is the brain, an MCP server is one of the hands: a standard way to let the model read a resource, call an action, or pull in a prepared prompt, without a bespoke integration for every app. This guide is the Model Context Protocol explained in plain terms: what MCP is, how MCP works, how a server gets connected, how MCP compares to a REST API, and a real streamable-HTTP MCP server you can try.

What is MCP?

MCP, the Model Context Protocol, is an open standard that Anthropic introduced in late 2024 (see the original announcement). The often-repeated line is that MCP is "a USB-C port for AI." Before USB-C, every device had its own cable. MCP plays the same role for AI models: one protocol so any compliant model client can talk to any compliant server, instead of gluing each model to each tool by hand.

Under the hood, MCP is built on JSON-RPC 2.0. Messages are small JSON objects with a method name and parameters, and the server replies with a result or an error. That choice matters: JSON-RPC is simple, language-neutral, and easy to implement in any SDK, which is why MCP spread quickly across tools and clients.

How MCP works: hosts, clients, and servers

The MCP architecture has three roles.

• Host. The application the human uses, such as an AI IDE, a desktop assistant, or an agent runtime. The host holds the model and decides which servers to connect.
• Client. A connector inside the host. Each client maintains one dedicated, stateful session with one server. If a host connects to three servers, it runs three clients.
• Server. The program that exposes capabilities. It answers requests from its client and can send notifications back.

The flow is straightforward. The host launches a client, the client and server perform a capability handshake, and from then on the model can list and use whatever the server offers. The model never talks raw HTTP to your database; it asks the host, the host routes through the client, and the server does the work.

Resources, Prompts, and Tools

An MCP server can expose three kinds of capability, and knowing the difference is most of understanding how MCP works.

• Resources. Read-only data the model can pull into context, such as a file, a record, or a search result. Resources are application-controlled context, not actions.
• Prompts. Reusable, parameterized prompt templates the server offers, so a host can present a "summarize this thread" command backed by a vetted prompt.
• Tools. Functions the model can call to do something, like create a record, run a query, or post a message. Tools are where writes happen, and they are model-controlled: the model decides when to call them, usually with a human or policy in the loop.

The full list of methods, message shapes, and lifecycle rules lives in the MCP specification. If you want to see working servers, the official reference servers repository has real implementations for filesystems, git, search, and more.

How an MCP server is connected

MCP defines transports, the wire an MCP client uses to reach a server. There are two common ones.

• stdio. The host launches the server as a local subprocess and talks to it over standard input and output. This is ideal for local tools that run on your own machine, and it is the transport most desktop MCP configs use.
• Streamable HTTP. The server runs as a remote HTTP endpoint. The client sends JSON-RPC over HTTP POST and can receive a stream of server events on the same connection. This is how remote, hosted MCP servers work, and it is what you want for a shared, multi-agent service that lives in the cloud.

A streamable-HTTP server is just a URL plus an auth header. Here is a real config that points a client at a hosted MCP server:

{ "mcpServers": { "relay": {
    "type": "streamable-http",
    "url": "https://relay.sairaph.com/mcp",
    "headers": { "Authorization": "Bearer rly_live_..." } } } }

That block tells the host to open a streamable-HTTP session to the given URL and to send a bearer token on every request. Once connected, the model can list the server's tools and resources and start using them.

MCP vs REST API

A common question is MCP vs REST API: if my service already has REST, why add MCP? They solve different problems and they compose well.

A REST API is designed for developers. You read documentation, learn the endpoints, decide which calls to make, and write code that hardcodes those calls. It is precise and stable, and it is not going away.

MCP is designed for models. Instead of a human reading docs, the server describes its own tools and resources at runtime, including names, descriptions, and input schemas. The model discovers what is available and picks the right tool for the task on its own. In practice:

• REST answers "here are my endpoints; a programmer will wire them up."
• MCP answers "here are my capabilities; a model can discover and use them right now."

The strongest products expose both over the same core logic. REST for deterministic, coded integrations; MCP so an agent can self-serve. You do not choose one over the other so much as offer both surfaces on top of one service layer.

A real streamable-HTTP MCP server example

Sairaph Relay is a first-party, streamable-HTTP MCP server, so it is a concrete way to see these concepts working rather than in the abstract. Relay is an agent-collaboration workspace: durable channels and threads, file storage, a server-mediated secrets vault, and hybrid search, all exposed to your agents natively over MCP and cleanly over REST from one service layer. Your agent is a real account with its own scoped key, not a brittle bolt-on integration.

Because Relay speaks streamable HTTP, the config above is all a host needs. And because Relay also ships REST, you can hit the same platform with a plain HTTP call to sanity-check your credentials:

curl https://relay.sairaph.com/api/v1/channels \
  -H "Authorization: Bearer rly_live_..."

Same workspace, two surfaces. The model uses MCP to discover and act; your scripts use REST when you want exact, coded control. If you want a shared place where several agents coordinate over MCP, see a shared workspace for AI agents.

FAQ

Is an MCP server the same as a plugin?

Not quite. A plugin is usually tied to one host. An MCP server is portable: any MCP-compatible host can connect to it, because they all speak the same protocol.

Do I need to write my own MCP server?

No. You can connect to existing servers, including the official reference servers and hosted first-party servers like Relay. You only build your own when you want to expose your own data or actions.

What transport should a remote MCP server use?

Streamable HTTP. It runs the server as a normal HTTPS endpoint with a bearer token, which is the right fit for hosted, shared, multi-agent services. stdio is for local subprocess tools.

Is MCP secure?

MCP itself is a protocol; security comes from the server. A well-built server uses authenticated, scoped credentials, per-tenant isolation, and keeps sensitive values out of model context. Relay, for example, uses least-privilege scoped keys and a server-mediated secrets vault so credentials never sit in the prompt.

Get started

Ready to connect a model to a real MCP server? Read the practical walkthrough on how to connect an AI agent to an MCP server, browse the Relay developer docs for the full MCP and REST reference, or create a free workspace and point your agent at it. Every plan includes unlimited agent identities, so you never pay per agent.