Read Search Console, Bing Webmaster, GA4 and PageSpeed data through one self-hosted MCP server.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
Every SEO signal lives in its own walled garden with its own dashboard, its own API, and its own bullshit auth dance: Search Console over here, GA4 over there, Bing Webmaster somewhere else, plus Cloudflare, Clarity, PageSpeed, CrUX, GTM, and Bing's backlink data. Point an agent at your rankings and it drowns juggling eight consoles. Rankrat drags all of them behind one self-hosted service, so you tell an agent the outcome you want and it inspects, creates, updates, or rips out provider resources through a single surface β REST and MCP, no dashboards.
It's a rat, not a burglar. You hand it the provider accounts; those credentials
are the only authority it has. The resource lists in boundaries.json are
inventory and URL-containment data β not a second permission system pretending
to keep you safe. Rankrat writes by default; set RANKRAT_READ_ONLY=true and
every mutating route and tool disappears from discovery. That's the one switch.
It speaks MCP over stdio, MCP over Streamable HTTP at /mcp, and a FastAPI JSON
API under /v1/. Wrapper-managed HTTP gets a bearer; a hand-rolled loopback-only
launch can drop it if you know what you're doing.
Status: alpha. The API and tool surface can still move before 1.0 β minor releases may break things on purpose (documented), so pin an exact release if you need it to hold still.
| Area | What Rankrat exposes |
|---|---|
| Search Console analytics, inspection and sitemaps; GA4 inventory, historical and realtime reports, ecommerce, funnels, and audiences; Google Tag Manager containers, workspaces, tags, triggers, variables, versions, and publication; property, sitemap, indexing, ownership, onboarding, and rename writes | |
| Bing | Search, crawl, indexing, sitemap, backlink, quota, keyword, opportunity, cannibalization, site/submission, and safe content-submission operations |
| Performance | PageSpeed, Core Web Vitals, CrUX history, Microsoft Clarity insights, Cloudflare analytics, and isolated local Lighthouse audits |
| Site intelligence | Whole-site audits, schema eligibility, internal-link graphs, orphan pages, content opportunities, and cross-provider comparisons |
| Ownership and onboarding | Google/Bing checks, provider-neutral DNS verification through Cloudflare, and idempotent GA4/Search Console/Bing onboarding |
| Backlinks | Bing Webmaster backlink intelligence for configured sites |
| Monitoring and remediation | Persistent monitors and issue history, sitemap/URL resubmission, IndexNow, exact Cloudflare purges, finite cache templates, and managed edge redirects |
What the runtime advertises is what it does β no hidden endpoints. A read-only deployment drops every write from discovery; a writable one exposes onboarding alongside the rest. The whole list is the MCP tool catalog and the generated OpenAPI document.
Install the rankrat command, create the credentials for the providers you
want, then run it. Docker is the only runtime requirement.
Download the installer, read it, then run it β per-user (no root) or system-wide:
The mode auto-detects from who runs it; --user / --system force it and
--uninstall removes the command. This puts the rankrat wrapper β a readable
script that drives the published Docker images β on your PATH. Prefer to work
from a source checkout? Clone the repo and use ./rankrat or the make targets
instead; see Getting started.
Run setup. It lists every provider, you pick the ones you actually use, and it walks you through creating each credential β the exact console clicks for Google OAuth, the Bing Webmaster key, the Cloudflare token, the Clarity token β then hides every value you paste. No copying token permissions out of a README:
Configuring Google? Paste the one-line Desktop OAuth client JSON at the hidden prompt when setup asks β same as every other credential.
Setup validates account access β it does not submit URLs or create properties.
Your profile lives in ~/.config/rankrat; override it per launch with
rankrat --data-dir /absolute/path or RANKRAT_DATA_DIR for a separate profile
per account or workspace. Want to read the credential steps ahead of time, or
what each provider actually gives you? See
Providers and credentials. From a source checkout the setup
step is make setup.
From a source checkout: make run (stdio) and make run-http (HTTP over
Compose, attached).
rankrat setup pins both psyb0t/rankrat and psyb0t/rankrat-lighthouse to the
latest release tag β recorded, along with the HTTP port and read-only flag, in a
.env at your profile root β rather than tracking the moving :latest. rankrat upgrade re-pins the images to the newest release, pulls both, restarts a running
HTTP stack (reusing the recorded port and read-only flag), and removes the
superseded images; it leaves the port and read-only lines untouched. Pass
--rolling (or set RANKRAT_ROLLING=1) to use the moving :latest images for a
single run without touching the recorded pin. RANKRAT_IMAGE,
RANKRAT_LIGHTHOUSE_IMAGE, RANKRAT_HTTP_PORT, and RANKRAT_READ_ONLY still
override the recorded values per run.
To set the host settings once instead of per run, put them in a permanent host
env file at ~/.config/rankrat/.env (override the path with RANKRAT_ENV_FILE).
The wrapper reads it before selecting a profile, so it can set RANKRAT_DATA_DIR
(which profile to use) along with RANKRAT_READ_ONLY, RANKRAT_IMAGE,
RANKRAT_LIGHTHOUSE_IMAGE, RANKRAT_HTTP_PORT, RANKRAT_OAUTH_CALLBACK_PORT,
and RANKRAT_ROLLING. It only fills a variable that is unset or empty, so a
--data-dir flag or a real env var still overrides it. This is especially handy
for MCP launchers that run rankrat with a minimal environment and never see
your shell exports. It is separate from the per-profile .env: the host file
selects the profile and the host defaults, while a profile's .env pins that
profile's images, port, and read-only flag.
Over HTTP, MCP lives at http://127.0.0.1:8080/mcp and REST under /v1/; stdio
needs no port and no bearer. HTTP treats your data directory as its Compose
project β it drops a docker-compose.yml in there if one's missing and never
touches yours if it isn't. Under the hood that's two
long-lived services plus one one-shot volume initializer. The wrapper, plain
docker run, raw Compose, HTTP auth, and client wiring all live in
Transports and deployment.
Browser audits run in a separate psyb0t/rankrat-lighthouse image over a Unix
socket, and it never sees a single provider credential. rankrat stdio brings up
an ephemeral Lighthouse sidecar for the session β same capability as HTTP β and
tears it down on exit; the wrapper launches it host-side, so the app stays off the
Docker socket and reaches Lighthouse only over the socket. See Lighthouse.
RANKRAT_READ_ONLY=true removes write REST routes and MCP tools from runtime
discovery. It is the only capability switch.See Configuration and Security before enabling writes or exposing HTTP beyond loopback.
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/rankrat)<a href="https://allmcps.com/mcp/rankrat"><img src="https://allmcps.com/api/badge/rankrat?style=directory" alt="Rankrat on AllMCPs" /></a>