What Waild MCP does: an AI SEO tool that lives inside Claude
Most AI SEO tools are one of two things: a dashboard you visit, or a language model you hope is right. Waild MCP is neither. It is an MCP server — a set of tools Claude can call mid-conversation — that connects the AI assistant you already write with to live search data: keyword research, SERP analysis, competitor and backlink intelligence, on-page audits, content briefs, and a grading gate that measures every draft against the pages that actually rank in Google search results. The premise is simple: AI content only helps your SEO when it is based on what search engines currently reward, and only an AI tool with live data can know that. This page walks the whole surface, grouped by the seven jobs it does, with the genuine numbers from recorded sessions at each step — so you can judge the tool by its outputs, not its adjectives. (New to the protocol itself? Start with what is an MCP server?)
Research: size the market before writing a word
Every SEO strategy starts with search volume data and search intent. Ask Claude whether a market exists
and it calls keyword_overview, which returns each keyword's monthly volume,
cost-per-click, intent classification, and keyword difficulty in one compact row. In the recorded
research session we asked about our own market: “ai seo” draws 8,100 US searches a month at
difficulty 52 — too hard for a new domain — while “ai seo tools” brings 2,400 searches at
difficulty 10 with commercial intent and a $41 cost-per-click, a fight worth picking.
That is the core of AI-assisted keyword research: many candidate keywords in,
relevant and winnable ones out, minutes instead of a day in spreadsheets.
A second call, serp_question_map, harvests what searchers actually ask around a
keyword: the People-Also-Ask tree, related searches, and long-tail questions, each tagged with
intent and a suggested role (FAQ entry or H2). On “ai seo tools” it returned twenty
question-shaped headings and long-tails — “is surfer seo legit”, “surfer seo alternative”,
“best AI SEO tools for small businesses” — the whole SERP's vocabulary orbits one incumbent —
plus the fact that no featured snippet was live. That is a content angle and a
position-zero opportunity, found in seconds.
The research layer runs deeper when you need it: keyword suggestions and related keywords,
SERP-overlap clustering (cluster_keywords_by_serp) that decides whether a set of
keywords needs one page or several, topical maps (topic_cluster_plan) that lay out
pillar-and-spoke architectures with internal links, Google Trends, and search-intent
classification for any keyword list. We used it on this very page: before writing, we pulled the
keyword “ai seo tools” — 2,400 US searches a month, difficulty 10, commercial intent. Real
research, eating its own cooking.
Write: a content brief from the live SERP, not from memory
The writing layer is grounded in the first rule of SEO content: never draft from imagination. The
build_content_brief tool reads the top-ranking pages for a keyword and compresses
them into a writer-ready brief — search intent and funnel stage, the word-count band of the
pages that rank (25th percentile, median, 75th), an outline that separates must-cover sections
from differentiators, term targets with recommended usage counts, the questions to answer, the
character targets and slug for your meta tags, and a featured-snippet instruction when position
zero is open.
One thing the brief deliberately does not do is write your copy. It hands over the raw material for the title and description — the keyword exactly as people search it, the character targets, and the titles of the pages that actually rank right now — and Claude writes them, in the language of the page. That is a correction, not a feature we skipped. Earlier versions filled in a title and description from English patterns, so a Finnish keyword came back wearing an English headline. Templates cannot write in a language they have never been given; the model in the conversation can, and it has the ranking titles in front of it as examples of what that market rewards. The same rule now covers page titles in a cluster plan, link anchor text, and the FAQ heading: the server supplies the evidence and the targets, you write the words.
The recorded session shows the brief for “seo mcp server”, our own entry keyword: a 1,380-word median target (competitors range 953 to 2,962), 50 terms with counts, the sections every winner covers, and a concrete snippet play — “no featured snippet is live yet; answer the query in a single 40–60-word paragraph under an H2 phrased as the question.” Claude drafts against that brief inside the same conversation. No copy-pasting between a research tab, a spreadsheet, and a writing app; the content workflow is the chat.
Two more tools back the drafting stage. term_coverage_target extracts the shared
vocabulary of the ranking pages — the terms Google's winners all use — with per-term counts and
heading placement. And competitor_content_teardown reverse-engineers a specific
ranking URL into a match-and-beat outline: its structure, term consensus, and the subtopics it
misses. The shape of the consensus, never the wording.
Before Claude writes a word, one more tool makes sure the draft will carry what no model can
invent — your own first-hand experience. build_content_brief and the gap tools emit a
short list of pointed author_questions drawn straight from the analysis: which common
advice you disagree with, what happened when you actually did the thing, what numbers or examples
you have that the ranking pages lack. Claude asks you those instead of fabricating a persona, and
it never re-asks what you have already told it — an experience bank remembers your answers per
project. The payoff is enforced at the gate: ship_check checks that real author input
is present and genuinely used in the draft, and one carrying none of it is presumed slop. This
author-input loop is deploying owner-first.
Grade: the quality gate that refuses slop
This is the part other AI SEO software does not have, and it is the reason AI content from this
workflow ranks better than AI content from a bare chat window. Every draft goes through
grade_draft, which scores it 0–100 against the live SERP: term coverage with
per-term status, word count measured against the competitor band, readability, and a
prose-quality report that counts AI-tell phrases per 1,000 words and flags structural tells like
over-signposting.
The recorded session shows what happens to a lazy draft. A 122-word first attempt at “seo mcp server” — an article about our own product — scored 13 out of 100: 43 missing terms, word count measured against a 1,380-word bar, 155.7 AI-cliché hits per 1,000 words, and “in conclusion,” “cutting-edge,” and “unlock” flagged by name. It did not ship. The loop — rewrite, re-grade, repeat — continues until the draft clears the target score and reads like a person wrote it. For comparison, our own MCP explainer guide went through the same gate and shipped at 86/100 with 0.5 AI-tells per 1,000 words.
Above grading sits ship_check, a single readiness verdict that checks structure,
coverage, information gain, prose quality, and fact verification, and returns the exact next
action for every failed gate. There is also critique_draft, which sends your
finished draft to a panel of three independent models server-side and hands back their
prioritized notes — quoted line, concrete fix, why — so you do the final rewrite yourself with
three editors' reads in hand, not a blind machine rewrite — and audit_draft_url,
which grades a live or staged page the same way before you publish, without leaving the chat. The point of all of it: optimization scores alone
do not decide. Content that is thin, off-intent, mechanically optimized without substance, or
template-flavored gets bounced regardless.
Those tools each grade one page. content_distinctiveness_check looks across your
whole published corpus at once, and catches the failure the per-page graders cannot see: the
optimization loop quietly pulls every article toward the same signature words, the same
scaffolding phrases, and the same skeleton, until your own house style hardens into a tic and
your writing becomes the slop. It measures that self-repetition — signature words you lean on
page after page, phrases that start to appear on their own, whole articles built to the same
template — and reports it as a nudge to vary, never a hard block, so a brand keeps one voice
without writing the same page twice.
Maintain: the cheapest rankings you will ever get
Every fact the server fetches lands in a shared cache, and the maintenance tools read from it at
no API cost. quick_wins finds your pages sitting in positions 4–20 — one edit from
page one — and ranks them by expected return, each with a concrete lever.
content_decay_scan watches ranking history accrue and queues pages that are losing
ground, with the right action for each: refresh, consolidate, or redirect.
detect_cannibalization catches keywords where two of your URLs split equity and
names the keeper. internal_link_suggestions proposes specific links from your
related pages into a target page, with varied anchor text.
Maintenance is the least glamorous part of SEO and often the highest-return one: refreshing an existing page frequently outperforms publishing a new one, and these tools make that the default move rather than an afterthought. Because they run over cached data, re-checking costs nothing — a maintenance sweep is free after the research that built the cache.
And the loop no longer ends at estimates. Connect your own Google Search Console — a one-time service-account grant in the Search Console settings, or simply paste a performance export if you would rather hand over no credential at all — and the same maintain tools switch to ground truth (deploying owner-first behind the analytics pack). Decay scans fire on your real clicks and impressions, quick wins show measured demand next to the estimate, and cannibalization checks display the actual click split between your competing pages. The first-party layer also answers questions no third-party index can: which queries you already earn impressions for but never wrote a page about, which pages Google never shows at all, the exact day traffic broke and whether demand, rankings, or the snippet caused it, and whether the article you shipped last week is being seen yet. Umami web analytics connects the same way, so search reality and on-site behavior sit in one conversation.
On top of that store sits a receipts layer no other Search Console integration we surveyed offers. Because the workspace already records what you did — briefs built, plan items published, links won, pages edited — the server can answer "did that change work?" with a weekday-normalized before/after comparison around your own change event, labeled honestly (improved, flat, or declined — never a fabricated experiment), and flagged whenever a Google incident or reporting change overlaps the window. A brief's promised term targets are stored when the brief is built and measured against the queries the published page actually earned. The anonymized share of your demand — impressions Google shows but never attributes to a query — is trended instead of ignored. Your sitemap is read directly, so pages Google has never shown even once stop hiding. And an opt-in canary re-inspects your top pages on a nightly drip and speaks up only on transitions: a page dropping out of the index, a canonical flip, a fresh soft-404, or an edit Google still has not re-crawled.
Compete: know the fight before you pick it
The competitive layer answers the question founders actually ask: should I even try?
In the recorded session we asked it about our own head keyword: who actually ranks for
“ai seo tools”, and how strong is the #1? domain_rank_overview on the real
incumbent (rankability.com — the giants only appear inside the AI overview and other people's
listicles): 844 US keywords worth roughly 101,500 monthly organic visits, 59 of them at #1.
backlinks_summary: 11,770 backlinks across 2,661 referring domains — against our
own 15. That one call also returns the profile's spam score and how many of its links are
declared paid or user-generated, so a big profile and a clean one stop being the same claim,
and the numbers land in the cached domain profile — asking again costs nothing. The honest
conclusion follows — you do not beat that head-on, you route around it through niche keywords
the incumbent cannot own.
Routing around is what keyword_winnability_score is for. Before any article gets
written, it compares the real link bar of the top-ten pages against your domain's authority and
returns a verdict: winnable, stretch, or unrealistic. It also says whether that verdict's own
number deserves your trust. The link bar is a median, and a median can describe no page in the
SERP: our recorded reading for “ai seo tools” ran from one referring domain to 1,458. So the
score classifies the shape of the top ten — uniform, mixed, or top-heavy — counts the thin
slots a median hides, and states in one line what that bar does and does not cover.
The rest of the layer fills in the map —
competitor domain discovery, keyword intersections (terms they rank for and you don't),
content_gap_roadmap for a prioritized list of pages to build or upgrade, full
backlink profiles with anchors and gap analysis, and on-page audits of any URL.
Build authority: link building that persists between sessions
Winnability verdicts often end with the same instruction: this keyword needs more authority
first. The link-building layer is how you act on that. link_prospect_scan is one
prospecting engine with four modes — domains that link to your competitors but not to you,
domains whose links to you were lost (reclamation), live linkers of competitors' dead pages
(the replacement pitch), and resource pages ranking for your topics. Every candidate comes
back deduped, spam-gated, and scored on domain rank, spam, traffic, and topical fit, with the
pitch evidence attached: the dead URL, the lost link's anchor, which competitors the domain
links to. The scan is a paid fan-out that runs for minutes, so it returns a job handle
rather than blocking: you poll it, and the prospects — and the campaign save, if you asked
for one — land when it finishes. unlinked_mentions_finder adds the warmest class of all — pages that
already mention your brand but never linked, each carrying the mention snippet for a
personal ask. Strictly white-hat: the tools refuse to model paid links, link farms, or
exchanges, and nothing is ever auto-sent.
We ran the pipeline on our own site the day it shipped — waild.fi, at the time a brand-new domain with 15 referring domains, 12 of them nofollow. Instead of staring at that thin profile, the workflow reads the niche: it pulled the live SERP for the product's own keyword, took the top-ranking comparable product, and harvested its referring domains — the sites that demonstrably link to things like ours. After bulk rank and spam scoring, the output was an easiest-first plan: six clean niche directories to submit to that day, four tool-roundup blogs worth a personal pitch, and four candidates the spam gate rejected by name (one scored spam 78 — a listing there would hurt, not help). That is the difference between a link dump and a prospect list — the Links demo replays the recorded session.
Then the part every other approach loses: link_campaign_tracker keeps campaign
state in your workspace between sessions — every prospect with its status
(prospect → qualified → contacted → replied → linked), contact, pitch angle, and asset. A
verify action checks your live referring domains and flips a row to “linked”
the moment a pitch actually lands; a report action tells you the win rate per
tactic, so the next campaign starts from evidence about what works in your niche. Without
stored state, an assistant re-prospects from scratch every conversation; with it, link
building becomes a campaign you run, not a report you re-buy.
Campaigns stay separate when you run several sites. The domains worth pitching overlap
heavily between properties — Reddit, Quora and Medium belong to almost every campaign — so
prospects are keyed per campaign, not per domain: each one keeps its own pitch, asset and
status, and updating one never edits another. When a domain you are adding is already in
play elsewhere, the response says so rather than quietly merging the rows. An
update_prospects action applies one change across a campaign, so re-tagging
fifty rows with a new asset is one call rather than fifty.
Plan: marketing decisions that persist between sessions
The newest layer applies the same discipline to the marketing plan itself. Ask a bare
assistant to plan your marketing and it improvises a fresh, generic strategy every
conversation. Waild MCP stores the plan instead. A workspace holds
subjects — each product or client, with its own domain, market, and brand
voice — and marketing_plan keeps plans per subject, so “create a plan for
product X” and “what do I do this week for product Y” stop colliding. The weekly
question is answered by a due-date query against the stored plan, never by
re-strategizing from scratch.
The store is deliberately opinionated about the failure mode that kills the most products: marketing built on demand nobody verified. It refuses to create a plan without demand evidence — real search volume, a read of the live SERP, a winnability score — recorded with the plan. Channel choice follows the Bullseye procedure: brainstorm all nineteen traction channels, run two or three cheap bounded tests, concentrate on the one that works. The ordering rules live server-side, and the hard ones are enforced, not suggested — a paid-ads plan item is refused outright when the product’s customer lifetime value cannot clear realistic ad costs. Every plan item is a decision, not a task: the channel and why, the audience, the evidence behind it, the seasonality window, a success metric declared up front, and the tool that executes it. Cadence is derived from the hours per week you actually have, and the store flags any week booked past that capacity — aspirational calendars are abandoned calendars.
The newest planning tool puts real dates on those decisions. campaign_calendar
pulls five years of Google Trends data per topic in your market, works out each topic's
seasonal shape, and schedules publication ahead of the demand peak — seasonal
content needs months of lead time to rank (published research puts the window at three to
six months, and the server shortens it for easier keywords and stronger domains). It is
also honest about young markets: when we ran it on waild.fi's own niche, it scheduled ten
articles by priority and issued no seasonal dates at all — no curve in this niche has a
twice-observed peak yet, and one spiked September is an event, not a season; the
seasonality evidence is stored on each item, and a later re-run can re-time it once the
pattern repeats (one cheap curve fetch per topic). Topics
with no real seasonal shape are scheduled by priority into whatever capacity your declared
hours support, and the same run lays down the maintenance layer: a decay scan
every quarter and an annual review date for each high-value page you name. It refuses to
invent a plan of its own — it only schedules into a plan that already passed the demand
gate, so the calendar inherits every refusal above. Preview first, commit when it looks
right; trend curves are cached, so re-planning costs nothing.
Launches get the same honesty. A real launch is a 50–120 hour multi-week project, not a
date on a calendar — and that is exactly the preparation first-time founders skip. The
launch_plan action expands a launch date into dated, phased plan items
(positioning, channel prep, warmup, launch day, follow-through), shows you which weeks it
collides with your publishing cadence, and refuses a launch date that leaves too little
runway — suggesting the earliest workable one instead. The advice is dated on purpose:
the Product Hunt day-of-week tradeoff it serves carries a verified-as-of stamp and its
source's conflict of interest, and it will tell you what it will not promise — launch-day
signup numbers, which no honest source can give you.
Distribute: we don't write your posts — your Claude does
A page that ranks still has to be seen. The distribution vertical holds that job to the same anti-slop bar as the writing, under one deliberate rule: we don't write your posts. Your Claude does — with our research, your voice, and a gate that says no. It is the same call we made on the article side, where a blind judge panel preferred a draft its own model rewrote from critique notes over one a server-side model rewrote wholesale. The assistant in your project already knows the product, the reader, and how you sound; a stranger model working from a digest does not. So the server stopped writing and started advising.
social_post_advice is that research step. It reduces the article you wrote to
an anchored ledger of its real claims, runs a small jury of independent models over it, and
returns a selection rather than copy: which claims travel to social and which
don't, the questions readers ask about the topic (pulled from the live SERP), and per
platform a post-or-skip call with the claim to lead with, the traps to avoid, and the
mechanical constraints (length band, hook, hashtag count, and where the link goes). The
writing boundary is enforced in code rather than by good intentions: anything the advice
quotes has to be verbatim text from your own article, everything else is an instruction,
and there is no sample post to paste. Name a workspace subject and the advice is shaped by
that subject's stored brand voice and your own first-hand material; leave it out and
nothing from your workspace is read at all. An article carrying fewer than three concrete
claims is refused outright, with what's missing named — advice over nothing is slop.
find_social_threads answers the other half of distribution: where the
conversation already is. It reads the SERP for your keyword and returns the live
discussions (Reddit, Quora, Stack Exchange, and the local-language forums that rank in your
market), each scored on two separate 0–100 axes, because they answer different questions:
visibility, how prominently Google already shows the thread, and liveness, whether the
conversation is still moving. A years-old thread at position 1 and a three-hour-old thread
at position 9 are opposite opportunities, and a single blended number hides which one
you're looking at. What makes it usable is what it admits. Every thread reports
how it was read: through a platform API credential where one is connected,
through the page parser, from text you pasted in yourself, or only from Google's snippet
— and the snippet is Google's own, which is often the thread's best answer anyway. A
thread behind a login wall still shows up, ranked and carrying both Google's snippet and
the reason it could not be read, instead of being quietly dropped — and nothing gets
contribution advice unless it
was genuinely read, because no model can reason about a discussion nobody has seen. Walls
are remembered, so the same blocked page is never paid for twice. If a thread matters to
you, open it in your own browser and paste it back: it gets the same full analysis as any
other. The community floor is not negotiable either: no karma, vote-timing, or alt-account
tactics can survive into any output, on Reddit and Quora the default is to answer in the
thread rather than drop a link, and every thread carries the same reminder to read the
room's rules first.
grade_social_post is the gate. Hand it one post, or a pack of up to 4 in a
single call, and it returns a 0–100 score, a ranked fix list with stable ids, and a
ship-or-no-ship verdict in the post's language. Three layers run: a deterministic lint
(length band, hook placement, hashtag and emoji density, link placement, engagement-bait),
a grounding check, then a judge panel where information gain and a natural human voice are
hard gates — a slick, perfectly formatted post that says nothing does not ship.
The grounding check is the one to know about: every number and every quotation in the post
has to trace back to a claim you passed in, or to a figure derivable from the numbers
inside a single claim. A statistic that came from nowhere does not ship, and that verdict
has no override: you can vouch for a fact from elsewhere in your project, but the vouching
comes back on the record as yours. The revise loop runs on which fixes you haven't
addressed yet, never on chasing a number, and the server deliberately won't tell you the
passing score, because a published target turns writing into optimizing for the grader. At
3 passes the verdict is final.
social_serp_presence answers the question that comes before all of them:
which platforms already own Google's results for your keywords — Reddit and forum threads,
TikTok and Shorts, YouTube. We ran it on “seo mcp server.” Reddit ranked for 4 of our 5
head terms, at position 1 on two of them. That is exactly why the plan's first social move
is a genuine, non-promotional Reddit post rather than a LinkedIn broadcast. Link handling
travels with the advice: on LinkedIn the link belongs in the first comment and on X in a
self-reply, because a post carrying an in-body external link is measurably suppressed on
both. Presence data
is cached, so re-checking a keyword set costs nothing, and the posting stays yours. Nothing
is ever published on your behalf.
Get cited by AI answers: the GEO layer
Ranking is no longer the whole game. A rising share of searches end inside an AI answer —
Google's AI Overview, Google's AI Mode, ChatGPT, Perplexity — where the engine writes the
reply and cites a handful of sources. The GEO layer is about being one of those sources. It is
the newest layer and rolls out owner-first behind the AI-search pack, the same deliberate path
every vertical here took — the citability sub-score below is already live everywhere;
the answer-surface tools are enabling on the owner instance first.
It reads the AI answer surfaces directly rather than guessing at them.
ai_overview_presence takes your keyword set and reports who Google's AI Overview
cites across it: a ranked share-of-citation table, which keywords trigger an AI answer at
all, and — if you pass your domain — whether you are in the cited set. It is cache-first,
like the rest of the server, so re-checking a keyword set costs nothing.
serp_google_ai_mode reads the actual AI Mode answer for a single query and the
sources behind it, so you can see what the engine already says before you write against it.
Grading learned the same lesson. Every grade_draft now carries a
geo block: an advisory citability sub-score that asks whether a draft is
structured to be quoted by an AI answer — does it answer the question directly near
the top, does it carry attributed statistics, named-source quotes, and outbound citations,
are its sections self-contained enough to be lifted as a chunk. The signals with real
peer-reviewed backing carry the most weight; the rest are labelled as the heuristics they
are. Crucially, the score saturates: piling on stats and quotes cannot run it to
100, because the point is grounded substance, not stuffing. It is advisory, never a ship
gate, and it sits downstream of fact-checking — a missing statistic is never a licence to
invent one.
track_ai_visibility is the longitudinal layer: give it a brand, a set of
buyer-language prompts, and the engines to ask (Google AI Mode plus, optionally,
ChatGPT/Gemini/Claude), and it records who each engine mentions and cites, run over run.
Because those calls are slow and paid, it never runs inline — it hands back a run id and
settles the answers in the background, then ai_visibility_report rolls them up
into a mention rate, your citation share, and a competitor comparison. It is honest about
what it measures: an AI answer is generated fresh each time, so a single reading is a
snapshot, not a verdict — the report frames run-to-run change as directional and tells you
when a zero could mean “not cited” versus “the search step didn't run.” It shows you who is
cited and whether you are; working out why the cited pages win is the next step, not
this one.
Where it fits in your SEO stack
A fair question for any AI SEO tool: which jobs does it replace, and which does it leave to the rest of your SEO software? The honest map of where it can help, capability by capability:
Technical SEO — page-level, on demand. on_page_instant_pages
audits any URL on your website for the on-page basics search engines care about: title and meta description,
heading structure, structured data, internal links, load metrics. on_page_lighthouse
runs a full Lighthouse report when you need Core Web Vitals. What it is not, today, is a
scheduled full-site crawler that watches thousands of URLs — for large sites' continuous
technical SEO
monitoring, a dedicated crawler is still the better tool, and we would rather tell you that here
than let you find out later.
Rank tracking — history that accrues, not a dashboard. Every time Claude fetches your ranked keywords, the positions land in the cache as ranking history, and a delta mode lets you track what moved since the last fetch in one call. Position changes feed the decay scans and quick-wins analysis directly. There is no standalone dashboard with daily email alerts; you ask in chat, and the answer is based on real position data, not memory.
Traffic estimation. Every ranked keyword carries an estimated traffic value, so “how much organic traffic is that website's content getting, and from which pages?” is a tool call. Good enough to size a competitor or prioritize a topic; it’s an estimate, and we label it as one.
Content creation — in the chat, publish anywhere. The server does not push content to your CMS. You create the blog post, landing page, or comparison article with Claude in the conversation, graded and ready; you publish it wherever your website lives. No platform lock-in, no auto-publishing you did not ask for.
AI search visibility — shipping now, owner-first. A growing slice of discovery
happens inside AI search: Google's AI Overviews, Google's AI Mode, chat assistants. The
citability sub-score on every grade_draft is live today. The tools that read the
answer surfaces directly — who AI Overview and AI Mode cite, and brand-visibility tracking
across engines — are built and deploying behind the AI-search pack, owner-first per our rollout
policy, so they light up on the owner instance first and reach the customer surface
deliberately. Even then it is not a fully automated always-on monitor with alerts; tracking is
run-based and job-settled. The honest map above still holds: the pages that rank in classic
organic results are the pages AI Overviews tend to cite, so the ranking work feeds the citation
work.
Platforms. Built and tested with Claude first. MCP is an open standard — OpenAI's ChatGPT and Google's Gemini adopted it in 2025 — so users of any MCP-compatible assistant can connect the same server and get the same tools.
What this looks like in practice
A hundred and five tools are live today, but the count is not the point — the point is that they compose into one content marketing workflow. Keyword research flows into a content brief, the brief into a draft, the draft into the grade loop, the shipped page into the maintenance queue, and every call feeds a cache that makes the next one cheaper. Search metrics change every day; with the cache, checking them again is free. The data covers any Google market — location and language are parameters on every call — so a Finnish bakery and a US SaaS both pull real local keyword, SERP, and backlink data. The language-intelligence layer (discovery matching and the repetition/distinctiveness checks) is best-verified for English and major European languages; non-Latin scripts may work but are less certain.
If you want the honest comparison against the other ways to do AI-assisted SEO — raw API wrappers, SEO content editors, generic AI writing — that is its own page. And if you want to see these tools against real problems rather than grouped by job, read how it helps.