If you write a technical blog as a side quest, you already know the pattern. You open Claude or Cursor, ask for a post, get something that looks finished, and then spend an hour deleting filler, inventing a keyword strategy you never measured, and wondering whether you just published the same intent as last month's article under a new title.
Developers are good at shipping code. Most of us are not SEO people. We still need a changelog, a how-to, or a post that answer engines can quote without embarrassment. The agent can write. What it usually lacks is process: a profile of the product, a calendar of topics, a list of facts you will stand behind, and a hard line between "draft ready" and "live on the blog".
That gap is why a lot of "AI SEO" tools sell you tokens or finished volume. Another design is possible: keep generation in the subscription you already pay for, and put the process in a remote MCP server the agent can call. This post is about that design choice for an MCP agent, what the human still owns, and why we refuse a publish tool. seodraft is the concrete case we built; the debate is the point. For our own SEO we use OpenSEO skills together with the OpenSEO MCP server, claude-seo to a lesser extent, and seodraft to manage quality and the editorial process.
The fork: sell tokens, or wrap the agent you already have
Most AI writing products put generation on their bill. You chat inside their UI, they call a model, and the meter runs on their side. Content factories go further: they sell finished posts, often with auto-publish into WordPress.
There is a third shape if your client already speaks MCP. The agent stays Claude, ChatGPT, Cursor, or Codex. A remote server exposes tools for planning, drafting, checking, and delivering a file. The server does not call a model. It holds state and rules. Calls do not add a per-token line from that product.
Tradeoffs are honest:
- If you will not connect an agent, nothing writes. There is no captive chat that "just works" without your subscription.
- If you want unattended auto-publish, this is the wrong architecture. Process without a publish tool is intentional.
- If you already live in Cursor or Claude Code, wiring process into tools you can list and call feels natural. If you do not, a hosted chat product may fit better.
We picked the third shape for seodraft because we are developers who already pay for agents. The interesting question is whether you want process in tools, or generation in someone else's meter.
What remote MCP changes in practice
An MCP server exposes tools an AI client can list and call. Local means a process on your machine. Remote means a URL.
For a content loop, remote plus OAuth is nicer than a long-lived local binary: nothing to keep alive, same rows as a browser UI, and a bearer token per request. Glama listed seodraft on its own, but it showed Unhealthy because its health check got a 401: our MCP requires an OAuth login. We fixed it by claiming the listing with another DNS TXT record and setting up an OAuth test profile with a test account, and it now shows Healthy. Streamable HTTP without a server session id means a dropped connection is just "send the next call". Stale writes can refuse with a version conflict instead of overwriting what you edited in the UI.
A minimal client entry looks like any other remote MCP URL:
{
"mcpServers": {
"content-process": {
"url": "https://example.com/mcp"
}
}
}
Auth discovery, dynamic client registration, and PKCE can all start from that URL. The first authenticated tool call is better proof of "connected" than a settings toggle.
None of that is SEO-specific. It is the same pattern as wrapping an issue tracker or a deploy API. The SEO part is which tools you expose and which ones you refuse to expose.
What the agent can drive, and what we leave out
Group tools by stage, the way you would group CLI subcommands:
Plan: topics, research, calendar.
Write: load a write skill, read a product profile and internal link graph, pick the next slot, upsert a post.
Review: run the rules check, list evidence the human accepted, mark ready to export.
Deliver: send a draft: true file to a git target, check delivery status.
There is no publish tool. Approval can mean "rules passed" and "file delivered as draft". Shipping to production stays in your CMS, your PR, or your hand. That split is intentional. An agent that can research and draft should stay one human yes away from overwriting the homepage. Eric Siu put the same boundary in a list of bots: "send, publish and spend stay behind a human yes". In our own demo run, the workflow stopped at READY: I did not call delivery or publish the article.
Optional SERP or volume data is another boundary. If the server never holds a shared vendor key, the human connects their own account (or lives with unmeasured estimates). Cost shows before a paid call. That is the same discipline you want for any tool that can spend money.
What the human still owns
Three decisions do not belong to the model:
- Evidence. The agent cites only numbers, cases, and lessons you accepted. Invented "studies show 73%" is a process failure. The current workflow saves the brief before the body and requires every evidence item in the brief to reach the article.
- Rules verdict. Checks are deterministic code: keyword placement, an answer under every H2, your own evidence, no filler list, cannibalization as a hard stop. Same draft, same verdict. After two failed redrafts the slot stops. No grinding until something slips through.
- Ship. Export Markdown, HTML, or a git draft. Nothing goes live until you move it.
If you skip those, you get the familiar blog of interchangeable posts that answer engines ignore and readers bounce from. If you keep them, the agent is a fast junior writer with a checklist. For the human-owned "never say" calls, see our note on human approval of AI content.
A concrete build (ours)
We wired this as seodraft's remote MCP server: Streamable HTTP, OAuth, dozens of tools in the stages above, no publish tool, optional DataForSEO on your own credentials. On September 27, 2026, seodraft went live in the official MCP Registry under the name app.seodraft/seodraft, version 1.0.0. The write skill the agent loads before drafting is public at seodraft.app/skill if you want to read the brief shape without connecting anything. How we ship that server into registries is a separate post: How to distribute an MCP server through registries.
That paragraph is the product mention. The rest of the post stands without it. You could rebuild the same boundaries on a private server for an internal docs site tomorrow.
Open questions for people wiring agents
I am curious how others draw the line:
- Do you let an agent open a PR, or only write files under
draft/? - Do you keep evidence in a DB, a markdown folder, or a Notion dump the model is allowed to invent from?
- When a draft fails the same rule twice, do you stop the slot or let the human override?
We stopped the slot and refused publish. That feels right for a public blog. It may be wrong for an internal changelog. Tell me where you land.
If you already pay for Claude, Cursor, or ChatGPT and want process around the agent without buying another token meter, try seodraft: the agent writes, the rules decide, and you approve before anything goes live.
