The Best Search Console MCP Lets the Database Do the Math, Not the Model

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. Where the wrapper pattern breaks 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. Server computes, model interprets 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. The stack underneath 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. ClickHouse is the analytical core. Search Console data is a textbook columnar workload: billions of narrow rows (date, query, page, country, device, clicks, impressions, position) that are scanned and aggregated and never updated. The partition and sort keys follow the questions SEOs ask, which are per property, per date range and per page or query. The hardware is dedicated and not metered. The warehouse runs on a dedicated Hetzner machine with 256 GB of RAM and NVMe storage. My infrastructure cost is fixed and only grows with the number of properties or questions, which is what keeps the pricing predictable. The API and MCP layer are written in TypeScript, with Supabase for auth and account data. The MCP server is remote. There is nothing to install: you add the connector in Claude or ChatGPT, sign in with Google through OAuth, and your properties are there. Clients such as Claude Code, Cursor and Codex can use an API key with a read or a write scope instead. 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. Designing responses for a client that reads carefully 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. Truncation has to be visible. Row tools cap what a single call returns so that one request cannot flood the context. The cap is not the risky part, because silent truncation is: a model that receives exactly 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. Totals travel with the rows. A 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. An empty result explains itself. A tool that can come back empty says why in emptyBecause and what to call next in nextStep, so a count of zero is never the whole answer. Dates are optional. Every date range defaults to the last 28 settled days, and a window that reaches into days Search Console has not finished processing is flagged as partial where it would otherwise read low without warning. No tool depends on the model knowing today's date. The tool list has to fit the client. Some clients limit how many tools reach the model: VS Code sends at most 128 per request, and Cursor's documentation has put its limit at 40. Beside the full catalog I therefore serve a core profile of 25 tools on its own endpoint. An audit as a chain of tool calls 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. Built for large sites first 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. Prompts I use in client work Each of these would be impossible, or at least unreliable, with a wrapper MCP. "Run a full SEO audit on example.com and give me the five issues with the biggest traffic impact." "Which pages have been decaying for more than three months, and is another page on the site taking over their queries?" "Our traffic dropped in the second week of August. Was it an algorithm update, a technical issue or seasonality?" "Compare the old and new URLs after last month's migration and list the redirect pairs that lost more than 30% of their clicks." "Break down non-branded clicks by product category template and show which categories are gaining share." "Which of our pages get the most traffic from ChatGPT and Perplexity in GA4, and how do they rank in Google for the same topics?" "Compare all our country properties and tell me which markets underperform on CTR relative to their average position." The answers come back with actual numbers, computed over all the data. When a wrapper is enough 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. The bottom line 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: Analysis belongs on the server. Databases compute and models interpret. Your data should outlive Google's 16-month window. Store it once and query it for years. Enterprise scale is the default and not an upgrade. If it works for 50 million URLs, it works for your blog. 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.