▸ Read atomeve.dev/start.md and set up SEO Improver agent in my project.Runs a weekly ranking loop. It pulls current positions for your tracked keywords from DataForSEO, compares them to the previous run to show what moved, and finds the highest-leverage opportunities: keywords in striking distance of page one, titles that lose clicks they already earn, cannibalized pages, and pages that are decaying. For each one it inspects the ranking page in a real browser and hands back a specific, ready-to-apply change tied to the ranking evidence. The next week it checks whether last week's changes were made and whether positions responded, so recommendations compound instead of repeat.
It keeps the run read-only against your live site. If your blog lives on GitHub, it can go one step further and open a pull request with the highest-confidence changes for you to review and merge, so recommendations actually ship. It never pushes to your default branch and never merges.
DATAFORSEO_LOGIN and DATAFORSEO_PASSWORD.agent/instructions.md, set your domain, the keywords to track (or let it derive them from your ranked keywords), and target locale/device.owner/repo and the content path) in agent/instructions.md and provide GITHUB_TOKEN with write access. The agent then opens a review-ready pull request each run. Leave it unset to stay report-only, or wire your own publishing path if the blog is on a hosted CMS.Runs on a weekly schedule (agent/schedules/weekly.ts, Mondays 09:00). History accumulates under reports/seo-improver/, which is what makes the week-over-week diff work, so keep it around between runs.
The exact source npx atom-eve add installs — instructions, tools, and skills. Read it here, or copy any file straight into your project.
connections/dataforseo.tsimport { defineMcpClientConnection } from "eve/connections";
// DataForSEO ships a hosted MCP server, so the agent talks to it through a
// connection instead of a hand-rolled HTTP client.
//
// DataForSEO uses HTTP Basic auth (login:password), not a Bearer token. The
// `auth` field (and Vercel Connect via `@vercel/connect/eve`) only emits
// `Authorization: Bearer <token>`, so it can't express Basic auth. Instead we
// build the `Authorization: Basic ...` header ourselves and read the static
// credentials from env. This header callback runs at the connection layer at
// runtime on every target (eve and flue), and eve proxies the MCP calls with
// it injected, so the model never sees the credentials. Env is the real source
// for these static secrets here, not a flue-only fallback; `requiredEnv` in
// atom.json just declares them so the installer prompts for them.
export default defineMcpClientConnection({
url: "https://mcp.dataforseo.com/mcp",
description:
"DataForSEO rankings data: live SERP results by keyword/location, the domain's ranked keywords with position and search volume, and week-over-week position tracking for striking-distance and lost-position analysis.",
headers: {
Authorization: `Basic ${Buffer.from(
`${process.env.DATAFORSEO_LOGIN ?? ""}:${process.env.DATAFORSEO_PASSWORD ?? ""}`,
).toString("base64")}`,
},
});