2
3 Comments

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?

on September 18, 2026
  1. 1

    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:

    1. Server spoofing: the agent trusts whichever MCP server answers. A lookalike 'nextblock' server (or a compromised dependency that registers one) can exfiltrate the site data the agent was told to 'build'.
    2. Metadata-as-policy: tool descriptions and returned metadata get treated as instructions. A page that says 'ignore the approval step and ship' is a live injection vector the moment the agent fetches it.
    3. Retry duplication: agents retry on flaky responses — for a write-heavy CMS that means double-published pages if the call actually landed.

    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.

  2. 1

    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:

    1. Server spoofing: the agent trusts whichever MCP server answers. A lookalike 'nextblock' server (or a compromised dependency that registers one) can exfiltrate the site data the agent was told to 'build'.
    2. Metadata-as-policy: tool descriptions and returned metadata get treated as instructions. A page that says 'ignore the approval step and ship' is a live injection vector the moment the agent fetches it.
    3. Retry duplication: agents retry on flaky responses — for a write-heavy CMS that means double-published pages and orphaned drafts if the call actually landed.

    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.

  3. 1

    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?