What Is an MCP Server? MCP Explained in Plain English (2026)

For almost two years now, your AI assistant has been able to interact with the outside world through MCP servers - small programs that translate between an AI like Claude and the tools, files and services you work with every day. Today we're going to learn what an MCP server is, how one works under the bonnet, how to plug one in without writing a line of code, and take a look at the latest features in the MCP library, because 2026 has been a big year for it.

A word on where I'm standing while I explain all this: I don't just use MCP servers, I build them. There are eleven open-source ones in the @houtini scope on npm - database queries, image generation, search-console data, email, file management - and my whole working day runs through them in Claude Desktop and Claude Code. So this is the view from both sides of the protocol, rather than a vendor explaining its own product. (New to Claude? New accounts get a free week of Claude Code , and the same Pro plan covers everything here.)

What is an MCP server?

MCP stands for Model Context Protocol - an open standard for connecting AI assistants to the tools and data they can't reach on their own. An MCP server is a small program that wraps something in the outside world (your database, your files, an API, a whole product) and describes what it can do in a way the AI understands. The assistant reads those descriptions and calls the right one when your request needs it.

Before MCP, an AI conversation was words in, words out. You'd ask Claude something, get an answer, then tab over to a browser and do the thing yourself - open the database client, copy some data, paste it back into the chat. Tim Berglund put the core problem better than I can: "that response is just words. But what if you want to do something?" One question, and it reframes what a chat interface is for.

With MCP servers wired in, the same conversation does the work. Claude queries my database, generates charts from the results, pulls files off my hard drive, checks my search-console data and pushes commits to GitHub when I ask it to - and I haven't opened a browser tab for any of it.

Everyone reaches for the USB-C comparison when they explain MCP, and I keep reaching for it too, even though Berglund was upfront that "comparing it to the USB-C of AI applications is probably not going to be helpful." He's right, it gets wobbly fast. But it's annoying when a cliche is still the quickest way in: before USB-C you had a drawer full of cables and none of them quite fit; before MCP, every AI app needed its own custom glue code for every tool it wanted to talk to.

The technical name for what MCP fixes is the N×M problem. Say you've got 5 AI clients and 10 tools - without a standard protocol, that's 50 separate integrations somebody has to build, maintain, and debug when they break. With MCP, you write one server for your tool, and Claude, ChatGPT, Gemini, VS Code and Cursor can all connect to it. As codebasics put it, "imagine all the companies in the world building millions of applications - that is a lot of glue code." And the maintenance cost is the bit nobody talks about: if an API you're wrapping changes its endpoints tomorrow, you're fixing that glue in one place instead of every client.

How an MCP server works

Here's the technical bit, kept short. Your AI application (Claude Desktop, Cursor, whatever) is the host. Inside the host sits a client that handles the protocol conversation - one client per server. The server is whatever external thing you're plugging in, wrapped up so the client knows how to talk to it.

It's JSON-RPC underneath, for what it's worth. Servers expose three types of things, but only the first one matters for most people:

• Tools are functions the AI can call - think POST requests if you've done web dev. Claude picks which tool to use on its own, from the tool's description. The description is everything: as codebasics explained, "the LLM has language intelligence so just by reading this description it can figure out which tool to call." It works, though it took me a while to trust it would pick the right one.
• Resources are read-only data - your files, database rows, API payloads. Fireship compared these to GET requests, which is decent shorthand.
• Prompts are reusable templates that show up in the host's UI. You trigger these, not the AI.

So in practice, tools are the ones doing the work. I prompt Claude "generate me a network diagram" and it calls a tool on my Gemini MCP server . I ask about search rankings and it hits Better Search Console without me specifying which server to use - Claude figures it out from the descriptions, sends the parameters, and hands me the result.

The penny-drop moment: building YubHub MCP-first

My own penny-drop moment with MCP came when I was building YubHub , as it happens. I built it API and MCP first, without really a thought for the UI at that point - I wanted simply to understand what the most useful features of the API would be. So I built the MCP server to support it, got YubHub working as a prototype inside Claude, and from there I could use plain human language to update job feeds and all of that kind of thing, well before we designed a UI at all.

That's one example of what an MCP server is really for: talking to the outside world through your AI assistant - in my case it's always Claude. And at one point, I really did think the future might look like the AI assistant as a kind of control surface, with applications taking a unified approach: you deal with a hundred percent of someone else's application through their MCP server, and never leave Claude - no browser, no logging in, no fishing an auth code out of your email. I've softened on "the whole future" since, but I still think MCP is a milestone in that journey, and the better servers already work this way.

Because here's the thing people miss when they describe MCPs as "tools for AI": technically that's accurate, but it undersells what the better servers do by a country mile. The Gemini MCP I built has separate tools for image generation, video, SVGs, landing pages, chart design and deep research - calling that a "tool" is like calling Photoshop a brush. Desktop Commander gives me file management, process control, and system-wide search. I've been calling these "mcpapps" - ugly word, I know, but "MCP servers that function as complete applications within your AI client" is worse. Claude Desktop has started feeling like an operating system to me, and MCPs are what I install on it.

MCP vs an API (and vs the command line)

A question that comes up constantly: if the tool already has an API, why do we need MCP at all? Because an API is written for programmers who read documentation - the AI can't discover what it does or how to call it without someone writing that glue code. An MCP server is self-describing: it tells the assistant what it can do, in language the model reads directly, and the model takes it from there. That self-description is the whole trick.

There are always alternatives, to be fair. Claude can run things through a command line, and that's powerful too - it's how I do a lot of my own development work. But MCP servers make this stuff accessible to non-technical people: nobody in your marketing team is going to learn a CLI, and every one of them can click Connect on a directory listing. That accessibility, more than any technical property, is why the protocol took off.

And it did take off. Anthropic wrote the spec, Claude had it first, and then everyone piled onto the same standard for once: ChatGPT added support (they call them "ChatGPT Apps", but it's MCP underneath), Google brought it to Gemini across their API and Vertex AI, VS Code baked it into Copilot's agent mode, and Cursor does one-click MCP installs. As of early 2026 the SDKs were seeing 97 million monthly downloads across more than 10,000 active servers.

How to use one without writing any code

If you're on Claude Desktop , the front door is the Connectors directory - no config files, no terminal. Customize → Connectors → Add opens the directory (around 440 verified integrations as of mid-2026): pick a service, click Connect, sign in via OAuth, done. Most take under two minutes.

For local MCP servers there are desktop extensions - .mcpb files you double-click to install, with the runtime bundled so the old dependency dance is gone. And for anything published on GitHub that hasn't been packaged yet, the escape hatch still works: edit claude_desktop_config.json by hand and restart. I wrote a step-by-step walkthrough for adding MCP servers with screenshots, but the gist is:

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/folder"]
    }
  }
}

Took me about five minutes the first time, and that included googling where the config file lives on Windows (it's %APPDATA%\Claude\claude_desktop_config.json - the system requirements guide covers file locations for both platforms).

What's new in the MCP library (September 2026)

The protocol has moved a long way this year, and it's worth knowing the shape of it even if you never read a spec document.

The July 2026 revision is the biggest change since launch

The 2026-07-28 spec made MCP stateless: the old session handshake is gone, every request now carries what it needs, and a new server/discover call lets clients ask a server what it supports up front. If that sounds like plumbing, here's what that means for you: stateless servers are dramatically easier to run remotely and at scale, which is what turns MCP from a thing on your laptop into a thing companies host for their customers. The same revision moved experimental features like tasks into official extensions, and retired several early features (Roots, Sampling, Logging) under a proper deprecation policy - the library is being gardened now, not just grown.

Remote servers grew up

The early MCP story was local-only; the 2026 story is remote servers with proper OAuth built into the protocol, which is what the Connectors directory runs on. That shift is why non-technical people can now use MCP without knowing it exists.

And nobody owns it any more

As of December 2025, MCP sits under the Linux Foundation's Agentic AI Foundation, with OpenAI, Google DeepMind, Microsoft, AWS, Cloudflare and Block as members. That was a genuine concern early on - building production infrastructure on one vendor's protocol - and it's resolved about as well as these things can be. We build on it commercially, and I sleep fine.

Is it safe?

The honest answer is: the protocol is sound, and the ecosystem is uneven. Two CVEs landed in March 2026 alone - an SSRF vulnerability in the Azure MCP Server that leaked managed identity tokens, and an unauthenticated SSRF in the Atlassian MCP server. The research points the same way: Adversa AI found 38% of 500+ scanned public MCP servers lack basic authentication, and Knostic counted 1,862 MCP servers sitting open on the public internet - of the 119 they sampled, every one handed over its tool listings without asking for credentials.

The thing to understand as a user: servers run with whatever permissions you hand them, and the protocol doesn't enforce boundaries - that's on you. My own rule is that I skim a server's main source file before I install anything, no exceptions, and I give file-system access to specific working folders rather than anything wider. The July spec revision tightened the authorisation story for remote servers, and hosts keep adding human-in-the-loop approval for destructive actions - the direction of travel is right - but "installed from a directory" is not the same as "audited", and it's worth keeping the two ideas separate.

Quality varies just as much as security. Some MCP servers feel like proper software: helpful error messages, sensible defaults, schema validation, response caching, thought given to what the LLM needs. The lazy ones pipe your request through to an API endpoint and hand back whatever comes out. You learn to spot the difference quickly.

Do MCP servers hallucinate?

I saw someone claim on LinkedIn that "MCPs hallucinate", and it's worth untangling, because the confusion points at something real. An MCP server can't hallucinate - it's deterministic software. The model does the talking; the server just executes and returns whatever it returns. But the worry underneath the claim is legitimate: a model summarising a big messy API response can still misread it, and then the mistake wears the tool's credibility.

Which is exactly why the strongest MCP pattern I know is putting a database inside the server. Our seo-audit MCP is essentially a wrapper around a SQLite database: the search-console and crawl data lands in tables, and Claude answers questions by writing SQL against them. It isn't "remembering" your rankings or paraphrasing a firehose of JSON - every number in the answer traces to a row that exists, and the model can only read what's there. I wrote up the general pattern in SQLite as an MCP context saver : stop cramming raw API data into the context window, store it, and let the model query it instead.

And for the more advanced reader wondering how a fleet of these runs day to day: we moved ours into containers - the Docker MCP gateway write-up covers how and why.

Where to go from here

If you've never used an MCP server, wire one in today - Customize → Connectors in Claude Desktop, pick Google Drive or GitHub, and give it a real task from your week. That first "it just did it" moment teaches you more than any explainer can, this one included.

From there:

• The best MCPs for Claude Desktop - the servers that turn the chat window into a workspace.
• The best MCPs for Claude Code - the developer-side stack.
• How to add an MCP server to Claude Desktop - the screenshot walkthrough for the config-file route.
• And if you're the builder type: the official spec and SDKs are where I started, and my first server was running in about twenty minutes with FastMCP.

The conversation window has become the place where applications run - it sounded a bit pretentious when I first wrote that sentence, and I still can't find a better way to describe it.