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. n2n-post2site is built for that split. It is a Model Context Protocol (MCP) server that acts as a stateless bridge between your IDE assistant and your website's API.

The project README sums it up as "Draft with AI. Publish with intent." (Source: n2n-post2site README)

The "Thin Bridge" Approach

n2n-post2site sits between the AI and your site's internals. 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 MCP server is stateless. It only takes tool inputs from the AI, validates the parameters, and maps them to HTTP requests. Your backend keeps control of database reads, publication states, and access control behind a secure API.

Strict Security Perimeters

The toolset is intentionally narrow, and 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. The AI searches existing posts (n2n_list_posts) to avoid duplicates.
2. For scoped content, such as product-specific guides, it reads the environment context using n2n_get_scope_context.
3. It creates or updates draft files locale by locale using n2n_create_post and n2n_update_draft.
4. The post stays a draft until a human explicitly tells the AI to run n2n_publish_post, or logs into the admin panel and clicks publish.

(Source: n2n-post2site README - Publishing model)

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.