Publish Blog Posts With Claude or Codex Over MCP

A blog run through MCP works like this: you research and draft in the conversation you already use, the assistant writes the post to your site as a draft, you read it as a visitor would, and you publish when it is ready. The copying between a document and a CMS disappears. The writing does not. That still has to be yours, or it reads like everyone else's.

This post is part of our MCP guide, and it is also how the posts in that guide were made.

Why the blog is the best place to start

If you are new to working over MCP, start with the blog rather than the pages. A post is self-contained, it is a draft by default, and nobody sees it until you publish. You can try the whole loop, from reading the site to publishing, on something that cannot break the homepage.

It is also where the time savings are plainest. The slow part of blogging was never the writing. It was everything around it: formatting, finding the old post to link to, setting the title and description, picking tags, remembering the author field, checking the result on a phone, fixing a typo after publishing. All of that is tool calls now.

The workflow

1. Research where you already are

The assistant you use for research is the one that will write to the site, so the research does not need to move. Ask it to read your existing posts first, so it knows what you have already said and what to link to. In Beste, list_posts returns every post with its title, summary, tags and status, and get_page_markdown returns a post as text. The assistant reads your own blog before it writes for it.

For anything that changes, such as prices, plans or a tool's features, ask it to open the source page itself rather than rely on what it remembers. Every post in this guide was checked against the pages in its sources list in the month it was written.

2. Draft in the conversation, not in the site

Write the post with the assistant the way you would with an editor: an outline, a draft, your corrections, another draft. Keep the rules document in context so the voice holds. Do this before anything touches the site, because a conversation is a better place to argue about a paragraph than a CMS field.

A warning from experience: the assistant will produce a competent post from a title alone, and competent is the problem. It will sound like every other post on the topic. The parts worth reading are the ones only you could write, which is the point of the section on what stays yours below.

3. Write it to the site as a draft

When the draft is ready, the assistant creates the post. In Beste, create_post takes the title, summary, meta description, author, tags, read time, slug and the body in Markdown, and the post lands as a draft. Headings, lists, tables, images and links carry over. Drafts never reach the live site.

4. Read it as a visitor

Ask for the preview and read the post on a phone. Headings that looked fine in a text window wrap badly at 380 pixels. A table with five columns needs a second look. Fix by asking: "shorten the second heading", "turn that table into a list". write_post_body replaces the body with the corrected version, and the change can be undone if the new version is worse.

5. Publish, by name

Say which post to publish, and say publish. The assistant sets the post's status and publishes the site. In Beste, publishing is a separate tool that runs only on request, so a post cannot go live as a side effect of an edit.

A checklist before you say publish

We read every post against this list. The assistant can check most of it for you, and you check the rest:

Facts. Every price, date and plan name matches the source page, and the post says when it was checked.
Links. Internal links point to pages that exist. External links open the page the sentence describes.
Sources. A list at the bottom, one line per source.
Title and description. The meta description is between 120 and 160 characters and says what the reader gets.
Headings. They read as a table of contents on their own.
Author. Set, with a real person behind it.
Phone. Read on a phone at least once.

Updating posts after they are live

This is where the method pays off over time. Prices in a comparison post change. A tool you mentioned renames itself. A claim you made in March is wrong in October.

Over MCP, the update is one request: "open the comparison post, update the Framer price to the current pricing page, and update the checked line to this month." The assistant reads the post, changes the paragraph, and the change waits in the draft. We keep a "Checked in [month]" line in every post that quotes a price, and the assistant updates the month when it updates the price.

A simple rhythm that works: once a quarter, ask the assistant to list every post that quotes a price or a plan, open each source page, and report what changed. Fix what it finds, review, publish. It takes an hour for a blog of fifty posts, and it is the difference between a blog that ages and one that stays useful.

The same applies to internal links. When a new post is added to a guide, every post in that guide should link to it. Asking the assistant to "add the new post to the list at the bottom of each post in the handover guide" is one sentence and six edits.

Authors, tags and structure

A blog needs the boring fields filled every time, and this is where an agent beats a person:

Author. Set from a list, never left empty. A post without an author is a post without a byline, which matters for readers and for the entity structured data that ties the post to your business.
Tags. Consistent across posts, from a short list you keep in the rules document.
Title and meta description. Written for the search result, not copied from the first paragraph.
Slug. Short, with the main phrase in it, and never changed after publishing without a redirect.
Read time. Honest.

In Beste, each of these is a field on create_post and update_post, and create_author adds an author with a photo and a title. Beste adds BlogPosting structured data, the sitemap entry and the share image on publish, so the fields are the whole job.

Pillars, clusters and the links between them

If you organize a blog as pillar guides with cluster posts, an agent makes the structure easy to keep. Each cluster links to its pillar, the pillar lists every cluster, and clusters link sideways where they touch. That is a lot of links to maintain by hand and almost nothing over MCP, because the assistant can read every post in a guide and check the links in one pass. Ask it to "list every post in the MCP guide that does not link back to the guide" and fix what it finds.

Translations

A blog in more than one language needs each post written, not translated word for word, and the versions need to be linked so search engines know they are the same article. In Beste, create_post with translationOf links a new post to its original, and link_post_translations links existing ones, so the live site emits hreflang alternates for the pair. The voice rules per language are the same ones used for the pages, described in How We Built a Multilingual Website With MCP.

What not to use the agent for

An agent can produce fifty posts in an afternoon. Do not let it. Google's guide to optimizing for generative AI features in Search warns that creating separate content for every variation of a query, mainly to manipulate rankings, violates its scaled content abuse policy, and that a high number of pages does not make a site higher quality. The same guide says using generative AI tools to help create content is fine, as long as the work meets Google's normal standards.

So use the agent for the work around writing, and to sharpen your drafts. Do not use it to multiply thin posts.

What stays yours

The same Google guide is clear about what matters most: content that is unique, useful and based on what you actually know. It contrasts a first-hand account with a summary of what is already online, and says the first is what stands out. It also says no special files or markup are needed to appear in AI features in Search.

That is an argument for spending the time you save on the writing, not on the plumbing. What the agent cannot supply is the part that makes a post worth citing: the project you ran, the number you measured, the mistake you made and what you changed afterwards. Put those in. The research, the structure, the links and the fields are the agent's. The experience is yours.

How this works in Beste

The Beste blog is on every plan, with unlimited posts, on your own domain and in your own design. Over MCP, the tools cover the whole loop: list_posts, get_page_markdown, create_post, write_post_body, update_post, create_author, link_post_translations, preview_url and publish. Deleting a post takes a second, confirming call, so an assistant cannot remove one by accident. The built-in blog page has the details, and the MCP server page lists the tools. Before you start, write the rules the assistant will follow, using Writing Rules for Your Website Agent.