From AI Chat to Published Post: An AI Markdown Workflow
From AI Chat to Published Post
Most of my writing now starts inside an AI chat. I draft an outline with Claude, ask ChatGPT to expand a section, paste the result somewhere, clean it up, and eventually push it to a site. The messy part was always the middle: copying markdown out of a chat window, pasting it into an editor, losing track of which version was current. An AI markdown workflow built on MCP removes that copy-paste step entirely. The AI writes markdown, and the markdown lands in a real workspace without me touching the clipboard.
This post walks through the setup I actually use: connect an AI to edtr.md over MCP, let it save documents as I chat, then take one of those documents from draft to a merged pull request.
Why MCP Changes the Chat-to-File Loop
MCP (Model Context Protocol) is the piece that lets an AI assistant call tools on a server it trusts. edtr.md runs a remote MCP server at https://edtr.md/api/mcp. Once you connect it as a custom connector in claude.ai, ChatGPT, Claude Code, or Cursor, the assistant gets a save_document tool. From then on, when the model produces markdown, it can write that markdown straight into your workspace.
Connecting an AI is free. You can wire up every assistant you use and never pay to save a single file. For a step-by-step walkthrough of each client (Claude Desktop config, ChatGPT connector, Gemini CLI, Codex), see the dedicated guide on connecting ChatGPT, Claude, Gemini, and Codex over MCP.
Here is the shape of the connector setup in Claude Code, for reference:
claude mcp add --transport http edtrmd https://edtr.md/api/mcp
After that, a prompt like “save this draft to my Blog folder” writes a real .md file.
How save_document Decides What to Write
The behavior that makes this usable day to day is how save_document handles repeat saves. It does not spray a new file every time the AI touches the text. The rules are simple and predictable:
| What the AI does | What happens on disk |
|---|---|
| Saves under the same title again | Updates the existing file in place |
| Makes a small edit and re-saves | Overwrites in place, no new file |
| Produces a heavy rewrite | Creates a -v2 file next to the original |
| Saves under a brand new title | New file in the target folder |
Every save also keeps a snapshot in version history, so a rewrite you regret is recoverable. In practice this means I can iterate on the same draft across a dozen messages and end up with one clean file, not twelve near-duplicates cluttering the sidebar.
The End-to-End Run
Here is a full pass from idea to live page.
1. Draft in the chat. I ask Claude for a first version of a post. It writes the markdown and calls save_document. Within about thirty seconds the file shows up in my edtr.md sidebar. If I open the editor I can watch it appear.
2. Refine by talking. I ask for a tighter intro and a comparison table. The AI edits and re-saves. Same title, so it updates in place. The version history quietly stacks snapshots in case I want to roll back.
3. Tidy the frontmatter. This is where I switch from the chat to the workspace. The frontmatter panel reads the schema from your project config, including Astro content collection definitions, so it knows which fields the target site expects. Instead of hand-typing YAML and hoping I spelled pubDate right, I fill in typed fields and edit tags as chips. The panel writes valid frontmatter back into the file.
---
title: "From AI Chat to Published Post"
description: "An AI markdown workflow that ends in a pull request."
pubDate: "2026-07-14"
tags: ["ai", "markdown", "mcp"]
draft: false
---
4. Open a pull request. edtr.md syncs .md and .mdx two ways with GitHub and GitLab. When the draft is ready, one click opens a PR on an edtrmd/ branch. The pull request comes with Vercel or Netlify preview links, so a reviewer sees the rendered page, not just a diff.
5. Teammate merges, site deploys. Someone reviews the preview, merges the branch, and the deploy pipeline publishes. The post that started as a chat message is now a live page, and the git history shows a normal PR like any other change.
What Stays Manual, and Why That Is Fine
The AI handles drafting and saving. It does not open the pull request for you, and I would not want it to. The PR step is where a human decides the piece is actually ready, and where frontmatter gets a final check against the site schema. The split works: let the model do the fast, repetitive markdown production, keep a person on the publish decision.
Two-way sync matters here too. If a teammate fixes a typo directly in the repo, that change flows back into the workspace. The file is not a one-way export; it is the same document, mirrored.
Setting It Up Yourself
The whole loop rests on three things you configure once:
- Connect an AI over MCP. Add
https://edtr.md/api/mcpas a custom connector. The AI integrations overview lists every supported client and what each one can do. - Link a Git repo. Point a workspace folder at a GitHub or GitLab repository so
.mdand.mdxfiles sync both directions. - Point the frontmatter panel at your schema. If your site uses Astro content collections, the panel infers fields automatically; otherwise you define them once.
Connecting AI assistants and saving documents is free. Publishing pages and the collaboration links used in the PR flow are part of the Pro tier, but you can build and test the entire drafting side without that.
The Payoff
The reason I kept this setup is boring in a good way. Nothing surprising happens. The AI writes markdown, it appears in my workspace, I clean the frontmatter, I open a PR. No clipboard, no “which tab had the latest version,” no manual file creation. The chat is where the words come from, and the workspace is where they become a real, versioned, publishable document.
If you write with AI and publish to a static site or a docs repo, this closes the gap between the two. Connect an assistant, open the editor, and let the next draft save itself.