Short answer: an MCP server lets an AI assistant, such as Claude or ChatGPT, work with your Drupal site through named tools instead of guessing from the outside. Build it so the assistant can read before it can write: first tools that list and read, then write tools that a person confirms call by call, and publishing behind a separate permission. Credentials stay on the server, each token is issued for that server alone, and nothing an agent writes goes live without a person. Drupal already has contributed modules for this. As of 28 October 2026, all of them are in alpha or beta.
What is an MCP server, in plain terms?
The Model Context Protocol is, in its own documentation's words, "an open-source standard for connecting AI applications to external systems". An MCP server publishes a short list of tools. Each has a name, a description and a schema for its inputs. The assistant (the MCP client) reads the list, picks a tool and calls it. The server does the work and answers. For a Drupal site, a tool might be "list the content types", "load this page" or "save this draft".
The specification (version 2026-07-28) is clear about who stays in charge. It says there should always be "a human in the loop with the ability to deny tool invocations". It also says servers must validate every input, enforce access controls, rate-limit calls and clean their outputs.
Why it matters to you: an assistant connected through MCP stops guessing about your site and works from it. What it can do is exactly what the tools allow, so the list of tools is the security design.
Which Drupal modules exist for this today?
We read drupal.org's release feeds and code repositories on 28 October 2026. This is a status report, not a recommendation:
- MCP Server (
mcp_server): latest release 2.0.0-beta6, of 14 October 2026, for Drupal 10 and 11. It is built on the official MCP PHP SDK and speaks over the command line and over HTTP. Its endpoint needs its own permission. Its core ships no authentication: OAuth comes from a companion project, MCP Server OAuth, at 1.0.0-alpha1. - Model Context Protocol (
mcp): the latest tagged release is 1.2.3, of 14 November 2025. A 2.0 development branch rebuilds it on top of MCP Server, with three OAuth scopes (read, write, publish) and new content saved unpublished. No 2.0 release is tagged yet. - MCP Tools (
mcp_tools): 1.0.0-beta18, of 24 July 2026, a large library of tools. Its own README says it is designed mainly for local development and advises read-only mode on production. - MCP Client (
mcp_client): 1.0.0-alpha3, of 22 August 2026. It works the other way round: it lets Drupal's AI module call MCP servers outside the site.
None of them has a stable release. Names you may see suggested, such as ai_mcp or drupal_mcp, have no project on drupal.org.
Why it matters to you: the building blocks exist and they move fast. Which one fits depends on your site. An alpha or beta module needs someone who reads its changes before every update.
Why read tools first?
Because most of the value is in reading, and nearly all of the risk is in writing. An assistant that can list your content types, read a page and report what changed since the last deploy already answers most of what editors and developers ask about a site. None of that can break anything.
So we build in this order:
- Read tools. Describe the site's structure, load content, report configuration status. They run as a dedicated Drupal account whose role can only view.
- Write tools, behind approval. Create or edit content. Each call is confirmed by a person in the assistant before it runs, and the site saves the result as an unpublished draft or a new revision anyway. Live pages are not touched.
- Publishing, behind its own permission. A separate grant, or a person pressing Publish in Drupal's own editorial screen.
An agent does not change configuration (content types, fields, views) on production at all. On the sites we build, configuration lives in git and reaches production through tests and a deploy, so an agent's change to it is a change in the repository that a person reviews first.
Why it matters to you: a token that can only read can expose data, but it cannot vandalise your site. And because each step up is its own permission, you decide how far the assistant goes.
What does "writes behind approval" look like in practice?
The protocol leaves the confirmation screen to the assistant's app, so the server holds its own line as well:
- A person confirms every write. The assistant shows the call and its inputs, and nothing runs until someone says yes.
- Drafts by default. Even a confirmed write saves unpublished, so a mistake is a draft someone deletes, not a page the public saw.
- Narrow scopes. The MCP security guide recommends starting with a minimal set of low-risk read permissions and asking for more only when a privileged operation is first attempted. Read, write and publish are separate grants.
- The token is never bigger than the person. A call runs with the permissions of the Drupal account behind it, and Drupal itself checks them.
- Anything that sends or spends waits. Email, payments, calls to paid services: each one waits for an explicit yes.
- Every call is logged by tool name, without storing the content of each request unless you decide to.
- Tests and a README. Every tool has a test, and the server ships with setup notes for your team's assistant.
Where do the keys go?
Not into the model's context, and not into a file in your repository:
- Secrets by reference. The configuration says where a credential lives, a server environment variable or a protected file, and the server reads it when it runs. It never appears in exported configuration, in a prompt or in a log. On our own site, the voice agent's secrets come from the server's environment, and the configuration committed to git holds them empty.
- One token per server. The MCP security guide forbids "token passthrough": a server must not accept tokens that were not issued to it.
- Consent in the person's own browser. Where a service uses OAuth, the person signs in and approves once, and can revoke that approval at any time.
What has our founder built with these rules?
Our founder runs his own daily work through MCP, and his tools follow the same rules:
- dangler, public on GitHub, is one front door to a fleet of MCP servers. The assistant sees five small tools and loads a server's full tool list only when it needs it. Each server states whose account it acts as, holds its secrets by reference, and has a read-only switch wherever the service behind it can write.
- gws-mcp, his server for Google Docs, Sheets, Drive and Gmail drafts, asks only for the permissions its job needs. It has no write access to Drive at all, and it sends an email only as a draft that was already checked, never one written in the same call.
He holds Anthropic's MCP certification (May 2026). These tools are not Drupal modules, and our own site does not run an MCP server today. They are where the rules in this article were tested in daily use.
Why it matters to you: the pattern is not a slide. It is how the person who would build yours already works.
What we don't promise
Today the engineer is our founder. We build one MCP server per system and set its scope after discovery, because an MCP server is only as safe as the permissions behind it: every engagement starts by reading who can do what on your site. Support runs in business hours, Colombian time (UTC-5). The one fixed price is an hour of the founder's time: USD 75.
For the rest of the picture, read a Drupal AI agent that keeps its keys on the server and how we use AI, and where we don't let it act. To connect your assistant to your Drupal site, see what we offer or write to us.