What is MCP, and what it means for building websites
What is MCP? The open protocol that lets an AI agent use real tools. What it changes about building client websites, and what it doesn't change at all.
Until recently, using an AI assistant on a website project meant a lot of copying and pasting. You asked for copy, pasted it into the CMS. You asked for a template, pasted it into a file. You described a bug, pasted the error back. The assistant could think, but it couldn't touch anything. MCP is the reason that's changing.
A plain definition
MCP, the Model Context Protocol, is an open standard for letting an AI agent discover and use tools on another service.
A service that supports MCP runs an MCP server. The server describes the tools it offers, what each one does and what it needs, and the agent, whether that's Claude, Cursor or another assistant, can read that list and call the tools as it works. "Create a page", "list the content types", "upload this image" become actions the agent can take directly, not instructions it writes for a human to follow.
Anthropic introduced MCP in late 2024. In December 2025 it gave MCP to the Agentic AI Foundation, a new home under the Linux Foundation that Anthropic co-founded with Block and OpenAI, so it's now governed as a neutral open project rather than by one company. It's supported by a wide range of agents and developer tools.
What changes for agencies
The agent works in the real platform. Instead of describing a content model for you to build, it creates the content types and fields. Instead of drafting page copy in a chat window, it composes the pages from your sections. Instead of writing a theme you then upload, it writes the theme files and pushes them where they need to go.
Everything it makes is a real object: a content type you can open, a page you can edit by hand, a form with an inbox. Nothing is a screenshot or a suggestion. That's the shift. The work an agent does becomes the same as work a person did in the CMS, and it can be reviewed, changed and undone the same way.
For a website project, that makes the grunt work fast: setting up a model from a brief, entering forty team members from a spreadsheet, building the first draft of every page. Why there's no AI chat box for building your site explains why we let you bring your own agent to do this, rather than building one in.
What doesn't change
Judgement. The agent doesn't know which of the client's four competing priorities is the real one. Design: an agent can build to a design system, but someone still decides what the brand looks like. The client conversation, which is most of an agency's actual job. And review, because an agent will do exactly what it was asked, including the wrong thing, very quickly.
If anything, MCP moves the agency's value further towards those things. The typing gets cheaper. The deciding doesn't.
Safety, in agency language
Giving a program the ability to change a client's site sounds alarming, and it should be taken seriously. The good news is that the safeguards are ordinary ones.
Scoped tokens. An agent connects with a credential that only reaches one workspace and only the things that credential allows.
Read-only connections. For research or audits, connect in a mode where the agent can look but not change anything.
Content-only connections. Give the agent content tools only, with no publish, deploy, structure or settings tools available at all.
Staging before production. Changes land somewhere private first, and a person promotes them to the live site.
Filters that only remove. On a well-built server, narrowing a connection can take tools away but never add one the credential didn't already allow.
On Contentive all of these are how the MCP server works, and on a site with deployments, an agent with no environment chosen writes content to staging by default. Building a CMS an AI agent can actually drive is the developer version of this section.
Where MCP is overhyped
An agent with tools is not a strategy. Connecting one to a CMS doesn't make a site better. It makes producing a site faster, which is only good if what's produced is good.
Tool quality matters more than tool count. A server with a long list of vaguely described tools gives an agent more ways to guess wrong. What helps is tools that describe themselves clearly, errors that say what to do next, and a way for the agent to ask what already exists before it changes anything. When you evaluate any platform's MCP support, ask about those, not the number.
And MCP doesn't make an agent understand your client. That part is still the brief, and the brief is still yours to write.
What a session looks like
A typical session on a website project goes like this. The agent asks the server what exists: the content types, the pages, the sections available. It reads the brief you gave it. It creates what's missing, a "service" type with name, summary and price fields, for example, and gets back a real identifier it can use in the next step. It creates pages from your sections, filling in each one. If something fails, a good server tells it what went wrong and what to do instead, so it corrects itself rather than guessing. At the end, a person opens the platform and reviews what's there.
Try it in an hour
Pick any platform with an MCP server and make a throwaway workspace with nothing real in it. Connect your agent with a scoped token. Give it a short brief for a fictional business: three types of content, five pages, a contact form. Watch what it does, then open the workspace and look at everything it made, as a person would. Change something by hand. Then ask the agent what it would do differently.
An hour of that will tell you more about what agents can do on your projects than any article, this one included. When you're ready for a real one, how to build a website with Claude Code walks through a client site step by step.