We registered NextBlock on MCP so desktop agents can build full CMS sites autonomously
Happy Friday! We just hit two big milestones for NextBlock CMS: we submitted our application to the Vercel Starter Templates gallery, and we listed NextBlock across every Model Context Protocol (MCP) registry we could find.
The problem with prompt-to-website tools is what happens on Day 2. Generating a prototype takes two minutes, but the moment you need to change a headline, update pricing, or hand the project to a client, you are stuck editing raw code or fighting LLM regressions.
We updated our CLI and /api/mcp endpoint so desktop agents (Claude Code, Cursor, Codex) can handle the build autonomously:
You prompt the agent: "create a new website using nextblock for [topic]."
The agent resolves the nextblock npm package and runs non-interactive scaffolding.
It writes structured PostgreSQL JSONB layout blocks directly into Supabase instead of fragile HTML strings.
When it finishes, you get a visual Notion-style Tiptap editor and 100/100 Lighthouse scores on Next.js 16 React Server Components.
You bring your own existing agent subscription without paying marked-up token fees.
Sandbox: https://nextblock.dev
GitHub: https://github.com/nextblock-cms/nextblock
How are you currently handling client handoffs after scaffolding sites with AI agents?
The Day 2 test I’d care about is what happens after both sides have edited the same site. A client changes pricing in Tiptap, then the agent returns a week later to add a section. Does it preserve the client’s change, explain the diff and avoid rewriting unrelated blocks?
Writing JSONB directly makes the first build fast, but I reckon the durable unit needs to be a validated content operation rather than a database mutation. Draft, schema-check, preview the visual diff, then publish or roll back.
If that round trip works—agent builds, human edits, agent safely returns—you have something meaningfully different from prompt-to-site generation. That is the handoff demo I’d put front and centre.
You hit the nail on the head. That bidirectional round trip is the real Day 2 test.
The reason client edits survive is block-level granularity. Pages aren't stored as one monolithic document blob; they exist as discrete, addressable block nodes in PostgreSQL. When an agent returns to add a section, its tool call appends or inserts a specific block node by ID rather than rewriting the rest of the page, so the client's pricing tweak stays untouched.
Writes are strictly schema-checked with versioned snapshots to roll back regressions, but your point on treating it as a staged content operation with a visual diff preview before publishing is pure gold. Spot-on advice for the demo, that exact round trip is what we will showcase next.
Congrats on the listings. A few things we learned running a remote MCP server for Mythex (disclosure: I'm building it, an AI app builder), in case they save you time:
Your Day 2 framing is the right thing to lead with.
Really appreciate this. The heads-up about bumping the resource URI to bust Claude's card cache is gold, we definitely would have lost hours debugging that exact issue.
Adding readOnlyHint and destructiveHint to our tool schemas right now before the registry grows any further. Good to know about the OAuth test requirements on other directories as well.
Thanks for sharing the hard-learned lessons, checking out Mythex now.
Autonomous agents building CMS via MCP is exactly where the security model breaks down — three things we keep hitting in red-team scans of agent stacks:
If it's useful: we run 24 probes / 9 classes against LLM + agent apps, including MCP trust and action-binding. The micro scan is free: https://llmrt-companion.manhliemcn4euwlu.workers.dev/agent-scan — point it at the agent loop and it reports where the bindings leak.
Autonomous agents building CMS via MCP is exactly where the security model breaks down — three things we keep hitting in red-team scans of agent stacks:
If it's useful: we run 24 probes / 9 classes against LLM + agent apps, including MCP trust and action-binding. The micro scan is free: https://llmrt-companion.manhliemcn4euwlu.workers.dev/agent-scan — point it at the agent loop and it reports where the bindings leak.
Solid points. These are genuine failure modes for write-heavy agent workflows. Here is how we mitigate them:
Server spoofing: The CLI binds strictly to the local instance (localhost:3000/api/mcp) using a unique bearer token generated directly in .env.local, rather than letting the agent resolve an unpinned remote server.
Metadata injection: The agent is only exposed to structured layout tools. No raw SQL or shell tools exist, and every mutation is validated against a strict Zod-backed JSONB schema before touching PostgreSQL. An injected prompt cannot execute arbitrary code or bypass database constraints.
Retry duplication: Writes use idempotent upserts keyed on unique page slugs and block IDs rather than blind inserts, so retried network calls do not create orphaned drafts or duplicate pages.
Appreciate the scan link, will take a look at the probes.
The Day 2 problem is the interesting part. Have any real client sites gone from agent scaffolding to handoff with NextBlock, and where did the workflow still break?
Honestly, none yet. We literally just shipped the MCP endpoint and CLI scaffolding, so so far it has only been tested internally on nextblock.dev and local test projects.
In our internal testing, the main point of failure was the agent hallucinating custom block structures instead of sticking to our JSONB schema. We had to add strict schema validation directly into the MCP tool responses to keep the agent in bounds.
Whether a real client will actually feel comfortable editing blocks in Tiptap or immediately email the developer asking to "just re-prompt the AI" is the exact question we want to answer in this beta.
We’re already connected by email — I’ve sent you three notes there (July 23, July 29, and August 12). I just followed up here because the beta question you raised is relevant to what I was asking about. Reply there when you get a chance and we can continue.