Building a Local MCP Content Pipeline for HocTat
A lab note on using local MCP tools for research collection and draft creation while keeping publication behind Admin review.
The Boundary Matters More Than The Tool
An MCP content pipeline can be useful when it helps collect research, inspect taxonomy, and create first-pass drafts. The risk appears when the same automation surface can also approve or publish. For a technical content hub, that boundary should be explicit: agents may assist the draft pipeline, but publication stays behind human Admin review.
That split keeps automation useful without turning it into an editorial bypass.
A Sensible Local MCP Shape
A local content pipeline should start narrow. Read tools can expose safe discovery data such as content types, categories, editorial rules, and existing research items. Write tools can be limited to actions that still produce private work, such as collecting a research item or creating a draft.
The important design choice is what not to expose. Approval, publication, deletion, role changes, raw SQL, migrations, and secret-reading tools do not belong in a draft-assist MCP surface. Those operations have wider product and security impact, so they should remain in existing Admin or operational workflows.
Audit Every Write
Even draft-only writes change the editorial database. Each write action should leave an audit record with the tool name, result, correlation identifier, actor context, and a safe request summary. The audit record should help a maintainer answer what happened without storing raw secrets, tokens, connection strings, or private operational payloads.
Workflow activity and MCP audit logs are related but distinct. MCP audit logs explain agent-assisted write actions. Post activity logs explain editorial lifecycle transitions such as review, approval, and publication.
Human Review Is The Publishing Gate
The final review should happen in the Admin workflow. A reviewer checks whether the title, slug, summary, category, content type, difficulty, SEO metadata, Markdown rendering, and source notes are appropriate for public readers. Only then should the post move from Draft to InReview, Approved, and Published.
This gives the pipeline a clear job: accelerate preparation while preserving accountability for publication.