Almost everyone I know who works in SEO has run the same experiment in the past year. They connect Claude or ChatGPT to Google Search Console through an MCP server, ask why traffic dropped last month, and expect an analyst to answer. What comes back is a model that fetched 1,000 rows, added up the wrong column, never saw most of the long tail because it did not fit in the context window, and then recommended better meta descriptions with complete confidence.
I do not think the model is at fault. The fault is in how nearly every Search Console MCP is built: the server forwards raw API rows to the model and expects a language model to behave like a data warehouse. I have been building websites for 30 years and spent a good part of the last decade on sites with more than 50 million URLs, so I know what real Search Console analysis involves, and I know it does not fit in a chat context. That is why I built GSC Wizard, a Search Console MCP where the analysis runs on the server, in ClickHouse, and the model receives results it can reason about instead of rows it has to add up.
This post covers the architecture, the response design that turned out to matter once a model is the client, and why I think it is the best Search Console MCP you can use in 2026. I built it, so weigh that opinion accordingly.
Open the source of an average Search Console MCP server and you will find a tool named something like query_search_analytics that passes your parameters to Google's Search Analytics API and returns the JSON, usually with list_sites and inspect_url beside it. That works in a demo on a small blog. Pointed at a real site it runs into four problems, and none of them can be fixed with a better prompt.
The first is that the context window, and not the API, is the real bottleneck. A mid-sized ecommerce site has hundreds of thousands of query and page combinations a month. I measured the cost on my own server: a single call that returns 1,000 rows of query data takes roughly 58,000 tokens, which is more than the entire tool list. A wrapper therefore truncates, the model sees the head of the distribution, and everything it says about the tail is a guess.
The second is that language models are unreliable at aggregation. Ask one for an impression-weighted average position across 5,000 rows, or for the CTR change per URL between two periods, and the numbers look plausible while being wrong often enough that you cannot put them in a client report.
The third is that a wrapper inherits every limit of the API. Google caps how many rows you can retrieve, leaves anonymized queries out, and keeps only 16 months of history, so a year-over-year comparison across a 17-month window cannot be done at all.
The fourth is that a wrapper has no memory. Every question starts new API calls, the same data is downloaded again and again, and you spend both quota and tokens on rows you already had yesterday.
My conclusion was that an MCP server for Search Console should work as an analyst and not as a pipe.
In a wrapper the server fetches and the model computes. GSC Wizard reverses that division of labor, so the server computes and the model interprets.
Content decay shows the difference well. With a wrapper you would pull page data for two periods, put both in the context and ask the model to spot the pages that are declining. In GSC Wizard the find_decaying_content tool compares every page or query with its baseline period inside ClickHouse, sorts the losers into severe, moderate and mild, and returns them with the clicks lost and the likely pattern behind the loss, such as a ranking drop, a pruned long tail, falling demand or a lower CTR. The model receives a few dozen relevant rows where a wrapper would have handed it tens of thousands of raw ones.
That reversal pays off in four ways.
| What you get | Why it follows |
|---|---|
| Correct numbers | Aggregations, deltas, change points and forecasts are computed by a database, so the figures in a report are the figures in the data. |
| Complete analysis | The scan covers every stored row, long tail included, so the context window no longer decides what gets analyzed. |
| A small context footprint | Results replace raw rows, which makes answers faster and cheaper and leaves the model room to reason. |
| Chains that finish | Each tool returns a compact, structured result, so a model can run anomalies, change points, the pages behind them and an algorithm update check in a single conversation. |
The model is very good at the part that remains, which is deciding what to run next, connecting the findings and explaining them in plain language. It is poor at being a spreadsheet, so GSC Wizard no longer asks it to be one.
GSC Wizard began as my own internal tool. I was running Search Console analyses for enterprise clients and kept rebuilding the same pipeline to pull the data, store it, compute decay, cluster queries and compare periods, until building it once and properly became the cheaper option. The stack is boring where it can be and specialized where it has to be.
All 132 tools (100 reads and 32 writes) run through one pipeline, whether a call arrives over MCP or over the REST API, so authorization, validation and the audit log cannot drift apart between the two.
A property that you place in full storage is backfilled with everything Google still has, which is 16 months, and is then collected daily. From that moment the history lives in ClickHouse and keeps growing past Google's retention window, for up to ten years. Beside Search Console I added the sources SEOs end up cross-referencing anyway, which are Bing Webmaster Tools, Yandex Webmaster, GA4 (including referral traffic from LLMs), Google Merchant Center and IndexNow, so one conversation can combine them.
The lesson I did not expect came from a testing round in October 2026. Models do careful arithmetic on whatever payload they receive, so a fact that is missing from a response turns into a wrong answer and not into a question. Since then most of my work has gone into the response contract and not into adding tools, and I think these five rules apply to any MCP server that returns data.
limit rows cannot tell a complete answer from a clipped one and will report that your site has 100 queries. Every row tool therefore fetches one extra probe row and returns a pagination block that says whether more exists and what the next call is.coverage block carries the property totals for the same window, the share of clicks that the returned rows account for, and the share Google anonymizes and never lists. The model quotes totals from that block and never from summed rows.emptyBecause and what to call next in nextStep, so a count of zero is never the whole answer.
A Search Console audit used to cost me two days of exporting, cleaning, pivoting and charting for every angle. The same audit now runs inside one conversation, and the reason is where the work happens and not a clever prompt. The data is already in the warehouse, so a tool call is a local ClickHouse query instead of a paginated round trip to Google. Aggregating a year of query and page data is exactly the workload a columnar database was built for. And every step of the audit is a purpose-built tool that returns a finished analysis.
| Stage | What the model calls |
|---|---|
| Health and trend | get_site_summary ,detect_anomalies ,detect_change_points ,list_algo_updates |
| Visibility structure | get_position_distribution ,analyze_ctr_curve ,get_branded_performance |
| Content risks | find_decaying_content ,analyze_cannibalization ,analyze_query_shapes ,get_longtail_clusters |
| Opportunities | score_opportunities ,find_page_poaching_opportunities ,forecast_traffic |
| Technical | audit_onpage_seo ,inspect_url ,get_sitemap_performance ,get_core_web_vitals |
| Beyond Google | get_bing_query_stats ,get_yandex_query_stats ,get_ga4_llm_traffic ,get_merchant_listings_performance |
You can also skip the choreography and call generate_seo_report, which runs the whole suite in one go and hands the model a structured summary to explain.
During an audit the model does not crunch data. It reads ten compact, correct results, notices how they connect ("the decaying pages are the same ones that lose to a sibling URL, and it started in the week of the core update") and turns that into a story a client understands.
Most SEO tools are designed on a 5,000-page blog and sold to enterprises afterwards. I went the other way, because my reference point was the kind of site I have worked on for years: classifieds and marketplaces with tens of millions of URLs, dozens of country versions and several Search Console properties per brand.
Data volume is a database problem and not an MCP problem. Whether a property has 10,000 or 50 million URLs, the tool call looks the same and returns a result of the same size, because the heavy scan happens in the warehouse and not in a chat session.
The structure follows how large organizations think. Nobody at an enterprise talks about URLs. They talk about categories, templates, markets and brands, so you define content groups, topic clusters, tags and saved filters once and cut every analysis by them afterwards, which gives you performance per template, decay per market and cannibalization per topic. International setups rarely live in one property either, so cross-site summaries compare every ccTLD or subfolder property side by side.
The operational side is covered as well. You can load redirect maps and compare performance before and after a migration per URL pair, inspect URLs in bulk within Google's inspection quota, track the indexing status of priority URLs over time and push changes through IndexNow. Agencies and in-house teams can create shared reports with access control per client, so the output of a session does not have to be pasted into a slide deck.
The proof is in the usage. At the start of September 2026 GSC Wizard had just under 8,000 trial users with more than 161,000 connected Search Console properties, all on the same dedicated setup.
Each of these would be impossible, or at least unreliable, with a wrapper MCP.
The answers come back with actual numbers, computed over all the data.
GSC Wizard is a hosted, paid service. It is free for 7 days without a credit card, and plans start at €17 ($19) a month. If all you need is a handful of rows from a small site now and then, an open-source wrapper around the API will do the job and costs nothing. The difference shows once the site is large, the question needs history or arithmetic, or the answer goes into a report that a client will read.
If you judge a Search Console MCP by how quickly it returns raw rows, every option looks roughly the same. Judge it by whether the answer is correct, complete and delivered before your coffee gets cold, and the architecture decides everything. GSC Wizard rests on three bets: You can try it at gscwizard.com: connect Search Console, add GSC Wizard as a connector in Claude or ChatGPT (the setup guide covers both), and ask it the question you have been meaning to answer for months. I would love to hear what you find, and if it tells you something about your site that you did not expect, that is exactly the point.