The engineers who got through the hard migration are already busy with the next one, so the post about it never gets written, or it's written by someone who wasn't in the room. Handing the job to an AI writer doesn't fix that on its own. A model with no project context writes generic copy, and a model with too much context can put a client's details on a public page.
I'm Preetham Reddy, and at TechFabric we had both problems. Since 7 October our engineers have emailed post ideas to a writer agent we run, which asks questions and drafts the post. It started from an email and knew nothing about the project behind it, so engineers spent their replies explaining context their own tools already had.
Andrey Taran, one of our engineers, proposed the fix. His Claude agent already held his project's memory, and he wanted it to write the post. On 19 October we shipped an MCP server at www.techfabric.com/mcp. An engineer's own coding agent, with the repository already in context, reads our writing rules from it, runs the site's checks on its draft and files the draft under the engineer's byline, and only the engineer can publish it. Developers have told me it's quicker and friendlier than email.
Below: how the server is built, what the agent reads before it drafts, the 24 checks a draft has to pass, and why the agent can't publish.
Why the engineer's agent writes the draft
A post is only as good as the context behind it. Our hosted blog writer is careful, but everything it knows about a project arrives in an email, and an engineer writing an email at the end of a long day leaves out the detail that makes a post worth reading: the error message, the config value that fixed it, the order the steps had to run in.
A coding agent sitting in the engineer's repository already has all of that. It has read the code, the commit history, the notes and often weeks of conversation about why things were built the way they were. Asking it to draft the post moves the writing to where the knowledge already lives. We call the pattern bring your own agent. The engineer brings the agent and the context, and we bring the rules and the checks.
There's a cost side too. Drafting runs on the engineer's own Claude subscription, so the AI credits we pay for go to the parts only we can run: the checks, the editor and the preview build. The email route stays for anyone who'd rather write a few paragraphs and let our writer take it from there.
How the server is put together
There's one server, at www.techfabric.com/mcp, and it lives inside the same Cloudflare Worker that serves the site. It speaks Streamable HTTP on MCP revision 2026-07-28, built on version 2 of the official TypeScript SDK, and it's stateless. Every request builds a fresh server, with no session id and no initialize handshake to keep alive. Clients still on the 2025-11-25 revision, which today includes Claude Code and Claude Desktop, are served on the same URL.
Anyone can call the four read tools without signing in. They answer from an index the build writes on every deploy, so drafts, previews and noindex pages can't appear in a result, and no read call reaches a language model. The four write tools need a Microsoft sign-in in the techfabric.com tenant, and that sign-in is the line between a reader and an author. Readers and authors alike can open the editorial rules resource, and every draft a write tool files goes through the same checks every agent runs.
The sign-in is single-tenant Entra, with PKCE and a nonce. The server checks the ID token's signature against the tenant's keys, refuses guest accounts, requires an @techfabric.com address and then looks that address up on the blog's author list. It matches on the address alone and checks the list again on every call, so removing someone from the list cuts off their access at once. Access tokens last an hour and renew for 30 days.
An anonymous call to a write tool gets the step-up challenge from the MCP authorization spec, which tells the client exactly where to sign in and which scope it needs:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://www.techfabric.com/.well-known/oauth-protected-resource/mcp", scope="blog.write"
A token without blog.write gets a 403 with insufficient_scope. Sign-in is accepted from Claude Code and Claude's custom connectors (Claude Desktop and claude.ai). Codex, Cursor, VS Code and other clients can connect and read, but they can't sign in to write yet.
| Tool | Who can call it | What it does |
|---|---|---|
search |
Anyone | Finds posts, services, case studies, city pages and events |
get_page |
Anyone | Returns one published page as Markdown, with its FAQs |
list_posts |
Anyone | Lists blog posts by tag, author or date |
get_services |
Anyone | Lists every service and product page |
check_draft |
Signed-in authors | Runs the site's checks on a draft and files nothing |
submit_draft |
Signed-in authors | Files the post under the author's byline and builds a preview |
get_status |
Signed-in authors | Reports a draft's state, failing checks and links |
update_draft |
Signed-in authors | Saves a new version of the author's own draft |
The read tools matter more to authoring than they look. Before drafting, an agent can search what we've already published on the subject, read our own earlier posts to link them, and avoid writing the third post on a topic we covered last month.
What the agent reads before it writes
The first thing the agent reads is the editorial_rules resource at techfabric://editorial/rules. The server assembles it on request from the same editorial pack our hosted blog writer loads when it drafts an engineer's post. That pack holds our voice rules, the patterns that make text read as machine-written, how we write titles and headings, what a post needs to carry, when to draw a diagram, what we may claim and whose perspective a post takes. It also carries two skills (drafting an author's post and turning narrated structure into a table or diagram) and six behaviours, such as never inventing a fact and asking the author instead of guessing.
Client confidentiality comes first in that document. A coding agent working in a client repository has seen code, data and conversations that must never reach a public page. The rules tell it to name no client, schema, metric or internal system unless the client is approved for publication, and then only as far as the approval goes. Signed-in authors get the list of approved clients with each one's limits. An anonymous caller gets a shorter instruction to name no client at all.
Every agent we run loads the house rules through one loader, scripts/editorial.mjs. The blog writer, the browser editor, the follow-up agent and the SEO agents all read from it, and so does the MCP resource. When we change a rule, the next post an engineer's agent drafts follows it, with no prompt in anyone's dotfiles to update. The resource is cached for an hour, so a change reaches every agent within that hour.
The 24 checks a draft has to pass
check_draft is the browser editor's own Run checks, called from the agent. The server writes the draft to a scratch record, starts a Cloudflare Workflow, and that Workflow measures the draft and starts a GitHub Actions job that runs the site's gate script on the text. Each gate reports back as it finishes. A full run takes five to ten minutes, and every finding comes back with the exact passage it's about, so the agent fixes that sentence and checks again instead of redrafting the whole post.
The 24 items split into 9 draft items and 15 site gates. The draft items are deterministic: a captioned diagram, enough depth, a title and description that fit a search result, no leftover placeholders, images the site can show, no empty headings, at least three answered questions at the end, no paragraph cut off mid-sentence and no broken links. Of the 15 gates, 11 are code and 4 are read by Clef, the decision model on Cloudflare Workers AI.
| Gate | Read by | What it holds the draft to |
|---|---|---|
| humanizer | Code | Em dashes, banned words and other mechanical AI tells |
| voice | Code | No internal jargon in TechFabric's voice |
| quality | Clef | Each paragraph read for generic, hyped or apologetic writing |
| helpful | Clef | The whole post against Google's helpful-content questions |
| opening | Code | Real prose before the first heading |
| density | Code | An opening that reads easily |
| buyer | Clef | Whether the post's reader would understand the first screen |
| claims | Code | Partner-tier wording and certification claims we can't make |
| known-errors | Code | Mistakes that shipped once and must never ship again |
| diagrams | Code | A captioned Mermaid diagram that renders on the site |
| title | Code | A title that names its subject in one clause |
| meta | Code | A title and description that pass the search check |
| images | Code | Images served from the site |
| assets | Code | Image references that are well formed |
| covers | Clef | The rendered cover image, plus SVG rules |
The model-read gates fail closed. If Clef is down, a token is missing or our spend breaker has paused model calls, the gate reports that it couldn't run, and a run with an item that couldn't run is never a pass.
The governance comes from there being only one list of gates. The site build in npm run check, the hosted blog writer, the editor's Run checks, check_draft and the approve link in a preview email all run the gates in scripts/check-post.mjs, and each gate calls the check's own code instead of a copy of its rules. A test fails the build if the writer's list ever drifts from it.
So when we tighten a check because a bad sentence got through, the content agent's next explainer and an engineer's next MCP draft meet the stricter version on the same day.
Fact-checking stays with the author
Posts from our hosted writer go through a model fact-check against their sources before anyone sees them. Posts submitted through MCP don't. We decided on 19 October to leave the facts in an MCP post to the engineer, because they're writing about their own work and their agent can check every claim against the vendor's documentation and the code in front of it. A second model second-guessing an engineer's account of their own work is what we moved away from on 10 October, after one engineer's post was rewritten on every reply, and since then an engineer's own text is published as written.
The deterministic guardrails still run. The claims gate stops partner-tier wording we're not entitled to, and the known-errors registry stops factual mistakes we've already shipped once and corrected. Confidentiality is the one rule left to the agent and the author instead of a gate, which is why it opens the rules document and why the author reads every preview before it can go anywhere.
From submit to publish
By the time an agent calls submit_draft, check_draft has usually run all 24 checks and the agent has fixed each flagged passage. submit_draft files the post under the signed-in engineer's byline exactly as written. It sets the author, today's date in Phoenix and draft: true, adds a reading time at 225 words a minute if the post has none, and returns an id. The id is a hash of the submission, so an agent that retries after a timeout gets the same draft back instead of a second one.
After filing, the pipeline does the work an engineer shouldn't have to. It renders each Mermaid block to SVG in a headless Chromium with the site's font and palette, uploads images to our blog media bucket in R2, builds the site, commits the post to its own branch, opens a pull request and uploads a preview version of the Worker. Then it emails the author the preview, the editor link and an approve link. The approve link is left out while any draft item is still failing.
The agent follows the draft with get_status, or subscribes to techfabric://drafts/{id} and hears when the state, the preview or the latest check run changes. For revisions it calls update_draft with the whole new post and the base_sha from get_status. The save is refused if the draft changed since that sha or is open in the browser editor, so an agent can't overwrite a human's edit.
There's no publish tool. The author opens the editor link and chooses Run checks, and Publish needs a run that passed on exactly the saved text. A check_draft pass doesn't count, because it ran on a scratch copy, and any save after a run means running the checks again. We'd add a publish tool only after a few real posts have gone through this route and we've seen where it breaks.
Setting it up
In Claude Code, add the server once for every project:
claude mcp add --transport http --scope user techfabric https://www.techfabric.com/mcp
Then run /mcp, pick techfabric and choose Authenticate. A browser opens on a techfabric.com page that names the client asking for access, and the engineer signs in with their @techfabric.com Microsoft account. In Claude Desktop or claude.ai, the same URL goes in as a custom connector.
The prompt we give engineers to start from asks the agent to read the rules before it does anything else:
Read techfabric.com's editorial rules (the techfabric editorial_rules resource), then write a TechFabric blog post about how we <solved this problem or built this thing>. Draft only from what I actually did and what's in this project; never name a client the rules don't approve, and ask me for any fact you don't have instead of inventing it. Run check_draft and fix every finding, then submit it with submit_draft and give me the preview and editor links.
Signed-in authors get 600 calls an hour, with at most 20 new check runs, 6 submissions and 30 saves. Checking text that was already checked joins the earlier run and doesn't count again.
This post went through the same route. My agent drafted it in the techfabric-web repository, from the server's own code, ran check_draft, fixed what came back and filed it under my byline.
Frequently asked questions
Can an engineer's agent publish to techfabric.com through the MCP server?
No. The server has no publish tool, so an agent can check a draft and file it under its author's byline but can't make it live. The author publishes from the editor link once Run checks passes on the saved text, and anyone who isn't on the blog's author list can't reach the write tools at all.
Which coding agents can write drafts?
Claude Code and Claude's custom connectors in Claude Desktop and claude.ai can sign in and use the write tools today. Codex, Cursor, VS Code, Gemini CLI, Copilot CLI and OpenCode can connect and use the read tools without signing in, but the sign-in for writing only accepts Claude clients for now.
Does a model fact-check posts submitted through MCP?
No. Our hosted writer's fact-check doesn't run on MCP posts, because the engineer is writing about their own work and their agent can check each claim against vendor documentation and the code it has open. The deterministic gates still run on every draft, including the claims check and the known-errors registry, and publishing needs them to pass.
What stops an agent from putting client details into a post?
The editorial rules the agent reads first put client confidentiality above every other rule, and signed-in authors get the list of approved clients with the limits on each one. The author reads the preview before anything can be published, and a post that leaks a client is withdrawn.