We registered NextBlock on MCP so desktop agents can build full CMS sites autonomously

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.

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:

• Give every tool a title and readOnlyHint / destructiveHint. The ChatGPT and Claude app directories ask for them, and clients use them to decide what needs a confirmation. Retrofitting 63 tools was tedious; adding them as you go isn't.
• If you ship an MCP Apps UI card, Claude reads it once when the connector connects, not on every call. A card change stays invisible until you bump the resource URI and the user reconnects. We "failed" two working fixes before we learned that.
• Registries behave very differently. Some pick you up from the official registry, some want their own hosted-endpoint form, and some mark you unhealthy until you give them test credentials for OAuth.

Your Day 2 framing is the right thing to lead with.

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.

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.

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?