Managing Drupal content with ChatGPT and MCP
š§ Listen to every article back to back
Drupal content can be managed by machines without giving up human control. The key is not to hand ChatGPT the full admin interface, but to expose narrow MCP tools: find an article, open a draft, propose a change, validate it, show the diff and let a human approve publishing.
# Managing Drupal content with ChatGPT and MCP
ChatGPT, Claude, Codex and other AI tools do not have to stop at writing text in a chat window. With the right interface, they can request context from a website, find existing content, suggest edits and prepare changes.
This is especially interesting with Drupal because Drupal content is usually already structured: content types, fields, translations, roles, permissions, workflows, revisions and logs. That does not mean AI should freely click around the admin interface. The opposite is true. The more capable the agent, the narrower and clearer its tools need to be.
WebPro recently built a local MCP workflow for its own site, allowing ChatGPT or Codex to manage blog articles through domain-specific tools. It does not give the model arbitrary filesystem access, shell access or production access. The tools are limited to blog source files, and every change still has to pass validation, build, tests, commit, backup and deployment.
This is a practical example of the same direction covered in the article about AI agents, Drupal and LLM/GEO readiness. Agent readiness does not only mean that a page is readable by machines. It also means a machine can act only inside the boundaries we deliberately expose.
What MCP Means Here
Model Context Protocol (opens in a new tab), or MCP, is a way for an AI application to connect to external systems and tools. The specification separates capabilities into three broad types: resources provide context and data, prompts describe reusable workflows, and tools are functions the model can call.
OpenAI's documentation describes the same direction from the ChatGPT side: MCP-powered apps can let ChatGPT take action in company tools, including write or modify actions in some contexts. The same documentation also stresses testing, permissions and review before such tools are deployed to a workspace. This is not a normal "give it the password and see what happens" integration.
OpenAI, Anthropic and Cursor: The Same Direction on Different Surfaces
It is not useful to discuss this through only one AI tool. The same editorial workflow can move through several working surfaces.
OpenAI's ChatGPT developer mode (opens in a new tab) fits cases where an editor or project manager wants to work through conversation: find old service pages, suggest better metadata, prepare a draft and ask for confirmation before applying a change. OpenAI's own documentation is clear that write and modify actions require permissions, confirmations and workspace-level review.
Anthropic introduced MCP (opens in a new tab) as an open standard for connecting AI applications to data sources and tools more safely. In Claude and Claude Code style workflows, this is especially useful when an agent needs to read project context, understand the content model and propose a change that a developer or editor reviews before applying.
Cursor's MCP support (opens in a new tab) is closer to the developer surface. When Drupal content logic, migration scripts, JSON:API endpoints or custom admin tools live in the codebase, Cursor can connect external context and the development environment through MCP. It does not replace the editor, but it can help a developer build better tools that editors later use safely.
The practical difference is straightforward:
- ChatGPT fits editorial and project-management conversations;
- Claude or Codex fits longer analysis, code changes and controlled agent workflows;
- Cursor fits the developer editor, where MCP can connect code, documentation and tools.
For a Drupal site, the question is not "which model wins". The question is whether OpenAI, Anthropic or Cursor can all operate through the same limited, auditable tool layer. If the tool layer is good, the AI client behind it can change over time.
For Drupal, MCP is useful precisely because we do not need to connect an agent to the generic admin UI. We can build tools that speak the language of the Drupal content model:
- find articles by topic, language or status;
- open a specific article with its metadata and body;
- create a new draft;
- update only allowed fields;
- check whether a translation and alternate URL exist;
- validate content rules;
- show a preview;
- propose publishing only after tests pass.
That limitation is not a drawback. It is the safety boundary of the workflow.
The Bad Version: AI as an Admin User
The simplest but weakest idea is to give AI a normal administrator account and let it fill forms in the browser.
That may work in a demo, but real websites quickly expose the problems:
- the agent sees more than it needs;
- every UI change can break the workflow;
- it is hard to separate content mistakes from technical mistakes;
- the reason for a change may not be recorded in an audit trail;
- permissions depend too much on a broad admin role;
- humans often see the result only after it has already been saved.
Drupal's admin interface is designed for humans. An AI agent needs a different surface: a small set of well-described tools with machine-readable input and output.
The Better Version: Domain-Specific Tools
In WebPro's blog MCP workflow, the tools are named in editorial terms, not server or filesystem terms. For example, an agent can find articles, open a specific article, create a draft, update allowed fields, validate content, show a preview and propose publishing or unpublishing.
That distinction matters. If an agent receives the instruction "fix this paragraph in the Estonian article and keep the English version equivalent", it does not need server commands, file-copy access, a database client or an arbitrary HTTP client. It needs a tool that understands an article as an article.
A good MCP tool for Drupal content should do less, but do it more precisely:
- limit which content types can be changed;
- require language and slug to be explicit;
- return a revision or other lock token;
- allow an update only when the revision still matches;
- validate metadata, fields and required links;
- create drafts by default, not published content;
- log who or what initiated the change;
- keep a clear review point for a human.
In our own implementation, write tools do not have access to the whole project. They can work only with the Estonian and English blog Markdown files. New articles start as drafts. Existing article updates use optimistic locking: the agent must first read the article's current revision and include it when updating. If someone else changed the article in the meantime, the conflict is surfaced instead of silently overwriting work.
Drupal Adds Workflow and Permissions
When applying the same idea directly to a Drupal site, the important starting point is not ChatGPT. It is Drupal's content model.
Drupal core's Content Moderation (opens in a new tab) and Workflows features allow content states and transitions: for example draft, review, published and archived. An agent does not need publishing rights. It may create a draft, improve metadata, suggest a translation or mark a page for review.
A practical permission model could look like this:
- the AI agent can read public and approved internal context;
- the AI agent can create a draft or change proposal;
- the AI agent cannot change user permissions, configuration or modules;
- the AI agent cannot publish without human approval;
- the editor sees the diff and decides;
- development or maintenance changes still go through the normal release process.
This model is especially useful for organisations with multiple languages, many service descriptions, recurring metadata, ageing documentation or a large editorial team. The agent helps maintain consistency, but it does not take over responsibility.
What ChatGPT Can Actually Do With Drupal Content
When the tools are designed well, ChatGPT can help with very practical editorial work.
Finding content. "Find every service page that mentions Drupal 7 migration but does not link to the audit page." The agent does not have to search only raw text. It can use content type, language, taxonomy and fields.
Cleaning up metadata. Many sites have inconsistent meta descriptions. An agent can suggest better descriptions, while the tool limits length, checks duplication and shows the change before it is saved.
Comparing translations. On multilingual Drupal sites, the agent can compare Estonian and English versions and flag factual differences. That does not mean overwriting one translation with another. It means making mismatches visible.
Finding outdated information. If an article contains an old version number, date or service description, the agent can surface it. Publishing still belongs to a human.
Checking accessibility and structure. The agent can check whether images have alt text, headings are in a logical order, tables need explanation and link labels make sense.
Building an editorial worklist. The agent can prepare a list of pages needing review: thin service pages, old news, broken references, missing translations or repeated headings.
These are tasks where AI does not need to be a creative author. It needs to be a consistent assistant that can inspect a large content base and propose controlled changes.
What Should Not Be Opened to AI?
The most important boundaries should be written down before the first MCP tool is built.
By default, an AI agent should not be able to:
- change roles and permissions;
- install or remove modules;
- run arbitrary commands on the server;
- read personal data or sensitive form submissions;
- change payment, login or integration settings;
- publish critical content without review;
- delete content without a recovery path.
If any of these actions is genuinely needed, it should have a separate narrow tool, a separate permission and a very clear audit trail.
How to Start
The best first step is not a large AI programme. Start with one workflow where the value is clear and the risk is contained.
Examples:
- reviewing metadata for articles or service pages;
- checking differences between translations;
- finding outdated Drupal version references;
- creating a draft from an existing content model;
- generating a preview and diff before publication.
Technically this can work in several ways. On a static site, an MCP tool may edit Markdown source files. On a Drupal site, the tool may talk to JSON:API, a custom endpoint or Drupal's own content logic. The important point is not the exact integration layer. The important point is that the agent does not operate outside the content model, permissions and workflow.
Summary
Managing Drupal content with ChatGPT and MCP does not mean turning AI into an administrator. A good implementation does the opposite: it removes generic admin access and replaces it with small, precise, auditable tools.
Drupal is a strong fit because it already has content models, roles, permissions, workflows, revisions, multilingual support and APIs. MCP makes those capabilities understandable and usable for AI agents.
WebPro helps Drupal site owners plan, audit and build these workflows. A good starting point is a Drupal audit or an AI and Drupal workflow review: what content a machine may read, what it may change and where a human decision must remain in the process.
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.