What 42,270 measured monthly searches for MCP actually contain

We build an MCP gateway. That means we have to answer "where is the demand for MCP tooling" with
numbers instead of instinct — and when we finally measured it, the shape of the answer was not what
the topic's noise suggests. This is that measurement, with the method attached so anyone can repeat
it and disagree with our reading.

Why we measured instead of guessing

The MCP ecosystem produces a lot of content and very little demand data. Every week brings another
"awesome MCP servers" list, another protocol explainer, another launch post. What none of them carry is
the number that decides what to write next: how many people search for a given phrase in a month, and
how hard the results page for it is to enter.

We had a second reason to care. Our own pages were indexed, our sitemap was clean, and our Search
Console still showed almost no non-branded impressions. When that happens, the useful question is not
"is our prose good" but "does anyone search for this at all, and with what words". A demand
measurement answers both at once.

The method, so the numbers can be checked

The pool comes from paid keyword data, not estimate tables scraped from a free tool:

• 73 phrases were screened: seed terms around the protocol itself, the client/server vocabulary, the transports, the comparison phrasings ("mcp vs api"), and the adjacent infrastructure terms our product lives among (agent memory, agentic RAG, streamable HTTP).
• Volumes and difficulty came from measured requests against the keyword APIs we already pay for, with the location pinned to the United States (location code 2840) so the numbers do not mix markets.
• 48 of the 73 cleared 50 searches/month. Those 48 were then clustered by search-result overlap: fetch the top 10 results for each phrase, and group phrases whose result sets substantially coincide. That is the only honest way to decide whether two phrases belong on one page or two.
• Snapshot date: 21 September 2026. Every number below is from that single day, which matters — see the limits section at the end.

Finding 1: the pool is small and top-heavy

The 73 phrases sum to 42,270 searches per month. One phrasing carries more than a quarter of it:

Two readings follow, and they point in opposite directions. The optimistic one: there is a real
audience — 42,000 searches a month is not a hobbyist niche. The pessimistic one: the top three
phrases are 47.6% of it, and those three are the name of the thing. People searching "model
context protocol" and "mcp protocol" are not looking for a vendor; they are looking for the definition,
which is exactly the query an encyclopaedia and a documentation site answer for free.

Finding 2: difficulty runs opposite to volume

Difficulty here is a 0–100 estimate of how hard the first page is to enter. Sort the pool by volume
and a pattern appears — the big phrases are defended, and the usable ones sit in the middle:

The two phrases with the lowest difficulty in the whole table are also two of the most specific:
"mcp vs api" compares two architectures, and "streamable http" names one transport that MCP
standardised. Both are the kind of query a reader has after learning what MCP is, and both are
answerable by anyone who has actually shipped the thing rather than read the specification.

That asymmetry is the practical finding: the demand that a new entrant can realistically win is
not the demand that looks biggest. Chasing the 12,100 phrase means competing with the protocol's
own documentation; answering the 12-difficulty phrase means writing something only an implementer
can write.

Finding 3: the demand is fragmented, not one topic

This was the surprise. We expected the 48 phrases to collapse into a handful of topical clusters, the
way "cheap flights" and "low cost flights" belong together. Instead, clustering the live result pages
turned 48 phrases into 43 clusters — with only 4 merges and 11 adjacent pairs across the whole set.

Translation: for MCP, almost every phrase owns its own result page. "mcp spec" and "mcp
specification" are not the same query if the results pages disagree; "mcp tools" and "mcp servers" sit
next to each other without merging. The topic looks like one huge subject from the outside and
behaves like a mosaic of small ones from the inside.

This has a direct consequence for anyone planning content here, and it is the opposite of the usual
advice to build one comprehensive pillar page. A single page cannot be the canonical answer to 43
different result pages. What works is a small centre per phrase family — the protocol overview, the
transport comparison, the client-configuration walkthrough — each one narrow enough to actually match
its result page, and each one linking to its neighbours so that a reader who lands on any of them can
reach the rest. Our own overview of the protocol's actors, lifecycle and transports is written to that
shape, rather than to a keyword count.

Finding 4: publishing is not the same as being found

The last piece of the measurement is not about search demand at all; it is about what our own site
saw while we were publishing into this pool. In the four weeks ending 22 September 2026, our Search
Console recorded 54 impressions and 7 clicks — and every one of them was a branded query. Not one
of the non-branded phrases in the table above produced an impression during that window.

That is worth stating plainly, because it is the number that disciplines the rest: a pool of 42,270
monthly searches, fifty-odd published articles, and a non-branded impression count of zero. Demand
being real does not mean demand is reachable; the pages existed before the audience did, and Google has
to decide to serve them before any of the arithmetic in this article matters.

The same period's edge logs add a useful counterweight: of the page reads recorded at our CDN in one
week, 282 carried AI-crawler user agents and 144 carried search-crawler user agents. Treat that as a
signal rather than a measurement — a user agent is a claim, not an identity, and machine files like
robots.txt inflate both numbers unless they are filtered out. The direction is still informative:
agents are reading this material earlier and more often than search engines are.

What this changed in our own content pipeline

Three things, all of them reversible if the next snapshot disagrees:

1. We stopped measuring success in pages and started measuring it in phrase families covered, which is the unit the clustering says actually exists.
2. We publish a cluster as a batch — one centre page on the head phrasing, members on the long tails — instead of one page at a time. A member page that links to siblings which do not exist yet is a broken link, and a centre page with no members is a page nobody reaches from anywhere.
3. We kept the measurement in the repository next to the content, so the next round can diff against it instead of re-deriving it from memory.

What this does not prove

The honest list, because a demand table invites more confidence than it earns:

• It is one market (United States) on one day. Volumes move; a phrase that was 1,900 in September may be 600 by December, and the difficulty of a result page moves faster than its volume.
• The volumes are advertiser-side estimates. A phrase with no advertiser interest reports nothing, which is not the same as no demand — several protocol phrases returned no data at all and were excluded rather than guessed.
• Two terms belong to a different protocol (A2A) that shares the audience; we kept it in the pool because the comparison queries are real, not because it is MCP.
• 43 clusters from 48 phrases is a floor, not a truth. Clustering depends on the result pages of a given day; phrase pairs that did not overlap in September can merge in October.
• Our Search Console window is short and small. 54 impressions is a sample that can only tell us the order of magnitude, and it cannot distinguish "the pages are wrong" from "the pages are new".

The map, not the territory

If the useful summary is one paragraph long, it is this: for MCP the measurable demand is real but
concentrated in a handful of definitional queries, the entry price is lowest exactly where the
audience is most specific, and the topic fragments into far more result pages than its vocabulary
suggests. Plan accordingly — a few narrow pages that answer a phrase completely, linked into a
neighbourhood, will outperform one broad page that answers nothing precisely.

The pool, the clustering and the diffable snapshots stay where the content lives. If you want the
starting point rather than the summary, the protocol's own mechanics are documented in our
MCP overview, and the
published-server side is collected in the
server list.

Disclosure: this measurement was assembled and written with AI assistance from our own paid keyword
requests and Search Console exports; the numbers are quoted from those files rather than re-typed.