We Counted 1,555 Public SEO MCP Servers on GitHub. One in Seven Passes Four Basic Maintenance Checks

An SEO agent has two weak points. One is the model, and everyone already worries about that. The other gets far less attention: the connector between the model and the data. MCP, the Model Context Protocol, is how Claude Code and similar tools reach Search Console, rank trackers and keyword databases. If that connector is stale, broken or careless with your credentials, a confident answer can rest on a bad foundation, and nothing in the chat window will show it.

The stakes are real. When Lily Ray tracked more than 220 sites publicly named as customers of AI content platforms, 54% had lost 30% or more of their peak organic traffic on third-party estimates. That is correlation, about content rather than connectors. Even so, it is a good reason to ask of any automated workflow: how would we know if this were failing?

So we started with the part anyone can inspect. We counted the public SEO MCP servers on GitHub and checked each one for basic signs that someone is looking after it.

A market that barely existed a year ago

We ran 36 GitHub searches on 4 and 5 November 2026 (terms such as "seo mcp", "search console mcp" and "rank tracking mcp"), which returned 3,385 distinct repositories. We kept those that name an SEO job and MCP in their name or description and show signs of being a server. That left 1,555. It is a working count rather than a perfect one: in a random hand-check of 50, 33 were clearly SEO MCP servers, 11 were broader marketing tools that include SEO, and 6 did not belong.

1,405 of them (90.4%) were created in 2026, and 585 (37.6%) in the last 90 days. October alone added 263. Building a connector has become so cheap, often with the help of the same agents it serves, that the supply now far exceeds anyone's ability to review it.

They cluster on the data SEOs want most, and repositories can count under more than one:

The 448 is the number to sit with. Search Console is a site owner's own first-party data, and hundreds of different people have written their own bridge to it.

Popular is not the same as looked after

The usual shortcut for judging a repository is its star count. Here it mostly tells you that nobody has looked: 1,041 repositories (66.9%) have no stars at all, and the median is zero. Only 24 have 100 or more, and the ten most-starred hold 73% of all the stars in the set.

Even at the top, a star is weak evidence. Researchers from Carnegie Mellon and elsewhere estimated six million suspected fake GitHub stars, and found that apart from phishing and malware, they mostly promote AI and LLM, blockchain and tool projects. We make no claim about any repository here. The point is only that a star count cannot carry much weight when your credentials are at stake.

So we looked at the files instead.

Four checks take a minute each and need no special skill: does the repository contain tests, does it run automated checks, does it have a licence you can actually rely on, and has anyone pushed to it in the last 30 days? Only 214 of the 1,555 (13.8%) pass all four. 442 (28.4%) have no tests, no automated checks and no licence.

Popular repositories do better, though not by as much as you would hope: two thirds of those with 100 or more stars contain tests, against 38.6% of those with fewer than five.

The time pattern is the most telling. 721 repositories (46.4%) received their last push within 24 hours of being created. Among the 970 that are more than 90 days old, 686 (70.7%) have not been pushed to in the last 90 days.

That needs a fair reading. A small connector can be finished. Quiet code isn't necessarily broken code, and a repository with no test folder may still work on the day you install it. But a connector sits between two things that do change: the API on one side and the agent client on the other. A connector nobody is watching will eventually return an error, or worse, something that looks like an answer.

What they ask for in return

1,187 READMEs (76.3%) mention an API key, token, OAuth or other credentials, and 907 (58.3%) show secrets being set through environment variables or a config file. That is normal for a tool that reads private data. It does mean that each install is a decision about who gets to hold the keys to your paid SEO data or your Search Console property.

Only 465 (29.9%) describe themselves as read-only anywhere in the description or README, and 23 describe working through a logged-in browser session rather than an official API. Neither figure proves anything about a specific repository, but both are things you would want to know before installing one.

Five questions before an agent gets your keys

1. Who publishes it? A vendor's own server, a company with a support address, and a stranger's weekend project carry different risks. Check the account, not only the name. 15 of the 17 repositories naming Semrush are not Semrush's.
2. Where do the numbers come from? An official API, a scraper and a logged-in session fail in different ways. A good README says which it uses.
3. Is anyone home? Look for a recent push, a closed issue and tests. Our four checks take a few minutes and already rule out six in seven.
4. What can it change? Start read-only. An agent that can only read can give you a bad recommendation, but it can't publish one.
5. How will you know it's wrong? Pick one number the agent reports and compare it by hand with the source, then do it again next month. We wrote up the guards we run on our own agent workflows after learning this the slow way.

A connector, and a way to check it

The same logic applies to any connector, a vendor's included, and that is the useful way to look at this one. The Semrush MCP server "provides AI agents with secure access to Semrush's public APIs" for clients including Claude, Claude Code, ChatGPT, Cursor and VS Code. Semrush hosts it, so there is no third-party code to install. OAuth is the default authentication, and each request uses API units, with availability depending on your plan. Semrush's documentation also carries the right warning: "AI responses may be incomplete or inaccurate, so always verify them." We have not used this integration ourselves; the descriptions here are Semrush's.

Then there are the checks, which is what turns a fast answer into a verified one.

Ground content plans in competitive data. Keyword Gap compares your keywords with up to four competitors' and lists the ones you are missing. If an agent proposes a content plan, this is the list to check it against, rather than taking the model's word for what competitors rank for.

Check technical claims against a crawl. Site Audit is a baseline for any audit an agent writes. If the agent says a page set has a problem, the crawl should show it too.

Find out whether the change worked. Position Tracking follows chosen keywords daily, so a change an agent recommended can be judged by what happened after it shipped. This is the plainest answer to "how would we know this failed?"

Track the AI answers too. Prompt Tracking, in the AI Visibility Toolkit, follows chosen prompts across AI platforms and records whether your brand was mentioned and which sources were cited. This is the AI search tracking that many custom agent workflows try to approximate.

Test market claims against traffic estimates. Agents are quick to size a market and name competitors. Traffic Analytics estimates a competitor's traffic and sources, and Market Overview, formerly Market Explorer, maps the players in a market. Both are in the Traffic & Market Toolkit, which is sold separately from Semrush One, and reaching this data through MCP needs a Trends API subscription.

Semrush One bundles the SEO Toolkit and the AI Visibility Toolkit, and the 7-day free trial is Semrush One's — the AI Visibility Toolkit has no free trial of its own. To try the verification side before paying, try Semrush One free for 7 days: its page offers "Unlimited access to all Semrush One tools" and notes "Offer available to new users only", checked on 5 November 2026. Those are Semrush's published terms, not something we tested; none of the data above came from a Semrush account.

Speed is cheap now. Knowing is not.

Anyone can build an SEO connector in a day, and our count suggests a great many people have, with nearly half never touched again after that first day. That is good news for choice, and it makes the review step more valuable. The teams that get the most from agents won't be the ones with the most connectors. They will be the ones who can say where each number came from and how they would know if it were wrong.

How the count was made

• Finding them: the GitHub repository search API, non-forks only, matching the name, description and topic tags, for 25 search terms. "seo mcp" alone exceeded the 1,000 results GitHub serves per query, so it was split by creation date, which made 36 searches in all. 3,385 distinct repositories, collected 4 to 5 November 2026.
• Keeping them (1,555): an SEO term in the name or description (such as SEO, SERP, Search Console, backlink, rank tracking, or a named SEO product) and MCP in the name or description, or an MCP topic tag plus a client configuration in the README, plus a sign of being a server in the README or name. Removed: lists, skills-only packs, and off-topic uses of the same words, such as note-taking "backlinks" and app-store optimisation. Hand-check of 50 at random: 33 clear, 11 adjacent, 6 out.
• Checks: stars, licence, dates and owner from the GitHub API. File lists from a metadata-only clone of every repository (no code was checked out or run). Tests = a test directory or a test-named file. Automated checks = a CI configuration such as .github/workflows. Licence = one GitHub can identify. Recent = a push within 30 days of 5 November 2026. READMEs were read for credential and read-only wording by pattern, so those two figures are approximate. "Published by that company" means the GitHub account name matches the company.
• What a repository count can't tell you: whether any connector works, returns correct data or is safe. We ran none of them. Private servers, hosted connectors with no public repository (Semrush's own server among them) and repositories deleted before our count are not included. A "push" can be any update, not only a code change. Tests may exist under names we did not match, and a test folder may hold nothing useful.

Written by Sohail Akhtar. The saved repository data and analysis scripts can be re-run.