SEOMonster puts 70 SEO tools inside the assistant you already use

An MCP server, not a dashboard

SEOMonster is described as a local, user-credential-driven MCP server for SEO workflows over Google Search Console, GA4, PageSpeed Insights and Cloudflare, and the read-first, open source framing is in the project description. The tagline in the README is that you do not learn another SEO dashboard, you just ask.

The mechanism is the Model Context Protocol. SEOMonster is a stdio MCP server: your AI host launches it, it calls Google, Cloudflare and the AI engines with your credentials, and it returns a consistent JSON envelope that the assistant reads back to you in plain language. The diagram in the documentation shows the same shape, with the assistant in the middle, SEOMonster talking to Search Console and GA4, PageSpeed and CrUX, Cloudflare and IndexNow, and optionally the AI engines and the SERP.

That distinction matters for what you get. There is no report to configure and no page to learn, because the interface is a conversation. The tool list runs to 70 across Search Console, GA4, AI and GEO tracking, keyword discovery, content, PageSpeed and CrUX, Cloudflare, IndexNow, technical SEO and schema, and every one of them returns the same result envelope and is driven by your own credentials.

The project is published on PyPI as seo-monster, so the command is uvx seo-monster, while the import package is seo_mcp. The name seo-mcp is kept as a dev and local alias.

The MCP config is four lines

The quickstart gives the configuration for any MCP client by hand, and it is as small as an MCP configuration gets:

{
  "mcpServers": {
    "seomonster": { "command": "uvx", "args": ["seo-monster"] }
  }
}

There are also one-click install buttons in the README for Cursor and for VS Code, and the VS Code one encodes the same uvx and seo-monster pair.

After the config there is a one-time Google sign-in step, run once as uvx --from seo-monster seo-monster auth, and then the documentation asks you to call the system_status tool to confirm what is connected. That first call is worth taking seriously, because it is the tool that reports which services are configured and reachable, the Google auth method and scopes, whether destructive mode is on, the full tool catalog and the list of registered prompts.

The requirements differ by path. For the .mcpb bundle path in Claude Desktop, you need Claude Desktop on macOS or Windows, and the bundle declares Python 3.11 as a runtime that Claude Desktop sets up for you, with no prior uv install needed. For the uvx path used by Cursor, Cline, Codex and advanced Claude Desktop, you need Python 3.11 or newer plus uv, which provides uvx.

One detail will bite anyone configuring a GUI client. The documentation says to find the absolute path to uvx with which uvx, because GUI hosts do not read your shell profile, so MCP configs need the full path.

Reads always work, writes need a gate and a confirm token

The safety model is the most carefully specified part of the project, and it is worth reading closely before you connect anything.

Reads always work. The two routine writes, sitemap submit and indexing request, are on by default. The Cloudflare write tools, which cover cache purge, redirects, settings and managed robots.txt, are gated behind the SEO_MCP_ALLOW_DESTRUCTIVE environment variable, and the riskier ones also need a per-call confirm token.

That is a sensible ladder. A tool that only reads cannot damage anything, so it needs no ceremony. A tool that tells Google to index a URL is routine. A tool that purges a cache or rewrites redirects on a live site is not, so it takes two independent confirmations, one at the environment level and one in the call itself.

The credential story is the other half. The package ships zero secrets, with every credential resolved at runtime from your own environment or config file, and the project description says nothing is sent to any third party. The data flows from your machine to Google, Cloudflare and the AI engines with your own credentials.

The tool catalogue groups the reads usefully too. gsc_list_properties reports the properties the credentials can see, with permission level and a derived writable flag that is true for siteOwner and siteFullUser. gsc_search_analytics is described as the workhorse, giving clicks, impressions, CTR and position by dimensions, date range, filters and data_state, with gsc_top_queries and gsc_top_pages as convenience top-N wrappers and gsc_compare_periods for a current versus prior window with per-key deltas.

The questions it is built to answer

The README frames the product as a set of questions you would ask an assistant, with a table of what happens for each. Asking what to write about next surfaces near-ranking topics from your own Search Console demand, described as positions 8 to 20 with real demand, ranked by opportunity, with the option to draft the brief. Asking whether a page is ready to publish runs the technical SEO and structured data checks before you ship.

Asking to get something indexed nudges Google through the Indexing API and Bing and Yandex through IndexNow. Asking whether a change actually moved rankings returns a before and after attribution against a matched control group, with a confidence interval rather than a guess. And asking whether ChatGPT is recommending you or your competitors tracks your brand's share of voice across the AI answer engines.

Those last two are the differentiators. A before and after comparison without a control group is the classic way to claim credit for a change that was really seasonality, and the tool takes the comparison seriously enough to name a matched control group and a confidence interval. The AI share of voice question is newer, and the release history shows it arriving with the v0.9.2 tag, described as Discovery and AI/GEO, in June 2026.

The server also publishes thirteen named workflow prompts, so the common sequences are available as named entries rather than only as individual tool calls.

A lean dependency list, and an alpha classification

The implementation choices are deliberately small. The project describes itself as lean: standard library plus the mcp SDK plus the Google client libraries, with PageSpeed and Cloudflare riding on urllib so there is no extra HTTP dependency. The manifest confirms it, with dependencies on mcp, google-api-python-client, google-auth, google-auth-oauthlib and google-analytics-data, and requires-python of 3.11 or newer.

The console entry points are set up so the PyPI name and the command match, with both seo-monster and seo-mcp mapping to the same server entry point:

name = "seo-monster"
seo-monster = "seo_mcp.server:main"
seo-mcp = "seo_mcp.server:main"

The classifiers call the maturity level plainly, with Development Status set to 3, Alpha, and the intended audience as Developers. That matters when you are choosing what to put in front of a client, and it is more honest than a beta label on a tool that writes to production Cloudflare accounts.

The development extras are pytest, pytest-asyncio and ruff, and the repository carries a uv.lock, a CHANGELOG, a CONTRIBUTING guide, a DESIGN document, a PRIVACY document, a .mcp.json, a .mcpbignore for the bundle packaging, a server.json, a manifest.json and a .cursor-plugin directory. The badge row in the README reports 575 passing tests, and the last push was on 2026-10-18.

v0.9.3 and a hotfix for fresh installs

The release history tells you where the project actually is. The newest tag is v0.9.3 from 2026-08-29, and its release name is unusually specific: hotfix, fresh installs work again. Before that came v0.9.2 from 2026-06-20, described as Discovery and AI/GEO, and v0.8.2 from 2026-06-02, which added cf_managed_robots for managed robots.txt and Content-Signals control.

A hotfix named for broken fresh installs is the kind of release note worth pausing on, because an install path that works for the author and fails for a new user is a packaging bug, and the fact that it was needed at all suggests the .mcpb bundle and uvx paths have not always agreed with each other. The requirements section is candid about that split, describing two separate paths with different prerequisites.

The version numbering is still pre-1.0 and the classifier says alpha, so treat the tool names and the JSON envelope as something that may move between releases. The presence of a CHANGELOG and the detail in the release names suggest the maintainers are documenting the breaking parts, which is the thing to actually read when you upgrade.

The MIT licence and the open source framing mean you can read the code that decides what gets sent to Google on your behalf, which for a tool holding Search Console and Cloudflare credentials is a reasonable baseline rather than a reassurance.

Editorial conclusion

Adopt SEOMonster if you already work inside an AI coding or chat assistant and want your own Search Console, analytics and PageSpeed data to be queryable in plain English, without opening another dashboard. Do not adopt it if your team does not use an MCP client, since the whole interface is tool calls rather than a user interface, and treat the Cloudflare write tools with care even with the gate enabled. Before you install, check three things: that you can run uvx and can give the MCP config an absolute path to it, since GUI hosts do not read your shell profile, that you know which Google account will authorise the requests and with which scopes, and that SEO_MCP_ALLOW_DESTRUCTIVE stays unset until you have read what each write tool touches.

Frequently asked questions

Official sources

1. avansaber/seo-monster on GitHub
2. License: MIT
3. Project website
4. README
5. Releases