MCP Server for Wordstat: AI Checks Search Query Frequency Itself

⚡ The gist in 5 seconds

• An open-source MCP server has been released that pulls search volume data from Wordstat straight into an AI agent conversation.
• Installs locally, runs on Python, connects to Codex via .codex/config.toml and stdio.
• Read-only: four API methods, it doesn't write anything into ad campaigns.

🔍 What happened

An author under the nickname akulemin published a walkthrough and code in the INFOSTART.RU blog on Habr: a Python package tagged wordstat-v0.1.1, a repository called ai-marketing-integrations, directory packages/yandex-wordstat. The pain point was simple. The model would invent search phrases "out of thin air," and a marketer would then manually verify them in Wordstat. Now the agent calls the API itself and returns the numbers in the same chat.

Inside there are four tools, all read-only. wordstat_top — popular and related phrases over the last 30 days. wordstat_dynamics — frequency by day, week, and month. wordstat_regions_distribution — shares and interest index by region. wordstat_regions_tree — a region tree to get IDs for the next call. Installation goes like this: git clone --branch wordstat-v0.1.1 --depth 1 https://github.com/akulemin/ai-marketing-integrations, then a venv and pip install -e ".[dev]". The .env file holds WORDSTAT_AUTH_TYPE=api_key, WORDSTAT_API_KEY, and WORDSTAT_FOLDER_ID. The service account needs the search-api.webSearch.user role, and the key is created with the yc.search-api.execute scope. A build check is a one-liner: wordstat.exe top "marketing automation" --region 225 --limit 5. In the Codex config you specify the absolute path to wordstat-mcp.exe, cwd pointing to the package directory, and a list of allowed tools. No keys in the TOML — they stay in .env.

🧠 Our take

Over the past year, MCP has become something like a universal connector for tools. Instead of a plugin for every chat and every model, you get a single server that speaks stdio. Our assessment: this news isn't about Wordstat — it's about the fact that "going to fetch real data" has turned into an ordinary function call.

It gets more interesting. The author deliberately avoided building one do-everything tool and instead carved out four narrow ones — with predictable responses and the original phrases embedded. We believe that's the main feature. An agent that decides on its own how to gather search volumes from the web fails quietly; an agent that receives a list of phrases with numbers fails loudly and verifiably.

Who wins? Those whose marketing already lives in Codex or a similar client and who pay for Yandex Cloud. Who loses — per our hypothesis, services that sell manual keyword research as a separate job: part of that work is now covered by a script from a repository. But only part: the article explicitly states that selecting keywords for a campaign requires data about the product, the landing page, and the goals of the advertising.

⚠️ What we don't know

The text says nothing about Wordstat API rate limits, call costs, or response speed. One author, one repository, tests are mentioned but no figures are shown. The launch was verified via stdio on a test cache without HTTP calls — that's not the same as a real-world run on a live project. Region 225 in the example is Russia, but what the service returns for other regions and for rare phrases is something readers will have to check themselves.

Prediction: within a quarter, forks with write tools will appear — bids, negative keywords, ad group edits. You can check this via the fork list on GitHub.

Source: Habr / INFOSTART.RU