Our engineers are focused on solving problems for our clients, and they'll never have enough time to sit down and write articles about all the work they do day to day, even though those articles would play an immense role in showing what TechFabric can do and in educating other enthusiastic readers.
The fix we landed on would work for any engineering team whose best work never reaches its website. Engineers now write those articles from the coding agent they already use, such as Claude Code or Codex, which already holds the context of the problem they solved. The post comes out more accurate, in fewer rounds, and the agent runs it through our checks and publishes it once the engineer says yes.
Below: why we moved the writing out of email, how the MCP server on our site works, the checks every draft passes, and how an engineer publishes from their own coding agent.
From email briefs to the engineer's own agent
To make it easy for our engineers to document and publish all the amazing things they're doing with AI and Databricks, we designed and built a suite of AI agents that can be triggered through email. When engineers email a brief of what they're looking for, TechFabric's content agents kick off, write a post, run through all the checks and generate a preview link for them to read, edit and approve.
But this process had many flaws. The agent didn't always have all the context it needed to write the article the engineer intended. Engineers had to go back and forth several times over email, supplying the information the agent needed to complete the article with all the checks passing (we have 24 checks). The whole process was taking longer than we would've liked.
So, instead of emailing an agent, we've made techfabric.com agentic and available to agents, so they can draft, request a preview and publish. We built an MCP server that any AI agent harness can reach. Now engineers can bring their own harness and start writing articles from the agent harness they're already using, without switching between the browser and other tools.
This has made the publishing process very simple and easy to use, and it gets us the most bang for the buck. Since the techfabric.com MCP server can be added directly to coding harnesses, the agent has full access to the context of the problem an engineer is solving (or has solved), and it can write a far more accurate post. The error message, the config value that fixed it and the order the steps had to run in are already in the repository the agent is sitting in, so nobody has to type them into an email at the end of a long day.
It also reduces our costs. Drafting, and most of the checking, runs on the tokens of the engineers' coding-harness subscriptions instead of API credits we buy through our AI gateway. Our gateway credits now go mainly to the judged checks, which run once on the final text.
We call this pattern Bring Your Own Agents (BYOA). Engineers bring their agents and the context, and we bring the rules and the checks. 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 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 seven 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.
Any MCP client can sign in, whether that's Claude Code, Codex, Cursor, VS Code, Fabric Agents or Claude's custom connectors in Claude Desktop and claude.ai. Before the sign-in, a techfabric.com page names the app asking for access and where its access goes. Then the engineer signs in with Microsoft. The server checks the ID token's signature against the tenant's keys, refuses guest accounts, requires an @techfabric.com address and looks that address up on the blog's author list. It 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"
| 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 |
get_brief |
Signed-in authors | Today's topic for a scheduled daily draft |
lint_draft |
Signed-in authors | Runs the rule-based checks in about a second, with no model |
check_draft |
Signed-in authors | Runs the full checks, our judge included, on the saved draft |
submit_draft |
Signed-in authors | Files the post under the author's byline and builds a preview |
update_draft |
Signed-in authors | Saves a new version of the author's own draft |
get_status |
Signed-in authors | Reports a draft's state, failing checks and links |
publish_draft |
Signed-in authors | Publishes the author's own draft once they confirm |
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 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 the drafting skill, the behaviours we hold every agent to (never invent a fact, ask the author instead of guessing), the frontmatter a post needs and the workflow below, step by step.
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 the rules without that list.
Every agent we run loads the house rules from that one pack, 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.
Lint first, then the 24 checks
The agent iterates with lint_draft. It runs every check no model reads, inside the Worker, on the whole post, and answers in about a second. Each finding names the passage it's about and what to do, so the agent fixes that sentence and lints again, as often as it needs, at no model cost to us. lint_draft also returns the judge's rubric: the reader the post is judged as, each question our judge will ask with its threshold, and the first screen the buyer test reads. The agent reviews its own draft against that rubric on the engineer's subscription.
Once the draft is filed, check_draft with the draft's id is the final verification. It's the browser editor's own Run checks on exactly the saved text, our judge included, and it takes five to ten minutes. Checking the same text again is answered from the earlier run.
The 24 checks 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 |
A check without an answer fails 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.
There's only one list of gates. The site build in npm run check, the hosted blog writer, the editor's Run checks, lint_draft, check_draft and the approval at the merge all call each check's own code instead of a copy of its rules, and a test fails the build if any of their lists 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. The engineer is writing about their own work, and their agent can check every claim against the vendor's documentation and the code in front of it. Having a model second-guess 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, and nobody can publish past the claims gate or the known-errors registry. 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 left to the agent and the author instead of a gate, which is why it opens the rules document and why the author reads the preview before anything goes live.
From draft to published
When lint_draft passes, the agent calls submit_draft. The post is filed under the signed-in engineer's byline exactly as written. The site sets the author, today's date and draft: true, and adds a reading time if the post has none. Then the pipeline does the work an engineer shouldn't have to: it renders each Mermaid diagram with the site's font and palette, puts the images in our blog media, builds the preview and emails the author the preview and the editor link.
For revisions the agent lints the new text, then calls update_draft with the whole 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. A save runs no checks, so after the last one the agent calls check_draft with the draft's id.
publish_draft never publishes on its first call. A client that can ask the engineer does, with a question that names the post. A client that can't gets a one-time confirmation, good for ten minutes and for this exact text, and the agent is told to ask the engineer before sending it back. Once they say yes, the post goes through the editor's own Publish, merge and deploy, and a failed merge or deploy brings the draft back with what failed. Publishing needs a passing check_draft run on exactly the saved text. If only wording and style checks failed, the engineer can choose to publish past them, and that choice is recorded. Build, images, diagrams, links, claims and known errors always have to pass.
The same tools file a case study instead of a post, with kind: "case-study", and an engineer can schedule their agent to draft a post every weekday morning from get_brief. A scheduled run stops at the preview and never publishes.
Setting it up
In Claude Code, add the server once:
claude mcp add --transport http 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 Codex it's codex mcp add techfabric --url https://www.techfabric.com/mcp, then codex mcp login techfabric. Our MCP servers page has the setup for Cursor, VS Code, Fabric Agents and the rest.
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 lint_draft and fix every finding until it passes, review the draft against the judge_rubric it returns, then submit it with submit_draft and give me the preview link.
Each signed-in author has an hourly limit on calls, and checking text that was already checked joins the earlier run instead of counting again.
Frequently asked questions
Can an engineer's agent publish to techfabric.com through the MCP server?
Yes, for the engineer's own draft, once the engineer confirms. publish_draft needs the full checks to have passed on exactly the saved text, and its first call publishes nothing: the client asks the engineer, or the agent gets a one-time confirmation it may send back only after asking them. Anyone who isn't on the blog's author list can't reach the write tools at all.
Which coding agents can write drafts?
Any MCP client that can sign in with OAuth, including Claude Code, Codex, Cursor, VS Code, Fabric Agents and Claude's custom connectors in Claude Desktop and claude.ai. The engineer signs in with their @techfabric.com Microsoft account and must be on the blog's author list. Reading the site's published pages needs no sign-in.
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 nobody can publish past those two.
Why does it cost us less than the email route?
The engineer's own coding-harness subscription pays for the drafting, the revisions and the rule-based lint, which can run as often as the agent likes. Our AI gateway credits go mainly to the judged checks, which run once on the final text.
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.