How the Model Context Protocol Works

November 1, 2026 · 5 min read

Close-up image of ethernet cables plugged into a network switch, showcasing IT infrastructure. — Photo by Brett Sayles on Pexels

The Model Context Protocol, usually called MCP, is a standard way for AI coding agents to talk to outside tools and data sources. Instead of writing a custom integration for every API or dashboard, a developer or a hosted service can expose an MCP server once. The coding agent then discovers what that server can do and calls it using a shared language.

For someone running a small site, the practical effect is that an agent can read analytics, create a report, or check a funnel without you copying numbers into a prompt. The agent does not need to know the internal API of every service. It only needs to know MCP.

The basic shape of MCP

MCP is a client-server protocol. The coding agent, such as Claude Code, Cursor, or Codex, acts as the client. The MCP server is a separate program or hosted service. They exchange JSON-RPC messages. The client sends a request, and the server sends a response. Notifications can also flow in one direction without a response.

The protocol defines methods for initializing a connection, listing capabilities, calling tools, and reading resources. This shared structure is what makes MCP useful across different models, clients, and servers.

The three things a server can expose

An MCP server can advertise three main types of capabilities:

Tools: actions the model can ask for, such as querying traffic data or creating a tracked link.
Resources: data the model can read, such as a list of pages or a saved report.
Prompts: reusable templates that help the agent perform a task with the right context.

Not every server uses all three. An analytics MCP server might focus mostly on tools and resources. A documentation server might expose mostly resources and prompts.

How a session starts

When a coding agent connects to an MCP server, it goes through a small handshake:

The client connects using a transport, either local or remote.
The client asks the server what protocol version and capabilities it supports.
The server responds with its list of tools, resources, and prompts.
The client keeps that list available for the current session.

After initialization, the agent can call any tool or read any resource the server exposed, subject to the client's permission settings.

Transports: local and remote

MCP can run over two common transports. The first is local standard input and output, often called stdio. In this mode, the coding agent starts the server as a subprocess and communicates with it directly. This is common for developer tools that need access to files or local processes.

The second is remote HTTP. A hosted server runs somewhere else, and the client connects to it over the network. Remote servers often use OAuth so you can sign in through your browser without pasting API keys into the agent. For a small site, remote servers are useful because there is nothing to install or keep running.

Security and trust

MCP servers can perform actions, so they should be treated like any integration with access to your data. Connect only servers you recognize, review what tools they expose, and remove ones you no longer use. Some clients ask for approval before connecting to a server or before running certain tools. The exact behavior depends on the coding agent and its settings.

A hosted MCP server with OAuth still acts on your behalf after you sign in. That is convenient, but it also means the server's access should match what you would be comfortable giving a dashboard or reporting tool.

What happens when you ask a question

Suppose you ask your coding agent: "Which pages dropped this week compared to last week?" The agent first looks at the MCP tools it has available. If an analytics server exposes a traffic comparison tool, the agent can call it with the right arguments, such as a page path or a date range.

The server returns structured data. The agent then turns that data into a plain answer. The key point is that the model is not guessing. It receives numbers and page names from the server, then summarizes them for you.

If your analytics tool exposes an MCP server, such as the hosted server from measuremy.site, the agent can read visitor counts, pages, sources, and funnel steps directly. You still need to sign in and connect the server, but after that the agent handles the protocol details.

Why MCP is different from a normal API

A normal API has its own endpoints, authentication, error formats, and data shapes. Each integration requires custom code or a custom plugin. MCP standardizes the discovery and invocation layer. The agent knows how to list tools and call them, regardless of which server is behind them.

That does not mean MCP removes all integration work. The server still has to implement the actual logic and connect to the underlying data source. MCP is the common interface, not the work itself.

What MCP does not do

It is worth being clear about the limits:

MCP does not make a model smarter.
It does not bypass permissions.
It does not guarantee data quality; the output is only as good as the source system.
It is not a dashboard or an app; it is a protocol for communication.

Treat MCP as a way to give a coding agent reliable access to tools and data you already trust.

Where this fits for small sites

For a founder or developer running a small site, MCP is most useful when it removes repetitive manual steps. Common starting points include:

Asking the agent to compare traffic between two weeks.
Asking the agent to find the biggest drop-off in a funnel.
Asking the agent to create a tracked campaign link.
Asking the agent to check analytics after a code deploy.

These tasks are useful because they combine structured data with a short written explanation. The agent does the retrieval and the summary, and you can verify the answer against your own dashboard.

MCP is worth understanding because it changes how you interact with your own site data. Instead of learning each dashboard's export process, you can ask your coding agent a direct question and let it use the tools you have already connected. Start with one small task, check the answer against your dashboard, and build trust before relying on it for bigger decisions.

See it on your own site

measuremy.site is cookieless analytics your coding agent can read. 30-day free trial, no card. Plans from $9/month.

Start free trial See the live demo

Add measuremy.site analytics to this project: connect the measuremy.site MCP server at https://a.measuremy.site/mcp for all my projects (claude mcp add --scope user; it signs in with OAuth, no key, and one sign-in covers every site), then tell me how to sign in. Details: measuremy.site/llms.txt

Free tools

Analytics tag checker: Which analytics and pixels a site runs, plus duplicate and broken tags.
Free UTM link builder: Add utm_source, medium and campaign to any link.
Website traffic checker: A site's popularity rank and estimated monthly visits.

All free tools