I Wired My Coding Agent Into a Live Drupal Site via MCP

I already run this blog on a headless-ish Drupal with a JSON:API that an agent writes into, so I thought I knew what "AI on Drupal" felt like. I was wrong. The AI module ecosystem now ships something stranger: a Model Context Protocol server that hands a coding agent a live steering wheel to your site's structure. I spent a weekend pointing my own agent at a dev copy. Here are the field notes.

What the AI module actually is

The drupal/ai module is not a chatbot. It is a provider-agnostic framework: a common abstraction over LLM backends plus an Operations/Tool layer that other modules build on. It is mature by contrib standards, currently on stable 1.4.x/1.3.x, targeting Drupal 10.5+ and 11.2+, covered by the Drupal Security Team, and reporting roughly 18,346 sites. That last number matters later.

AI Agents: text-to-action, configured in the UI

The AI Agents module (~11,541 sites, stable 1.3.2) is the interesting part. It ships "text-to-action" agents that manipulate real configuration, not just prose:

• Content Type Agent — creates, edits and reasons about node types.
• Field Type Agent — "add an image field called My Images to the Page type" and it does it.
• Taxonomy Agent — spins up vocabularies and terms.

You assemble new agents with no code at /admin/config/ai/agents by giving a title, a system prompt and a set of allowed tools. There is a Modeler API built on BPMN.io for graph-based, ECA-style workflows, and an AI Agents Explorer for debugging what the model actually decided. It is being folded into AI core for the 2.0 release.

The MCP server: your coding agent, meet Drupal

The bit I actually wanted was the MCP layer. It exposes Drupal's Tool API operations over the Model Context Protocol (JSON-RPC), so any MCP client — Claude, Cursor, VS Code, Cline — can discover and call them. Install is ordinary Composer:

composer require "drupal/ai:^1.4" "drupal/ai_agents:^1.3" "drupal/mcp:^1.2"
drush en ai ai_agents mcp -y
drush role:perm:add authenticated "use mcp server"

Then you register the server with your client. This is the bridge config I ran — note the two lines I've flagged below:

{
  "mcpServers": {
    "drupal": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "DRUPAL_AUTH_USER",
        "-e", "DRUPAL_AUTH_PASSWORD",
        "ghcr.io/omedia/mcp-server-drupal:latest",
        "--drupal-url=https://mysite.ddev.site",
        "--unsafe-net"
      ],
      "env": {
        "DRUPAL_AUTH_USER": "mcp_user",
        "DRUPAL_AUTH_PASSWORD": "change_me"
      }
    }
  }
}

Within minutes my agent had enumerated the tools and, on request, created a content type and a field on the running site. It genuinely works.

Now the honest part: the governance gaps

Compare the install counts. AI core sits near 18k sites; the standalone drupal/mcp module reports about 319, and it is still mid-merge with the AI module's own MCP Server submodule. The agent layer is production-grade; the exposure layer is early. That asymmetry is the whole story.

Three things stopped me pointing this at production:

1. Coarse permissions. Access hinges on a single "use mcp server" permission plus per-tool toggles. That is a capability grant, not an audit trail. There is no meaningful "the agent proposed X, a human approved X" gate in the box.
2. The config I pasted above. --unsafe-net and HTTP basic auth are fine on ddev.site; on a real host they are how you leak an admin-adjacent credential. OAuth 2.1 is the recommended path for remote servers — use it, don't cut the corner.
3. Prompt injection reaches your schema. An agent that can create content types is an agent that a poisoned document can talk into creating content types. Text-to-action collapses the gap between "summarize this" and "restructure my site."

An agent that can create content types is one a poisoned input can talk into creating content types. That's not a bug in the module — it's the feature, pointed the wrong way.

My rule after the weekend: MCP against a throwaway or staging clone, credentials scoped to a purpose-built role, every structural change reviewed as config in Git before it goes near prod. The demos are real. The blast radius is also real.

If you want the official vision — and it is a good one — Dries covers Canvas and AI site-building here:

Links

• AI module on drupal.org
• AI Agents module on drupal.org
• MCP / Model Context Protocol module
• Drupal MCP documentation
• DriesNote, DrupalCon Vienna 2025