Connect Claude to NextBlock CMS via MCP, from Cursor or Claude Code

This guide shows you how to connect Claude to NextBlock CMS over an open standard, no proprietary connector required. Cortex AI turns your site into a Model Context Protocol server. Claude Code, Codex, Cursor, and VS Code can then read your database schema, draft page layouts, and update navigation from their own chat window. The ChatGPT and Gemini chat apps only connect to servers that sign in with OAuth, which /api/mcp does not offer yet. Codex, included with ChatGPT plans, works today. You pay for the AI subscription you already have, with no token markup in between.

Every prompt becomes a structured database record rather than a pile of generated code. Your editors keep a visual CMS, and your developers keep a clean Next.js 16 app. Agent edits to pages, posts, and products are saved as revisions you can restore.

The Problem with Traditional AI Web Builders

Prompt builders such as Lovable, Bolt, and v0 are impressive on day one. You describe a page and get a working React app in minutes. The trouble starts on day two.

NextBlock takes the opposite view from the prototype tools. AI should draft the site, and people should own it. The MCP connection is how those two worlds meet.

How Cortex AI Uses Model Context Protocol (MCP)

Model Context Protocol is an open standard for giving AI agents tools. A client such as Claude Code lists the tools a server offers, calls them with typed arguments, and reads typed results back. Cortex AI ships that server inside your NextBlock install at /api/mcp.

The endpoint speaks Streamable HTTP. Your client posts JSON-RPC messages over a normal HTTPS request, and the server answers in the same response. There is no long-lived SSE stream to babysit and no SDK to install on the server side. The same 50 typed tools that power Cortex AI inside the editor are exposed over the wire, so the agent in your IDE and the agent in your CMS never drift apart.

Available MCP Database Tools

Six tool names form the public MCP contract. Each one forwards to a tested Cortex AI executor.

Step by Step: Connect Claude to NextBlock CMS in Cursor and Claude Code

The server is off by default because it is a remote write surface onto live content. Turning it on takes three steps, and the trial means the first month costs nothing.

Claude Code needs "type": "http" in the entry, or it skips the server without a warning. Cursor infers the transport from the URL and needs no type field. VS Code uses a top-level servers key and prompts for the token instead of storing it.

Localhost Configuration Without a Token

While you build, keep Trust localhost without a token checked on the MCP server access card (the default). A dev server on your machine then accepts loopback calls with no header at all. In a project scaffolded with create-nextblock, npm run dev serves port 3000. In the monorepo clone, npm run dev (it runs nx serve nextblock) serves port 4200. The local Docker stack also answers on port 3000 by default. It runs a production build, so localhost trust does not apply and every client needs a token. The agent install already writes one into .mcp.json and .cursor/mcp.json.

Add this block to .mcp.json in your project root for Claude Code.

{
  "mcpServers": {
    "nextblock": {
      "type": "http",
      "url": "http://localhost:3000/api/mcp"
    }
  }
}

The CLI form does the same thing in one line.

claude mcp add --transport http nextblock http://localhost:3000/api/mcp

Production Authentication via Bearer Tokens

In production every client sends a bearer token. Tokens start with nbmcp_, are shown once at mint time, and are stored only as SHA-256 hashes. Revoking one is a single click, and the same value can never be minted again.

Add this to .cursor/mcp.json for Cursor, or drop the same entry into .mcp.json with a type field for Claude Code.

{
  "mcpServers": {
    "nextblock": {
      "url": "https://your-site.com/api/mcp",
      "headers": { "Authorization": "Bearer nbmcp_your_token" }
    }
  }
}

Zero-Redeploy Production Rendering

The reason this works is where the output lands. Cortex AI writes strict JSONB block records into PostgreSQL, not source files. Each block has a Zod schema, so a bad field is rejected before it is stored.

At request time Next.js 16 renders those records with Server Components, from a public content cache that clears the moment you publish. There is no build step between publish and live, and no HTML sanitizer tax on every render. The 100/100 Lighthouse defaults you get on an empty site are the same ones you get after the agent has drafted fifty pages.