Clearon Editorial Pipeline MCP

MCP server for immutable editorial revisions, explicit human approval, and draft-only publishing handoffs.

The server does not write prose and does not claim to detect AI authorship. Its job is to preserve revisions, expose transparent style heuristics, and require explicit human review before export.

What it does

• Creates append-only editorial projects.

• Preserves immutable revisions with SHA-256 fingerprints.

• Validates and normalizes declared source_urls metadata.

• Flags style heuristics without pretending to be an authorship detector.

• Requires explicit editorial, factual, and quotation review confirmations.

• Exports draft-only WordPress payloads for a separate publishing workflow.

• Carries forward the latest matching source-audit gate for article exports.

Related MCP server: Shawn Core MCP

What it does not do

• It does not publish.

• It does not make editorial decisions for you.

• It does not verify sources or quotations against external material.

• It does not sanitize raw HTML exports automatically.

Requirements

• Node.js 20 or newer

• A local MCP client that can launch a stdio server

Installation

cd tools/clearon-editorial-pipeline-mcp
npm install
npm test
npm run smoke

MCP client setup

Example stdio configuration:

{
  "mcpServers": {
    "clearon-editorial-pipeline": {
      "command": "node",
      "args": ["/absolute/path/to/clearon-editorial-pipeline-mcp/server.mjs"]
    }
  }
}

Storage

By default, project data is stored outside the repository in a user data directory:

• macOS: ~/Library/Application Support/clearon-editorial-pipeline-mcp/projects

• Linux: ${XDG_DATA_HOME:-~/.local/share}/clearon-editorial-pipeline-mcp/projects

• Windows: %APPDATA%\\clearon-editorial-pipeline-mcp\\projects

Override that location with CLEARON_EDITORIAL_ROOT.

Each project stores:

• project.json

• revisions/*.txt

• revisions/*.json

• approvals/*.json

• handoffs/*.json

Recommended workflow

1. Call create_editorial_project.

2. Call audit_revision.

3. Rewrite the content in your normal editorial environment.

4. Call propose_revision.

5. Review the exact proposed text, protected passages, protected blocks, and audit output.

6. Call apply_revision.

7. Call approve_revision only after human editorial, factual, and quotation review.

8. Call export_wordpress_payload.

9. For article projects, make sure the latest source-audit report matches the approved revision. Export requires that report to be ready_for_human_approval.

10. If the exported payload includes pending source_audit.pending_publish_update_review_findings, keep going with dry-run review only. Publish or update must wait for explicit user approval of those exact source-integrity items.

11. Run the exported payload through a separate publishing dry-run workflow.

Tools

• get_server_health

• create_editorial_project

• list_editorial_projects

• get_editorial_project

• audit_revision

• propose_revision

• apply_revision

• approve_revision

• export_wordpress_payload

HTML exports

If a project uses content_format=html, export_wordpress_payload requires trusted_html=true.

For content_type=article, export_wordpress_payload also reads the latest source-audit report for the same slug from CLEARON_SOURCE_AUDIT_ROOT or the default Clearon source-audit data directory. The report must match the approved revision fingerprint and be ready_for_human_approval. When ready_for_publish_or_update is still false, the payload records the pending source-integrity review list so downstream dry runs can surface it and real publish/update flows can block on it.

That requirement is explicit because the server passes stored HTML through as-is. If you need sanitization, do it in a separate trusted preprocessing step before export.

Protected passages

protected_passages are not just substring checks anymore. At project creation, the server captures the full original block containing each protected passage and later revisions must preserve that exact protected block. This is still a lightweight structural safeguard, not a full semantic diff or legal-redline system.

Development

npm test
npm run smoke
npm run syntax