Wiring process around an MCP agent (so it does not ship SEO slop)

Jorge Rojas — Sun, 25 Oct 2026 02:10:52 +0000

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, what the human still owns, and why we refuse a publish tool. seodraft is the concrete case we built; the debate is the point.

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 a feature, not a missing checkbox.
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, not because wrapping MCP is trendy. The interesting question for this community 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 + 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. 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 a 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 not be one tool call away from overwriting the homepage.

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, not a style failure.
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, not an unsupervised content factory.

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. 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.

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.