---
title: "AI CMS Integration: How Live CMS Context Improves Page Generation"
url: https://www.darwinapps.com/blog/ai-cms-integration-live-cms-context-page-generation/
type: article
---

![AI CMS integration illustration showing live CMS context for page generation.](https://cdn.sanity.io/images/qd0fa73p/production/4876c1e6a8d8ad819a5874b1c9d10b5834dba012-2984x1679.png?w=1492&q=85&auto=format)

# AI CMS Integration: How Live CMS Context Improves Page Generation

- [#AI](https://www.darwinapps.com/blog/category/ai/)

## Quick Answer

When an AI assistant builds pages inside a CMS, it has to choose the right kind of page for the request. Component checks confirm blocks and settings, and page-family choice depends on the site's published pages. For one client, we connected ChatGPT to Drupal through MCP: the assistant researches live pages and creates editable, unpublished drafts from native components, with no manual HTML transfer.

## TL;DR

- **Component validation checks components and attributes.** Page-family selection depends on published precedents. Our first draft of a partner page passed Drupal validation and followed a generic landing-page family, and an existing partner page on the client's site was the correct precedent.
- **Published pages define page families.** We reviewed 14 compositions for 12 landing-page families. In a fresh test without a suggested reference, the revised skill selected that existing partner page as the reference.
- **Static guidance drifts with the site.** The offline skill worked from a snapshot, so every change to forms, media or components meant a skill update. We moved research into the live CMS through an MCP server with 17 bounded tools.
- **Write access is narrow by design.** Users sign in through Drupal with OAuth, existing permissions apply and the assistant writes only drafts. Editing published pages and publishing stay with editors, and revision and duplicate checks guard every write.
- **The integration is on a test site.** Documented checks include native draft creation, editor roundtrips, revision protection and Drupal authentication. During a client working session, a marketing representative from the client used the integration to generate and review a webinar-page draft.

AI-generated pages introduce a challenge that component-level CMS validation cannot resolve. A page can render correctly, use supported blocks and satisfy its schema with a composition built for a different purpose. For teams using AI to assemble complete pages, the question is how the system decides which page structure belongs to the request.

That decision depends on context that sits outside a component catalogue. Published pages show how a site's content types are composed, current CMS data supplies valid references and editorial rules determine what a person should review. Each of these is a separate responsibility, and an integration needs to account for all of them.

## The Architectural Requirements of AI Page Generation

Generating a complete CMS page requires more than drafting its text. The model must work within an existing content architecture, where page types, component configurations, entity relationships and editorial conventions all shape what can be assembled.

A component catalogue describes available building blocks and their supported attributes, and our guide to[design-system documentation for AI page builders](https://www.darwinapps.com/blog/ai-page-builders-design-system-documentation/) covers how to document it. A schema can determine whether a configuration is technically valid. Identifying the appropriate page family takes a third source: a page family is a group of pages that do the same job and share a section order. A webinar registration page, a customer story and a campaign landing page may share components and organize information differently because they serve different purposes.

A technically valid sequence of blocks can produce an unsuitable page. Existing published pages offer evidence of section order, component variants and content hierarchy. Page purpose, audience and intended call to action help identify which precedent is relevant. Editorial review remains necessary to assess the copy, claims and final layout.

## From Component Validation to CMS-Aware Page Generation

Static component instructions are useful for defining what an AI system may generate. Their limitation is that they capture one state of the CMS. New pages, updated components, changed media and revised content relationships can make that reference incomplete. The same problem appears with data, as our article on[marketing data readiness for AI agents](https://www.darwinapps.com/blog/marketing-data-readiness-for-ai-agents-what-to-fix-before-automating-analytics-workflows/) explains.

A CMS-aware workflow can retrieve relevant published examples, inspect their composition, resolve supported references and validate a proposed draft against the CMS. This gives the model evidence for its choices and treats each published example as a reference point. When the request is ambiguous or a page type is unsupported, the workflow should surface that uncertainty. A plausible invented layout would hide the problem.

The practical challenge is turning these principles into a workflow that works with an established CMS. The model needs enough information to select an appropriate page structure, and the CMS needs a reliable way to validate what the model produces. We encountered these requirements in our work with a B2B software client whose marketing team manages landing pages, webinars, case studies and blog content in Drupal. The site uses custom Gutenberg components, and its existing authoring process involved custom GPTs and HTML templates that marketers transferred into Drupal manually. Pages built that way sit outside the component library, which is how[design debt on B2B marketing websites](https://www.darwinapps.com/blog/design-debt-on-b2b-marketing-websites-why-ai-built-campaign-pages-become-expensive-to-maintain/) builds up.

## AI-to-Drupal Integration and Native Draft Generation

To bring generated content into the existing editor, we used a ChatGPT skill containing the site's component references and page-generation instructions. It produced a page plan in Drupal's native format. A custom Drupal importer checked that plan and then created an unpublished draft that marketers could open and edit in the CMS.

In the tested workflow, this replaced manual HTML transfer with native draft creation. The importer verified that the proposed components and attributes were supported. The next test raised a different question: whether a valid draft also followed the right page family.

## Why Drupal Validation Cannot Confirm the Right Page Structure

We saw the gap in a draft of a new partner page. It used the client's native Gutenberg components, passed Drupal validation and rendered correctly. Its composition followed a generic landing-page sequence of promise, credibility, offer and call to action. An existing partner page on the client's site was the more appropriate precedent for that content, so the draft was valid in Drupal and belonged to the wrong page family.

A valid draft with an unsuitable composition opens in the editor and can look complete. The discrepancy becomes clear when an editor compares its composition with the page type the site uses for that content.

![How the authoring approach evolved from custom GPTs and HTML templates to an MCP-connected live CMS.](https://cdn.sanity.io/images/qd0fa73p/production/af274210fd72ce5f19d4278b9a9c3b9a56cc9d33-2280x1166.png?w=1140&q=85&auto=format)

> "Components are vocabulary, not grammar." – Gregory Potemkin, AI Engineer, Darwin

## How Published Pages Inform AI Page-Family Selection

We rebuilt the skill around page families taken from the client's published pages. Those pages already showed which sections each page type used and in what order, and they had passed the client's own publishing process. The team reviewed 14 compositions for 12 landing-page families and added a case-study adapter.

Page purpose, intended audience and call to action guided the choice of family. We used a published page serving the same purpose as the reference for section order and component variants. The reference came from the site's editorial conventions, so the model had a real structure to follow.

In a fresh skill-only test without a suggested reference, the workflow selected that existing partner page as the reference for the new one.

Further tests found gaps. A broad family label could produce a page that was too short or picked a weaker hero than the closest existing example. Media selection needed image inspection along with filenames. We added more specific variants and media-role guidance.

This improved page-family selection. The guidance itself lived outside Drupal, so the skill needed updates each time components, forms or media changed. That maintenance problem led us to connect the assistant to the CMS itself, where it could inspect current pages and references ahead of composing a draft.

Planning to integrate AI into your CMS? Our team can help you build the integration, automate content creation and keep publishing decisions in your hands.

## Connecting AI to Live CMS Context Through MCP

We connected ChatGPT to Drupal through an MCP server and a companion CMS skill for the client's site. MCP, the Model Context Protocol, is an open standard that lets an AI assistant use tools inside another system. From ChatGPT, the assistant can research existing Drupal pages, inspect their component structures, find current media and forms, validate a proposed composition and create an unpublished draft directly in the CMS. Marketers no longer copy generated content into Drupal by hand. The assistant uses the site's existing page patterns to choose an appropriate structure or flags a request it cannot support.

The server exposes 17 bounded tools for identity and capabilities, schemas, page and component discovery, media, forms and references, validation, draft creation or update, preview and image upload. Every call runs under the signed-in user's Drupal permissions. Narrow tools make the model's access explicit, so a reviewer can see exactly which operations a given user can trigger.

An early MCP server ran as a separate Node process. For the test implementation, we moved the endpoint into a Drupal module written in PHP, within the site's existing hosting setup. Authors can request and revise drafts from ChatGPT, with changes written to Drupal through MCP. The Drupal editor remains available for review and manual edits, which the assistant can read back through the integration.

### How Our AI-to-Drupal Workflow Operates

1. **Research the live CMS.** The assistant retrieves published page examples, component schemas, forms and available media through permission-scoped MCP tools.
2. **Identify the page family.** The workflow selects a published precedent based on page purpose, audience and CTA. If the brief is ambiguous, it should ask for clarification. Unsupported page types are flagged and stay out of the generic landing-page layout.
3. **Compose with native components.** The model uses supported Drupal blocks and current CMS references for taxonomies, media, links, buttons and forms. It retrieves site-specific IDs and entity references from the CMS.
4. **Validate the composition.** The integration checks the proposed structure ahead of creating or updating an unpublished draft.
5. **Create an editable draft.** Editors can review the draft in Drupal and continue changes through the CMS or the connected assistant.
6. **Complete editorial review.** The client's editors verify the copy, claims and suitability of the page and retain control of publication.

![Six-step AI-to-Drupal workflow: research the live CMS, select the page family, compose, validate, create a draft and editorial review.](https://cdn.sanity.io/images/qd0fa73p/production/95206ee3b3ea1448a3809dbbabdcf60f933c9f11-2280x1440.png?w=1140&q=85&auto=format)

## Testing Draft Creation, Permissions and Revision Safety

We tested the MCP-connected workflow on a Drupal test site, including native draft creation and editing, editor roundtrips, rejection of outdated revisions, duplicate-request protection and permission-scoped access. An authoring test also surfaced invalid plans that were rejected ahead of saving. We corrected the writable schema guidance and retested. These checks cover the connected MCP workflow.

We treat validation as a deterministic gate. An invalid plan should fail with a clear reason and be corrected ahead of any saved draft. Any request the workflow cannot support should end in a flag or a question to the user. A[marketing automation audit](https://www.darwinapps.com/blog/marketing-automation-audit-10-checks-before-ai-workflows-go-live/) applies the same kind of checks to other AI workflows ahead of launch.

Each user signs in through Drupal with OAuth, and existing permissions apply. The assistant can read published pages for research and write only drafts. Editing published pages and publishing stay with the client's team. Revision checks reject outdated edits, and repeated requests do not create duplicates. We also reviewed the editor-facing experience during testing and addressed the issues it surfaced. For teams planning similar controls, our guide to[AI agent audit logs](https://www.darwinapps.com/blog/ai-agent-audit-logs-for-gtm-teams-what-to-track-before-automating-workflows/) covers what to record for each automated action.

### What We Tested

| Test | What It Verified |
| --- | --- |
| Partner-page family selection (skill-only stage) | In a fresh skill-only test without a suggested reference, the revised skill selected the existing partner page as the reference for the new one. This result predates the MCP integration. |
| Native Drupal draft creation | Drafts used supported CMS blocks and attributes. |
| Editor roundtrips | Drafts could be edited through Drupal and the connected assistant. |
| OAuth and permissions | Login, token refresh, declined access and user-scoped permissions were exercised. |
| Revision and duplicate checks | The integration rejected outdated edits, and repeated requests created no duplicate drafts. |
| Published-page restrictions | The assistant could neither edit published pages nor publish drafts. |

![Drupal MCP tests and what each verified.](https://cdn.sanity.io/images/qd0fa73p/production/36f517399f3e736a72abbc128c5cb30fdf77a2af-1960x632.png?w=980&q=85&auto=format)

During a client working session on the test site, a marketing representative from the client connected the integration with his own account, generated a webinar-page draft from supplied content, reviewed its preview and requested a form change. The session demonstrated draft generation and review through the connected workflow on the test site. Further deployment and component review remained under discussion.

Forms remain an important boundary. The assistant can discover and reference available Drupal form mappings. Submitting a form and verifying delivery through the external marketing platform sit outside the automated authoring workflow. End-to-end submission needs its own testing.

Validation confirms that a draft is buildable. Editors decide whether the page is right and ready to publish, and our[QA checklist for AI-built landing pages](https://www.darwinapps.com/blog/website-qa-for-ai-built-landing-pages-a-pre-launch-checklist/) covers that review. A valid page can have weak copy, unsupported claims or an unsuitable layout, and those decisions require editorial judgment. The system creates unpublished drafts only, and publication remains a human step.

## What Live CMS Context Changes for AI Authoring

The partner-page test exposed a distinction I now consider essential in AI-assisted CMS work: a valid structure is one condition for a useful page. The workflow also needs to select the right family, use references that exist in the current CMS and leave editorial decisions with the people responsible for the site.

Live CMS access makes those decisions better grounded. The assistant can inspect relevant published pages, current component schemas, media and forms ahead of preparing a composition. The MCP tools limit what it can read or change according to the signed-in user's permissions, and validation remains a separate check ahead of any saved draft.

Our tests also defined the limits. An ambiguous brief needs clarification, and an unsupported page type should be flagged. Identifiers come from the CMS, and form submission remains outside the automated path. A technically valid draft can contain weak copy, unsupported claims or an unsuitable layout.

The integration remains on a test site. It creates unpublished drafts, and the client's editors retain responsibility for review and publication. The documented checks support the workflow's tested capabilities. Production rollout and measurable page results sit outside what these checks cover.

![The four Darwin Flux questions behind an AI CMS integration: Surface, Connections, Clarity and Momentum.](https://cdn.sanity.io/images/qd0fa73p/production/fc2c729bcce6061f3ade126184654fe79395472f-2280x1440.png?w=1140&q=85&auto=format)

The same engineering decisions map to the four[Darwin Flux](https://www.darwinapps.com/darwin-flux/) questions. Surface identifies the page and experience being changed. Connections defines CMS access and permissions. Clarity establishes the published precedents and validation evidence. Momentum assigns review, publication and ongoing maintenance.

For a team evaluating AI CMS integration, I would examine the site's existing page families ahead of deciding how much autonomy to give the assistant. An[AI readiness assessment for marketing](https://www.darwinapps.com/ai-readiness-enablement/) is one structured way to run that review. The available components define what it can build. Published examples and editorial rules establish what it should build. The integration has to preserve both.

## Main Lesson

AI-generated CMS pages need access to the site's real content, page structures and component configurations. This context helps the model select appropriate layouts and generate drafts that follow established CMS conventions.

### Planning to integrate AI into your CMS?

Our team can help you build the integration and keep publishing decisions in your hands. Tell us how your team builds pages today.

![Gregory Potemkin](https://cdn.sanity.io/images/qd0fa73p/production/7750c1113491db96d953865ff47737582374e5f1-640x640.jpg?w=320&q=85&auto=format)

###### You might also like

![The image features an illustration of a woman talking on her cell phone with a robot standing behind her. The robot is holding up a sign that says "8", and there are other signs around it as well. In addition to these elements, there's also a person in the background who appears to be listening to the conversation between the woman and the robot.](https://cdn.sanity.io/images/qd0fa73p/production/54145a0392181010a7b36d3dee2831349ad81e40-2984x1679.png?w=1492&q=85&auto=format)

## [8 Best AI Customer Support Tools for B2B SaaS in 2026](https://www.darwinapps.com/blog/best-ai-customer-support-tools-b2b-saas/)

![The image features an illustration of a robot holding up a video game controller on its arm. The robot is depicted as a green humanoid figure with arms and legs, giving it a lifelike appearance. It appears to be in motion, walking across the frame while carrying the controller. The scene takes place against a backdrop that includes a computer screen displaying a website's navigation bar and a mouse icon.](https://cdn.sanity.io/images/qd0fa73p/production/09e16a7d8a781e33fc3a4451e1558a09b87ad79f-2984x1679.png?w=1492&q=85&auto=format)

## [Website QA for AI-Built Landing Pages: A Pre-Launch Checklist](https://www.darwinapps.com/blog/website-qa-for-ai-built-landing-pages-a-pre-launch-checklist/)

![The image features an illustration of a man wearing a suit and tie, climbing up a rope ladder while holding onto a monitor. The scene is set against a pink background with various computer screens displaying different graphs and charts. This unique combination of elements creates an interesting visual representation that could be used for advertising or as part of a creative project.](https://cdn.sanity.io/images/qd0fa73p/production/466d39489df614781a0dab50b8228bdb84b69b5d-2984x1679.png?w=1492&q=85&auto=format)

## [Design Debt on B2B Marketing Websites: Why AI-Built Campaign Pages Become Expensive to Maintain](https://www.darwinapps.com/blog/design-debt-on-b2b-marketing-websites-why-ai-built-campaign-pages-become-expensive-to-maintain/)