Your AI Should Publish While You Sleep: Building an MCP Pipeline That Blogs on a Schedule

(This one assumes you already did the hard part once: your site is live, your domain points at it, and publishing works. If you're still at "ChatGPT wrote me some HTML, now what," start with Create a Blog With AI, Then Own It: Publishing, RSS, and Updates Without a Site Builder first — this post builds directly on top of that publishing setup.)

Every post on this blog starts from the same place: Claude or ChatGPT wrote you a landing page, you shipped it, it works. And a one-off blog post is the same shape of problem. You open a chat, you prompt, you copy the markdown, you paste it into your publishing setup, you deploy. Done. That workflow is fine for post number one.

It is a terrible workflow for post number twenty.

Because the whole thing depends on you being the pipeline. You are the scheduler, the courier, and the deploy button. Miss a week and the blog goes quiet. The fix isn't a better prompt — it's removing yourself from the loop, except at the one step where you actually matter: deciding whether a draft is good enough to publish. That's what an MCP pipeline gets you. Here's how the pieces fit and where I'd put the human checkpoints.

What MCP actually buys you here

MCP — Model Context Protocol — is an open standard Anthropic introduced for connecting AI models to external tools and data sources. Instead of copy-pasting content between a chat window and your site, the model calls tools directly: read a file, write a file, hit an API, create a draft.

The difference sounds cosmetic until you run the one-off workflow three times. Then you notice what's actually happening: every session, you re-explain your site structure, your frontmatter format, your category list. The model has no memory of your blog. An MCP setup solves that by making your blog reachable — the model inspects your actual posts directory, sees your real frontmatter conventions, and writes output that matches what's already there instead of inventing a format it saw in training data.

That's the whole pitch in one sentence: the AI stops guessing what your blog looks like because it can look at it.

The three pieces of the pipeline

There are exactly three jobs in a self-publishing blog, and it helps to keep them separate even when one tool handles two of them.

1. The scheduler

Something has to kick off the run on a schedule — say, every Monday at 6am. This is the least glamorous piece and the one people overbuild. You do not need a workflow platform with a dashboard. A cron job on any machine you control does the job:

# Every Monday 6am, run the pipeline
0 6 * * 1 /home/you/blog-pipeline/run.sh

The script's job is narrow: start a Claude session with the right MCP servers attached, pass in a prompt that says "draft this week's post on topic N from the content queue," and hand the result to step two.

2. The agent with tool access

This is where MCP lives. When the scheduled run starts, the model isn't sitting in your chat history — it's a fresh session with a small set of tools:

Filesystem access to your blog's content directory, so it can read existing posts (style, structure, frontmatter) and write the new draft in the same format.
The content queue, which is honestly just a text file or a folder of one-line topic ideas you maintain. More on this below — it's the piece people skip and regret.
A draft mechanism — and here's the key design decision: the agent writes drafts, not published posts.

That last one is the load-bearing wall. Your pipeline should have two states in your content directory — drafts/ and posts/ — and the agent only ever writes to drafts/. If your publishing setup distinguishes draft from published (most static site and CMS setups can), use that. If it doesn't, a folder convention works fine.

3. The publisher

Publication can be as dumb as a deploy script that runs after you approve a draft, or as automated as a cron job that publishes anything sitting in an approved folder. Start with the dumb version. Approval-first means a hallucinated statistic or a broken frontmatter block ships only if you let it.

Where you still matter: the review gate

The biggest mistake in every "automate your blog" setup I've seen is making it fully autonomous. The failure mode isn't dramatic — it's drift. Post three is fine. Post eight has a subtly wrong frontmatter field. Post twelve confidently cites something that doesn't exist. Nobody notices until a reader does.

So the review gate is not optional, and it should be cheap to pass through, or you'll stop using the pipeline. My setup:

The scheduled run produces a draft and a one-paragraph summary of what it wrote and why.
That summary lands somewhere you already look — an email, a push notification, a commit on a branch.
You read the draft. Approve moves it to the publish folder; reject appends a note to the content queue explaining why, which teaches next week's run what to avoid.

The summary arriving in your inbox is doing more work than it looks like. "A draft is ready about X" is a two-second decision. "I should check whether the pipeline ran" is a task, and tasks you don't remember to do are how automated pipelines die.

The content queue is the real product

Here's the part nobody warns you about: an agent that can publish on schedule is worthless without a supply of things worth publishing. If you let the model pick topics freeform, you get the AI-blog genre — generic listicles about topics adjacent to yours, technically competent, unmistakably filler.

The queue fixes this. It's a simple file where you drop topic ideas as they occur to you — questions customers asked this week, a take you have about your industry, a follow-up to something you already published. Twenty entries in the queue is four months of weekly posts that sound like they came from someone who actually does your work, because the topics came from someone who does.

The agent takes the next queue item each run, writes it, and marks it consumed. You refill the queue whenever inspiration strikes — batched, whenever you feel like it. That's the actual division of labor: you supply judgment in bulk, the machine supplies regularity.

Prompting the scheduled run

The prompt your cron job passes to the agent is a one-time investment that pays off every week. It should encode your conventions, not hope the model infers them:

Read the last 5 posts in posts/ to match voice and formatting.
Take topic 1 from queue.txt. Do not invent statistics or sources;
if a claim needs a citation and you don't have one, flag it in
the draft summary instead of writing it. Write the draft to
drafts/YYYY-MM-DD-slug.md using the exact frontmatter format of
existing posts. Do not publish. Do not modify anything in posts/.
End your run with a 3-sentence summary for the review email.

Two details worth stealing: the "do not invent statistics" line, and the constraint against touching posts/. Agents with filesystem access are eager helpers — an unsandboxed "fix this typo while you're in there" will happily rewrite your archive. Scope the write access tight. Drafts folder, full stop.

A realistic first version

If you're building this today, resist the urge to design for scale. The version I'd ship first:

One cron job, one shell script, one MCP-enabled Claude session.
Filesystem MCP server scoped to your blog directory.
Drafts folder + queue.txt + a review email.
Publishing stays manual until the drafts are consistently good — then automate the last step.

Total build time is an evening, not a weekend. And the first thing you'll learn from running it is which part of your editorial judgment was actually irreplaceable (for me: the queue) and which parts were just courier work you can happily never do again.

The goal was never a blog that writes itself. It's a blog where the machine handles the publishing cadence and you handle the only thing that makes it worth reading — and you only ever touch it in twenty-minute chunks, on your schedule, instead of pasting markdown into a terminal at 11pm because you promised yourself you'd post this week.