What is Model Context Protocol?

The short answer

An AI model on its own knows two things: what it was trained on, and what you paste into the chat. That second part is the bottleneck. You export a CSV, you screenshot a dashboard, you copy an error message, and the agent reasons over a snapshot that was already stale when you took it.

MCP removes the pasting. It defines a standard way for an AI client to talk to a server that wraps one source of truth, and a standard way for that server to describe what it offers. The client discovers the capabilities at connection time and calls them during the conversation, with no custom integration written for that pair.

Anthropic published the specification as an open standard in late 2024. The version an askbowtie connection negotiates today is 2025-03-26. It is not a Claude feature: any compliant client can talk to any compliant server, which is the entire point.

What a protocol actually buys you

Before a shared protocol, connecting agents to tools was a multiplication problem. Every client needed bespoke code for every tool, so the work grew with the product of the two numbers rather than their sum.

That last row is the one you feel. Under a standard, a new capability is available to every agent you already use the moment its author ships it, and nobody has to agree on a roadmap first.

What an MCP server exposes

A server is a small program that speaks the protocol and wraps exactly one domain. It advertises three kinds of thing, and in practice tools are where the value sits.

A tool definition is a name, a human description, and a JSON schema for its arguments. The description is not decoration. It is the only thing the agent reads when deciding whether this tool answers your question, so a server whose descriptions are vague gets called at the wrong moments.

askbowtie exposes 47 tools over one connection, covering traffic, conversions, JavaScript errors, Core Web Vitals, Search Console, Google Ads, uptime, crawl, page roles, section engagement, custom events, A/B tests and standing watches. Eight of them are frozen byte for byte, because external clients already depend on their exact shapes; everything added since is additive and never changes an existing response.

The three calls in every session

MCP is JSON-RPC 2.0 underneath, carried over a single POST /mcp endpoint in askbowtie's case, and a session is smaller than people expect. Three method names carry almost all of it.

The consequence of tools/list running once is worth knowing before it bites you: an already connected client holds the tool list it was given at connection. A server that adds a tool or changes a schema does not reach that client until the connection is restarted. If a colleague insists a tool does not exist and you can see it, one of you is holding an older list.

The protocol standardises the handshake and the shapes. It has no opinion at all about what your data means. That part is the server's job, and it is where servers differ most.

The worked example: a real chain, including the call that failed

Abstractions are easy to nod along to, so here is a real sequence, taken from askbowtie's own per-call activity log. Five calls, one user, the morning of 4 September 2026, all times UTC.

The refusal in the middle is the most useful row in the table, and it is the reason this example is worth printing. The agent asked a question it was not entitled to ask, got a flat domain_denied rather than a plausible-looking empty answer, worked out what it was allowed to see, and asked again. That is the protocol behaving correctly under an agent's mistake, and it is invisible in any account that only shows the calls that worked.

The six seconds between the first two calls carry the other half of the argument. get_incident_detail is documented as "call this after get_incidents", and it needs to be told which failure type to expand. Its schema does not force that type to come from the previous answer, so this is strong evidence rather than proof, but the same pair recurs at 19:47:07 the same day, and again at 05:52:51 against a different site. An agent that has just read a ranked list and then asks about one entry in it, six seconds later, is following the list.

What the calls found. The agent's own reply is not recorded anywhere, because askbowtie keeps no transcript. Re-running those same three reads on 2026-09-21, over the eight UTC days from 28 August to 4 September 2026, gives the shape of the answer. The calls' own arguments are not logged, so that is a window ending the morning they ran rather than provably the one they used: 41 of 127 logged problems needed action. Another 62 were the site's own but not urgent, and only 24 were blocked third-party scripts. All 41 of the urgent ones were a single JavaScript error signature, firing 42 times on /about-us. Over those same eight days the site took 7 conversions from 561 sessions, a rate of 1.2%, and every one of the 7 fired on the home page. None on /about-us.

So the ending is a judgement, not a number: the only error the site is actually responsible for lives on a page that converts nobody. Worth fixing, not worth fixing first. Five calls, one of them correctly refused, to get to a sentence you would otherwise have assembled from three tools by hand, which is the point at which most people stop and the breakage sits.

What MCP is not

Four assumptions cause most of the confusion, and each one is cheap to correct.

Where the data lives, and who can read it

A protocol that reaches your real systems deserves a straight answer about boundaries, so here is askbowtie's.

Each site gets its own database. A connection is authenticated with an Authorization: Bearer token, and a token reaches the sites it owns and nothing else. Answers are joined at read time across the silos the protocol exposes, which is the part a single source reader cannot do: traffic joined to errors joined to conversions is a diagnosis, while any one of them alone is a shrug.

What askbowtie can see of your agent side is deliberately thin. The MCP activity tables record which tool was called, for which domain, by which user, and when. There is no transcript. The prompts you type and the answers you get back are not stored, because answering "which tools get used" never required them.

How to tell a deep server from a thin one

Once one server is connected the question becomes which others are worth adding, and a popularity ranking will not tell you. Two things will, and both are answerable from a server's own documentation before you install anything.

Does it keep running when you close the chat? A server that lives as a local process on your machine can only answer while you are there to ask. A hosted one is still collecting at 2am, which is the difference between finding out about an outage and being told about it.

Does it reach more than one source? The worked example above ends on a join: an error count and a conversion count meeting on the same page. Getting there took three reads, but only one server, because both numbers live in the same store. Against a separate analytics server and a separate error server, that last step is yours to do by hand, and by hand is where it usually stops.

There is a third thing worth checking that documentation rarely advertises: how carefully the tools are described. An agent picks a tool by reading its description and nothing else, so vague wording produces no error and no warning. It produces a server that gets called at the wrong moments, and an agent that quietly performs worse than it should.

Best MCP servers for your website answers the first two for the three servers that reach a live site, in one table that includes where askbowtie loses: it needs its own snippet installed, where GA4 is usually there already. It takes the third question separately, for the reason above.

Questions you can now answer

If the protocol is doing its job, these stop being research projects and become single questions:

Try it on your own site

The clearest first win is the site you already own. Add one script tag, the one carrying your data-token, so there is something to read, connect the server once, and then ask the messy question you would never phrase for a dashboard. The next pages in this hub cover which servers reach a live website and exactly how to wire one to Claude.