MCP Architecture, Explained Without the Jargon

What is MCP?

The Model Context Protocol is an open standard for connecting AI assistants to external systems: your analytics, your CMS, your visibility data, your database. MCP follows a client-server model: an AI application embeds an MCP client, an external service runs an MCP server, and the protocol defines how client and server communicate. Anthropic open-sourced it in November 2024, modelled on the Language Server Protocol that solved the same many-to-many problem for code editors, and since December 2025 it has been governed by the Agentic AI Foundation under the Linux Foundation. Every message on the wire is JSON-RPC 2.0, which is a fancy name for a small, boring, twenty-year-old format: a method name, parameters, and an id to match responses to requests.

The point of the standard is that integration stops being pairwise. Before MCP, every assistant needed custom code for every service, and large language models could only reach what their vendor had integrated. After it, a service publishes one server and every MCP client can use it, whether that client is Claude, ChatGPT, Cursor or a script. It is the reason connecting RankX AI to Claude is a paste-one-URL job rather than a development project.

Who talks to whom in the MCP architecture?

Three roles make up the client-server architecture. The MCP host is the AI application you actually use: Claude Desktop, ChatGPT, an editor or development environment. Inside the host live MCP clients, one per connection, each holding a conversation with exactly one server. The server is the service side: MCP servers expose what their systems can do, so a single MCP client talks to one server, and one host can run many. RankX AI's server, for example, exposes 66 tools over the company's visibility, rank tracking, audit and publishing surface.

A server offers up to three kinds of thing, the protocol's primitives. Tools are functions the model can call, and they carry the weight of the protocol. Resources are external data sources the client can read, like files or documents. Prompts are reusable templates a user can invoke. Most servers you will meet in SEO work, RankX AI's included, are tool servers.

What are the layers of the MCP architecture?

The MCP specification splits the architecture in two. The data layer defines what the messages mean: MCP uses JSON-RPC 2.0 for lifecycle, for the tools, resources and prompts primitives, and for how AI agents discover capabilities a server offers. The transport layer defines how those messages travel, and there are two standard transports: stdio runs the server as a local subprocess of the host, reading and writing newline-delimited JSON, simple, private and confined to your machine; streamable HTTP serves the protocol from one web endpoint, where the client POSTs each message and the server answers with plain JSON or a stream. The older two-endpoint SSE transport was replaced in March 2025 and is formally deprecated.

The split matters because each layer changes independently: the same data layer runs over either transport, so a local MCP server and a hosted one behave identically in conversation. The transport choice is really about where the code should live, and remote versus local servers gets its own article; the short version is that hosted servers over streamable HTTP have become the default for anything with an account behind it, with OAuth 2.1 and mandatory PKCE as the authorisation framework since March 2025.

What actually happens when an assistant uses a tool?

1. The client connects and asks the server what it can do. The core request is tools/list, and the answer is a list of available tools, each with a name, a human-readable description and a JSON Schema for its inputs.
2. Those descriptions go to the model, because LLMs choose tools by reading about them. This is the quietly clever part: the tool list is prompt material, so the server explains itself to the assistant in the same language it would explain itself to you.
3. The model decides a tool is relevant and the client sends tools/call with the tool's name and arguments. A well-behaved host keeps a human able to see and deny the call, and the spec says so explicitly.
4. The server does the work and returns content: text, structured data, sometimes images. A tool failure comes back as a result with an error flag rather than a dead connection, so the model can read what went wrong and correct itself.
5. The result travels back to the LLM as context, and the model writes its answer from it.

That loop, list then call then read, is the whole mechanism. When you ask Claude which prompts your brand is invisible on and it answers with your own tracked data, it ran exactly that loop against get_prompt_visibility, a tool it discovered thirty seconds after you connected the server.

How does MCP compare to RAG and function calling?

The three get conflated because all of them bring outside knowledge to large language models, and they sit at different layers. Function calling is a model capability: the vendor-specific mechanism by which an LLM emits a structured request to run a function, and every model does it slightly differently. MCP standardises what sits on the other side of that call, so the same server works whatever AI model the host runs. RAG, retrieval augmented generation, is an application pattern: fetch relevant context, often to access real-time data the model was never trained on, and hand it over. MCP versus RAG is therefore a false choice; an MCP tool that answers a query over your data IS retrieval, and MCP simply gives the retrieval a standard doorway.

The practical reading: function calling is how the model picks an MCP tool, MCP is how the tool is discovered and called, and RAG is one of many things a tool can do once called. The layers compose, which is why the question worth asking a vendor is never which acronym they support but what their server actually exposes.

What changed in the 2026-07-28 revision?

A lot, and most explainers have not caught up. The revision finalised on 28 July 2026 is the largest in the protocol's history: it makes the core stateless, so any request can land on any server instance and hosted servers deploy behind ordinary load balancers, removes the initialize handshake and protocol-level sessions, adds a server/discover request for capability discovery, and deprecates the roots, sampling and logging features with a twelve-month migration window. Server-initiated requests give way to a pattern where the server answers that it needs input and the client retries with it.

What you will actually meet in August 2026 is still mostly the 2025-06-18 and 2025-11-25 behaviour, because clients migrate more slowly than specifications. Nothing about the mental model above changes either way: servers describe tools, models pick them, clients call them, results come back as data.

Why does MCP matter for SEO and marketing work?

MCP enables AI agents to interact with external systems through one standard doorway, and the interesting question was never the protocol; it is what becomes askable once your tools speak it. Rank tracking, AI visibility, audits and Search Console data all join one conversational workflow you can drive in a sentence, and running a full visibility audit from inside Claude shows what that looks like end to end. One honest caveat belongs in every explainer: tool output and tool descriptions are untrusted text, and hidden instructions inside them have been demonstrated to steer agents, which is why RankX AI's server tells every connected assistant to treat what tools return as data, never as instructions. The ecosystem of servers worth connecting is the practical next read.

Sources

• Model Context Protocol specification, versioning and changelogs, checked 20 Aug 2026
• MCP blog, the 2026-07-28 release (SDK download figures), checked 20 Aug 2026
• MCP joins the Agentic AI Foundation, 9 December 2025, checked 20 Aug 2026
• Anthropic, Introducing the Model Context Protocol, November 2024, checked 20 Aug 2026
• Docker, MCP tool-poisoning incident write-up (Invariant Labs disclosure), checked 20 Aug 2026
• PulseMCP server directory count, checked 20 Aug 2026