Bridging AI and Web Publishing: Decoupled CMS via n2n-post2site

Giving an AI assistant direct access to your production database or server shell is rarely the right boundary.

It is reasonable to let an assistant help draft release notes, blog posts, and documentation. It is not reasonable to hand it broad server credentials just because the final output is text.

A safer design keeps the assistant on the drafting side and leaves storage, authorization, and publication policy inside the website backend. That is the role of n2n-post2site.

It is a Model Context Protocol (MCP) server that acts as a stateless bridge between your IDE assistant and your website’s API.

The core philosophy: Draft with AI. Publish with intent. (Source: n2n-post2site README)

The "Thin Bridge" Approach

Instead of granting the AI direct access to your site’s internals, n2n-post2site sits in the middle. It has no database, no file system, and no deployment capability.

┌─────────────────────────────┐
│     AI coding assistant     │
│   (Claude, Cursor, VS Code) │
└──────────────┬──────────────┘
               │ MCP tool calls (stdio)
               ▼
┌─────────────────────────────┐
│        n2n-post2site        │
│     MCP server · 9 tools    │
│  validate → map → HTTP call │
└──────────────┬──────────────┘
               │ HTTPS + site-scoped API key
               ▼
┌─────────────────────────────┐
│   Your backend content API  │
│  (Content Publishing API    │
│   Contract)                 │
│  owns storage, auth, policy │
└─────────────────────────────┘

(Source: n2n-post2site README - Architecture)

The setup is straightforward:

1. The MCP Server is stateless: It only takes tool inputs from the AI, validates the parameters, and maps them to HTTP requests.
2. Your backend keeps control: Your server handles database reads, publication states, and access control behind a secure API.

Strict Security Perimeters

The toolset is intentionally narrow. n2n-post2site does not support any administrative actions. The AI client cannot:

• Delete posts.
• Run raw SQL queries or read system logs.
• Modify pricing plans or subscription data.
• Manage user accounts.
• Execute terminal shell commands.

(Source: n2n-post2site README - Security and governance notes)

If the AI behaves erratically, the worst it should be able to do is create a messy draft. Server configuration and user data stay outside the MCP server boundary.

Drafting vs. Publishing

AI models shouldn't publish articles autonomously. n2n-post2site separates content drafting from actual publishing.

1. Discovery: The AI searches existing posts (n2n_list_posts) to avoid duplicates.
2. Context Intake: For scoped content (like product-specific guides), the AI reads the environment context using n2n_get_scope_context.
3. Drafting: The AI creates or updates draft files locale-by-locale using n2n_create_post and n2n_update_draft.
4. Intentional Publishing: The post stays as a draft until a human explicitly tells the AI to run n2n_publish_post, or logs into the admin panel to click publish.

(Source: n2n-post2site README - Publishing model)

This flow ensures that human oversight is always required before anything goes live.

How to Set It Up

To use this, your website's backend needs to provide the content publishing API.

Once your backend is ready, add the server to your Claude Desktop config:

{
  "mcpServers": {
    "n2n-post2site": {
      "command": "npx",
      "args": ["-y", "n2n-post2site"],
      "env": {
        "CONTENT_API_BASE_URL": "https://your-site.com/api/v1/mcp",
        "CONTENT_API_KEY": "your-secret-api-key"
      }
    }
  }
}

(Source: n2n-post2site README - Quick Start)

Keep The Boundary Narrow

Automation helps, but it should not collapse content editing and system administration into the same permission boundary. By keeping the bridge narrow, n2n-post2site makes AI-assisted publishing easier to review.

Visit the n2n-post2site GitHub repository to view the API contract.