What is MCP (Model Context Protocol)? A guide for non-developers

MCP — the Model Context Protocol — is an open standard that lets an AI assistant connect to outside tools and services in one consistent way, instead of a custom integration for every app. A service speaks MCP once and works with any assistant that speaks it too. For a website, MCP is what lets the assistant that built your pages also publish them.

This is written for people who keep meeting the acronym in setup instructions and want to know what it actually is. No code, and no setup steps.

What MCP actually is

MCP is a standard, not a product. Nobody sells you MCP and nothing is called "an MCP". It is an agreed way for two pieces of software to talk: on one side an AI application, on the other a service offering the external tools and data an AI model cannot reach on its own.

Anthropic published it in November 2024 as "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools." The protocol's own documentation describes it as "an open-source standard for connecting AI applications to external systems," and reaches for a hardware comparison: think of MCP as a USB-C port for AI applications, one connector shape instead of a drawer of cables.

That analogy is the official one, and it is doing the same work USB-C did. The port is not the interesting part. What matters is that the number of adapters stopped growing.

The problem it was built to solve

Before MCP, connecting an assistant to anything meant building that connection from scratch, once per pairing. Anthropic's announcement put the cost plainly: "Every new data source requires its own custom implementation, making truly connected systems difficult to scale."

The arithmetic is what makes it painful. Every assistant times every service is a separate piece of work, and none of it transfers. A calendar integration written for one assistant does nothing for the next one. Multiply that across every tool anyone might want, and most of the connections simply never get built.

You felt the result even if you never saw the cause. An AI model could describe in convincing detail how to move a file, edit a page, or check your schedule, and then could not do any of it. It could talk about your work but never touch it.

How it works: a host, a client, and a server

Three names come up constantly, and they are less mysterious than they sound. The protocol's architecture overview defines them like this:

• The MCP host is the AI application you are actually sitting in — Claude Desktop, ChatGPT, Cursor, an editor. It coordinates everything.
• A client is the part of the host that holds one connection open. The host creates one client per server it talks to, so three connected services means three clients.
• An MCP server is the program on the other end, the one that has something to offer. Despite the name, it does not have to be a machine in a data centre. It can be a small program running on your own laptop.

An MCP server advertises what it can do in three flavours: tools, which are actions the assistant can take; resources, which are data it can read; and prompts, which are ready-made templates. The assistant asks the server what it has, gets a list back, and works from that list.

Underneath, the messages are ordinary JSON-RPC, and there are two ways to carry them: a local connection between programs on the same machine, and a streamable HTTP connection to a service somewhere else. That is the whole of the plumbing you need to know as a user, and the last time this article will mention it.

MCP and an API are not the same thing

This is the question people ask most, and the usual answer overstates it. An MCP server is not a replacement for an API. In practice a server very often sits directly on top of one, passing requests through to the same place a developer would have called anyway.

The difference is who reads the documentation.

With an API, a person reads the docs, decides which calls matter, writes the code, handles the errors, and ships it. Nothing works until someone does that, and the work is specific to one pairing of app and service.

With MCP, the server describes itself — here are my tools, here is what each one needs, here is what it returns — and the assistant reads that description when it needs it. The integration work happened once, on the server's side, for everyone.

So the honest framing is not "MCP beats APIs." It is that MCP moved the integration work from the point of use to the point of supply.

What a real MCP server contains

Most explanations stop at "the server exposes tools" and use a weather lookup as the example. That leaves the useful question unanswered: what does a real one contain?

Here is ours, in full. Birta's hosted connection gives an assistant a bounded set of named tools and nothing else. It can list, create, and rename projects; show visitor stats; manage versions and rollbacks; create and edit a draft file by file; declare lead forms; and read the leads those forms receive. It cannot delete a project or a lead.

That is the entire surface, and it makes the shape of MCP concrete in a way the abstractions do not.

The exact hosted and local inventories are different. The Birta MCP reference keeps both current, alongside real authorization and publication transcripts; this article keeps the concept explanation.

Two things stand out. First, everything is named and specific. There is no general "do something to my account" tool, and an assistant cannot invent one. Second, the list describes exactly one job. A connection built for publishing websites can publish websites. It cannot read your email, because nothing in that list reads email.

The reverse is just as true, and it is worth seeing once. Notion's hosted server gives an assistant a deep reach into a workspace's content and, as of this writing, nothing for putting a page on the web at all. The two surfaces side by side show how much a server's shape tells you about what it is for.

If you have also met the term Agent Skills and wondered whether it is the same idea, it is not. A Skill tells an assistant how to do a job; an MCP server gives it the hands, and that article uses this same server as the worked example.

Why this matters when what you want is a website

Here is the part the general explainers do not cover, because they are not thinking about your problem.

An assistant that can build a website has been able to do so for a while. It writes the HTML, the stylesheet, the copy. Then it stops, because the finished files are sitting somewhere it cannot leave, and getting them onto the internet was a separate job with separate tools that had nothing to do with the conversation you were just having.

MCP is what closes that gap from the inside. The same assistant that wrote the files can hand them to a host and get an address back, without you exporting anything, opening a dashboard, or learning a deployment pipeline. The change is not that publishing became more powerful. It is that publishing stopped being a different activity from building.

Plenty of places to put a website still have no connection of any kind. Google Sites is the clearest example: the only API it ever had was deprecated and never reached the current version, so an agent working on one has nothing to call.

Others went the other way and built one. InstaPods, an app host, publishes its own connector, so that comparison turns on what the tools actually reach rather than on whether they exist at all.

This also explains something that surprises people: it works from an ordinary chat, not only from a developer's editor. The assistant does not need to be running on your computer to publish a site. It needs a connection to a service that will accept one.

What that publishing layer should look like is a separate argument, and why the simple case ever got complicated is a different one again.

Two ways in, and why you should not have to choose

There is one real distinction between connections, and it is not the one people usually get told about.

Some AI tools can read and run things on your computer. Some cannot, because they live in a browser tab or an app. That single difference decides everything: a tool with access to your files can start a connection locally and hand over whole folders, while a tool without it connects to a hosted address over the internet and works file by file on a draft instead.

We got this wrong at first, and it is worth admitting. Our own landing page used to ask people to pick between a "chat" and a "coding agent" before it would show them anything. That is a question about our architecture, not about their work, and almost nobody should have been asked it. There is now one line to paste into whichever tool you already use; it reads making the site itself readable to machines and either connects itself or tells you which setting to open. If you would rather set it up by hand, the guides are organised by the name of your tool. What the agent actually does with that line, from reading the index to choosing a way in, is traced step by step in its own article.

Who is behind MCP, and who supports it

MCP started at Anthropic, and the first companies to build on it were mostly developer tools, with Block, Apollo, Zed, Replit and Sourcegraph named in the original announcement.

It did not stay a single company's project. On 9 December 2025 the Linux Foundation announced the Agentic AI Foundation, formed with founding contributions that included Anthropic's Model Context Protocol, Block's goose and OpenAI's AGENTS.md. Its members include Amazon Web Services, Cloudflare, Google, Microsoft and OpenAI. The stated point was to keep the protocol "open, neutral, and community-driven as it becomes critical infrastructure for AI."

For a standard, that matters more than adoption numbers. It means the assistant you use next year is unlikely to need a different connector.

What to watch out for

MCP is a way to connect things, which means it is also a way to give something access it did not have before. Three points are worth holding on to.

A connection acts with your permission. When an assistant calls a tool, the service on the other end sees an authorised request, so the question is never "can the AI be trusted" in the abstract, but what this particular connection is allowed to do.

Connect MCP servers you have a reason to trust. Anyone can write one, and a server's description of its own tools is written by whoever built it.

Look at what a server says it can do. That list is public by design, and a connection whose tools are broader than the job it was hired for is a fair thing to be suspicious of.

Ours asks for access in your browser: you sign in with a one-time code sent to your email and approve it there. There is no key to paste anywhere, and the first request from an unauthorised assistant is refused rather than queued, which comes back with a confirmation link, and nothing happens until you follow it.

The short version

The useful thing about MCP is not the protocol itself, which is deliberately boring. It is that the gap between an assistant describing work and doing it got smaller, and for anyone who has ever had a finished site with nowhere to put it, that gap was the whole problem.

If a site is what you are after: connect the tool you already use to Birta, ask it to publish, and you get a live HTTPS address. The last ten published versions are kept, so a change that goes wrong can be rolled back, and your own domain can point at it when you want your name in the bar. Pick your tool and it will walk you through the rest.

Frequently asked questions