Because it has no way in. A model can write about your industry all day, but it cannot see your CMS, your analytics, your project tracker, or your database unless something connects it. The Model Context Protocol is the standard built to be that connection, and it is quietly changing how web teams work.
We started paying attention to this because of a practical annoyance. AI tools were useful for writing and reviewing, and useless for anything that required knowing what was actually in a client's site. Every question ended with copying and pasting context by hand.
MCP is the answer the industry settled on. Here is what it is, in plain terms, and whether it is worth your attention yet.
An MCP server is a program that gives an AI application access to a specific system. The official documentation calls the Model Context Protocol "an open-source standard for connecting AI applications to external systems". A server is the piece that sits in front of one of those systems and exposes it in a way any AI client can use.
The documentation uses an analogy that is genuinely helpful. It compares MCP to a USB-C port for AI applications, saying that just as USB-C provides a standard way to connect devices, MCP provides a standard way to connect AI applications to external systems.
That standardisation is the whole point. Before it, every AI tool needed a custom integration with every service. Now a service builds one MCP server and every compatible AI application can use it. Build once, connect everywhere.
Through a client and server arrangement with three named parts. The docs define an MCP Host as the AI application that coordinates everything, an MCP Client as the component holding a connection to one server, and an MCP Server as the program that provides context. The host creates one client for each server it connects to.
A concrete example from the documentation makes it clearer. Visual Studio Code acts as a host. When it connects to a server, it creates a client object for that connection. Connect to a second server and it creates a second client. Each connection is dedicated rather than shared.
Underneath, MCP is built on JSON-RPC 2.0, which is a long-established way for programs to send each other requests and replies. The protocol splits into a data layer, which defines the messages, and a transport layer, which defines how those messages travel.
None of this is exotic. That is deliberate, and it is a large part of why adoption moved so fast.
They are the three things a server can offer, and the distinction matters. The documentation defines tools as executable functions the AI can invoke to perform actions, resources as data sources that provide context, and prompts as reusable templates that structure interactions with the model.
The practical difference is between reading and doing. A resource lets the model see something, such as a database schema or a file. A tool lets the model change something, such as running a query or creating a record. Prompts are the least discussed and are simply saved patterns for common requests.
The documentation gives a clean example. A server providing context about a database might expose tools for querying it, a resource containing the schema, and a prompt with examples of how to use the tools well.
Knowing which is which matters when you decide what to connect. A resource is low risk. A tool takes actions in a real system, and that deserves more thought.
Where it runs and how it talks. MCP supports two transports. Stdio uses standard input and output streams for direct communication between processes on the same machine, which the docs describe as giving optimal performance with no network overhead. Streamable HTTP uses HTTP requests and enables remote servers.
A local server runs on your own machine, which is the usual arrangement for something touching your filesystem. A remote server runs on a provider's platform and can serve many clients at once, which is how a hosted service exposes its own data.
Authentication only really applies to the remote case. The documentation notes that Streamable HTTP supports standard HTTP authentication including bearer tokens, API keys, and custom headers, and that MCP recommends using OAuth to obtain authentication tokens.
Because most of the tedious work in web projects is moving information between systems, and this is the first standard that makes that automatable without custom code for every pair. The value is not that AI writes your content. It is that AI can finally see the systems your work already lives in.
Think about what a routine site audit involves. Checking analytics, reading the CMS, looking at deploy history, cross-referencing tickets. Each one is a separate login and a separate export. Connecting those through MCP means asking once and getting an answer that spans all of them.
We are careful to describe this as a workflow change rather than a magic one. The model still needs a clear question and a person who can judge the answer. What changes is how much manual gathering sits between the question and the answer, and that is the part that actually eats a working day.
It also connects naturally to the automation most teams already run. Our guide to automating web workflows with Zapier and Make covers the rule-based version of this. MCP is what the same idea looks like when the thing making the decisions is a model rather than a rule.
The systems you already check every day. A CMS, so the model can see the real content structure. Analytics, so it can answer questions about behaviour rather than guessing. A project tracker, a design tool, a code repository, an error monitor. The documentation's own examples include a hosted error-tracking server and a local filesystem server.
The strongest use we have found is not generation but verification. Asking whether every page has a meta description, whether any CMS items are missing required fields, or whether a template changed since the last deploy are questions with correct answers, which is exactly the shape of work models handle reliably.
That fits the approach we already take to using AI to QA a website before launch. Checking is a better job for a model than creating, because a wrong check is obvious and a wrong sentence often is not.
Real ones, and worth taking seriously before connecting anything to a live system. A tool is an executable function. Giving a model access to tools means giving it the ability to act, and an action taken on a misunderstanding is still an action taken.
The protocol handles authentication properly, and OAuth being the recommended path for remote servers is a good sign of a standard that expects to be used in production. But authentication answers who is connecting, not whether what they asked for was wise.
Our own rule is to start with read access and add write access one tool at a time, with a person approving anything that changes client data. That is not caution for its own sake. It is that the cost of a wrong read is a wrong answer, and the cost of a wrong write is a client phone call.
Be careful with content coming back from a connected system too. Data returned by a server is input, not instruction, and a model that treats text found in a database as a command is a problem waiting to happen.
It is stable enough to use and still moving. The current protocol version at the time of writing is 2026-07-28, and that version deprecated two client features that earlier implementations relied on, sampling and logging. That is a healthy sign of a protocol being tidied up, and a reminder that things you build now may need revisiting.
Ecosystem support is the stronger argument. The documentation lists Claude and ChatGPT among supported AI assistants, alongside development tools including Visual Studio Code and Cursor. When competing model providers adopt the same connection standard, that standard is not going away.
Our honest read is that MCP has already won the integration question, and the remaining uncertainty is about details rather than direction. That is a reasonable position to build on, provided you build the parts you could change.
Completely. An agent using a website is working through the same interface a person would, reading pages and clicking things. MCP gives a model a structured connection to a system directly, with defined functions and typed inputs. One is improvisation, the other is an interface built on purpose.
Both matter, and they point at different work. Making your public site usable by agents is a design and markup problem, which we covered in our piece on whether AI agents can use your website. MCP is about your internal systems, where you control both ends.
Connect one thing you already trust and use it for a week. Analytics or a documentation repository is a good first choice, because both are read-only and the answers are easy to check. You will learn more from one real connection than from any amount of reading about the protocol.
Do not rebuild your workflow around it yet. Add it beside what you already do, notice which manual steps stop happening, and let that tell you where the value actually is. The teams getting the most from this are the ones who connected something small and paid attention.
If you are weighing how much of this belongs in your setup, or you want a site and content system that is genuinely legible to the tools you are adopting, we are happy to think it through with you. Let's talk. You can reach our team at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.