decoupled.io
← All Articles
AI & Development

MCP Connectors Are Not a CMS: What Lovable, Bolt, and Base44 Still Need

Jay Callicott··8 min read

MCP Connectors Are Not a CMS: What Lovable, Bolt, and Base44 Still Need

The biggest AI app builder story in early 2026 is the rapid spread of MCP across the tools people actually use to build software.

On January 26, 2026, MCP Apps became the first official MCP extension, adding interactive UI inside chat clients. On March 9, 2026, the MCP roadmap shifted toward transport scalability, agent communication, and enterprise readiness. In parallel, Bolt launched Connectors on February 26, Lovable expanded its personal MCP connectors, and Base44 kept pushing MCP deeper into its builder workflow.

That trend also creates a misunderstanding.

Many teams now assume that if their AI builder supports MCP, they have solved content management. They have not. MCP connectors are a tool interface for agents. A CMS is an operating system for content. Those are related, but they are not interchangeable.

If you are searching for a headless CMS for Lovable, a bolt.new CMS, or an MCP CMS for AI-built apps, this distinction matters.

Why this matters right now

The 2026 generation of AI builders is moving from toy demos to production workflows.

Vercel framed that shift directly in its February 3, 2026 announcement for the new v0, calling out security, production apps, and agent-driven software delivery. Next.js followed that up in February and March with explicit work on an “agentic future,” plus AI-focused improvements in Next.js 16.2 like AGENTS.md support in create-next-app.

That changes the question teams ask.

The question has shifted:

  • Who updates the homepage copy next week?
  • Where do campaign landing pages live?
  • How do marketers change CTAs without touching prompts or code?
  • How do agents create content safely without turning the repo into a database?
  • How do we deliver the same content to web, app, email, and AI workflows?

MCP helps with orchestration. It does not replace structured content.

What MCP connectors actually do

Model Context Protocol gives AI clients a standard way to talk to external tools and data sources. That is extremely useful.

In practice, current AI builders mostly use MCP in one of three ways:

  • Context ingestion: read docs, tickets, analytics, schemas, and design files while building.
  • Tool actions: create issues, update tasks, inspect systems, or trigger workflows.
  • Agent UI: return interactive forms, dashboards, and other controls inside the conversation.

Bolt can connect to remote MCP servers and use tools like Notion, GitHub, or Linear as live context while you build. Lovable does something similar with personal connectors, where the agent can read documentation, tickets, and diagrams to generate better prototypes. Base44 also supports MCP connections for external context during the build process.

This removes a lot of “copy-paste the brief into the prompt” work.

But there is an important limitation: in several of these products, the MCP connection is primarily for the builder chat, not the deployed app runtime. Base44 states this directly in its docs: MCP connections control what the AI chat can access while you build; your deployed app code does not call those MCP servers through that settings flow.

That means MCP can help create your product, but it usually is not the system that should store and govern production content.

The gap: build-time context vs runtime content

This is the part teams feel after launch.

Your AI builder can generate a polished landing page, wire up auth, maybe even scaffold a database. But the moment marketing wants to run campaigns, publish case studies, update pricing copy, or localize hero text, you need capabilities that MCP alone does not provide:

  • Structured content models for pages, blocks, promos, FAQs, authors, and media
  • Editorial workflows with drafts, revisions, and permissions
  • Visual editing so non-developers can change content safely
  • Stable APIs for web, mobile, agents, and automation
  • Reusable content instead of prompt-specific one-off outputs

An MCP server exposes tools. A headless CMS exposes governed content.

That difference matters even more for AI-built apps because teams move fast before they have modeled content properly. The result is common:

  • copy embedded in components
  • “CMS” data living in random JSON files
  • product messaging split across prompts, code, and vendor-specific backends
  • no safe handoff from developer to marketer

This is where decoupled Drupal still makes sense.

What a proper CMS architecture looks like for AI-built apps

For most teams, the clean pattern is:

  1. Use the AI builder and MCP tools to stand up the project fast.
  2. Use MCP again to provision and configure your CMS.
  3. Run the live app against GraphQL or JSON:API, not against builder-chat context.
  4. Let marketers manage content in a visual editor instead of asking the AI to rewrite source files.

Use MCP for setup and automation, then use a CMS API for production delivery.

// app/api/page-data/route.ts
const query = `
  query LandingPage($slug: String!) {
    pageByPath(path: $slug) {
      title
      heroHeadline
      heroSubhead
      ctaText
    }
  }
`

export async function GET(req: Request) {
  const { searchParams } = new URL(req.url)
  const slug = searchParams.get('slug') || '/'

  const res = await fetch(process.env.DRUPAL_GRAPHQL_URL!, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.DRUPAL_TOKEN!}`,
    },
    body: JSON.stringify({ query, variables: { slug } }),
    cache: 'no-store',
  })

  const { data } = await res.json()
  return Response.json(data.pageByPath)
}

That route can be called by a Lovable frontend, a Bolt project, a Next.js app from v0, or a custom React application. The app does not need Drupal internals. It just needs a stable content API.

Why Drupal is unexpectedly well positioned in this cycle

What matters in 2026 is whether your CMS can act as a durable content system behind increasingly agentic frontends. Drupal is strong here for a few reasons:

  • Mature structured content modeling
  • Revision history and editorial permissions
  • Open-source ownership
  • Multiple delivery options, especially GraphQL and JSON:API

There is also active movement in the Drupal headless stack itself. The Drupal GraphQL project shipped 5.0.0-beta2 on February 19, 2026, with support for Drupal 10.4 and 11. That is useful if you want a modern GraphQL layer without giving up Drupal’s editorial model.

The trade-off is familiar: self-managed Drupal still brings operational complexity. If you want the content model and APIs without the PHP maintenance burden, a managed approach is usually better.

That is the space Decoupled.io fits into. It gives teams a managed headless Drupal backend with APIs, a visual page builder, and MCP tooling, so the AI builder can stay focused on frontend velocity while the CMS handles content properly.

What to look for in a CMS for Lovable, Bolt.new, or Base44

If you are evaluating a Contentful alternative, an open source headless CMS, or a visual editor headless CMS for AI-built apps, use this checklist:

  • Does it support runtime APIs cleanly? GraphQL and JSON:API are both valuable.
  • Can marketers edit without code or prompts? A visual editor matters more than people admit.
  • Can AI agents provision and manage it? MCP tools are useful here.
  • Can you reuse content across channels? Web is only one surface now.
  • Do you own the model and data? Vendor lock-in is worse when AI accelerates app sprawl.
  • Can it fit an existing React or Next.js frontend? You should not need to rebuild the UI around the CMS.

The better pattern is simple: let the builder generate the experience, and let the CMS own the content lifecycle.

A practical way to adopt this without slowing down

You do not need to stop using AI builders. You need to stop asking them to be your CMS.

Start with this split:

  • Use your AI builder for layout, components, flows, and experimentation.
  • Use MCP tools to create and configure your content backend.
  • Move editable copy, media, landing pages, and reusable blocks into the CMS first.
  • Keep product logic in code and content in the content system.

If you are building with Decoupled.io, the relevant starting points are AI app builder integration, MCP tools, and the visual page builder. If your frontend needs direct API integration, the GraphQL docs are the next stop.

CTA

If your team is using Lovable, Bolt.new, Base44, or v0 and hitting the “who owns content now?” problem, the answer is not more prompts. It is a proper headless CMS with a visual editor and agent-friendly tooling.

Start with Getting Started, then connect your frontend through AI builder integration or GraphQL. Decoupled.io is built for exactly this split: AI-generated frontend velocity on one side, structured Drupal content on the other.