What Is an MCP Server? A Plain-English Guide

An MCP server is a program that gives an AI app access to your tools and data. It speaks the Model Context Protocol, an open standard built on JSON-RPC 2.0. The AI app connects, asks what the server can do, then calls it. (Model Context Protocol docs)

That is the whole idea. No custom plugin format per AI tool. One server, many clients. For a CMS like Draftbase, it lets an agent read and edit real content instead of guessing at it.

What Is an MCP Server, Exactly?

MCP names three roles. The host is the AI app itself, like Claude Code or VS Code. The client is the link object inside that host. The server is your program. It holds the tools and data.

One host runs many clients. Each client owns its own link to a single server. Hook VS Code up to a Sentry server and a file server, and it spins up two clients. (Model Context Protocol docs)

The word "server" is a bit off here. An MCP server need not run on some far-off box. It often runs as a local process on your laptop. Where it runs is a transport detail. It is not part of what the thing is.

What Does an MCP Server Expose?

A server offers three kinds of thing. The spec calls them primitives.

Primitive	What it is	Example
Tools	Code the model can call to do a thing	Create a blog entry, run a query
Resources	Read-only data the model can pull in	A schema, a file
Prompts	Reusable instruction templates	A "write release notes" flow

Tools are the ones folks mean most of the time. Each tool has a name, a short blurb, and an inputSchema in JSON Schema. That schema is how the model knows what to send.

Lookup works the same way for all three. The client calls tools/list to see what is there. Then it calls tools/call to run one. Resources and prompts share that list-then-use shape.

Clients can expose a primitive too. It is called elicitation. It lets a server ask the user a question mid-task. Sampling and logging used to be client primitives. Both are now dropped, as of spec version 2026-07-28. (Model Context Protocol docs)

How Does an MCP Server Talk to a Client?

Every message is JSON-RPC 2.0. A request gets an id and a reply. A notice gets no id and no reply.

There are two transports. Stdio pipes messages over standard input and output. It fits a local server on the same machine. There is no network hop at all. Streamable HTTP sends an HTTP POST per message. It can add Server-Sent Events for streaming. Use that one for remote servers.

Streamable HTTP takes normal HTTP auth. Bearer tokens, API keys, and custom headers all work. The spec suggests OAuth for getting those tokens. (Model Context Protocol docs)

A tool call looks plain on the wire. That is the point.

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "create_entry",
    "arguments": { "templateId": "blogPost", "locale": "en" }
  }
}

Why Did MCP Spread So Fast?

Before MCP, each AI tool wanted its own hookup format. Ten AI apps and ten data sources meant a hundred connectors. A shared protocol turns that into twenty.

The numbers moved fast. One year after launch, MCP had over 97 million monthly SDK downloads. It had roughly 10,000 live servers. (Anthropic)

Ownership moved too. Anthropic gave MCP to the Agentic AI Foundation in December 2025. That fund sits under the Linux Foundation. Block and OpenAI co-founded it. Google, Microsoft, AWS, and Cloudflare back it. (MCP Blog)

That matters when you pick a protocol to build on. A neutral owner cuts the odds of a rug-pull later.

How Is an MCP Server Different From a REST API?

It is a fair question, since both sit behind HTTP. The gap is who reads the docs.

A REST API expects a human to read a spec and write client code. Endpoints, paths, and payload shapes get wired up by hand, once. Change the shape and the client breaks until someone fixes it.

An MCP server hands its own docs to the model at runtime. The tools/list reply carries each name, blurb, and JSON Schema. No one writes glue code per tool. Add a tool and every connected agent can use it on the next lookup.

So MCP does not replace your REST API. It usually wraps one. Draftbase's MCP server calls the same backend routes the web app calls. The tool layer just makes those routes legible to a model.

The practical upshot is scope. A REST API is a surface for developers. An MCP server is a surface for agents. They can share a backend and still want very different shapes on top.

The Part Most Guides Get Wrong: MCP Is Stateless Now

Search this topic and you will read that a server holds a stateful session. Most of those posts were written in 2025. The spec has changed since.

MCP is a stateless protocol as of spec version 2026-07-28. Each request carries its own version and capabilities in a _meta field. The server infers nothing from past requests. (Model Context Protocol docs)

There is now a required server/discover call. It returns the versions a server takes, what it can do, and a cache hint. Replies carry ttlMs and cacheScope. A client can reuse a tool list for minutes instead of re-fetching it.

This is not trivia. It changes how you ship. A stateless server can run as a plain serverless function. Draftbase's own MCP server does just that, over Streamable HTTP.

Change notices went opt-in too. A client opens a subscriptions/listen stream. It names the events it wants. The spec says delivery is best-effort. Clients should still poll to stay fresh.

Is It Safe to Point an Agent at One?

Not by default. A tool blurb is text, and the model reads it. So a bad server can hide orders in that text. The attack has a name: tool poisoning. OWASP tracks it as its own entry. (OWASP)

Treat a third-party MCP server like any other dependency with write access. Read what it exposes. Check who ships it. Scope its token to the least it needs.

The server side has homework too. Auth belongs at the transport layer, not in a tool argument. Write tools should be split from read tools, so a token can grant one and not the other. And any tool that changes live state should be its own call, never a side effect of a read.

What an MCP Server Looks Like for a CMS

Most public MCP servers are read-only. They fetch docs, search code, or query logs. Write access is where the design gets hard.

An agent that edits content needs three things a reader does not. It needs the schema up front, so it does not invent fields. It needs an undo path. And it needs a wall between draft and live.

Draftbase's MCP server ships 26 tools. They cover content types, entries, media, and MDX parts. list_templates returns the field schema. list_entry_revisions and rollback_entry are the undo path. set_entry_status and schedule_entry_publish decide what goes live.

The safety rule here is dull and vital. create_entry only ever makes a draft. Going live is a second, separate call. An agent cannot push content to your live site by mistake.

Token cost is the other limit people miss. Every tool blurb sits in the model's context on every turn. A server with 80 chatty tools burns budget before the first real call. Draftbase's server sends an instructions string. It tells agents to batch field defs into one call, and to skip repeat lookups.

Content shape counts as much as tool shape. Draftbase stores rich text as plain MDX strings. It is not a nested JSON tree. A model can read and write MDX on sight. It does not need to learn a custom node format first. That is a real edge over a CMS with a closed rich-text format.

See the content type guide for how those schemas get defined. The Draftbase MCP docs cover hooking up a client.

Conclusion

An MCP server exposes tools, resources, and prompts over JSON-RPC 2.0. Any MCP-ready AI app can then use them. The protocol went stateless in the 2026-07-28 version. That makes serverless hosting easy.

If your content sits in a CMS, an MCP server is how an agent edits it safely. Draftbase was built for that job. Plain MDX storage, schema-first tools, revisions with rollback, and a hard draft-to-live wall. See the MCP-connected AI page for what agents can do with your content. Or check pricing to start.