Your Team Has Copilot. Your CMS Should Be Talking to It.

A Microsoft 365 Copilot license already grants Copilot Studio access, but the agent's tool calls consume separately purchased Copilot Credits, and the Drupal MCP Server module is still at alpha, so scope the first build as a pilot.

Two things arrived in the enterprise in the last eighteen months. An assistant rolled out across the workforce: 64% of organizations above 5,000 employees now run an active Microsoft 365 Copilot deployment, up from 40% at the end of 2024. And a named owner for AI: 38.5% of companies have appointed a Chief AI Officer or equivalent, up from 33.1% a year earlier. What almost none of them have is a website that either one can reach

That's no longer a technology gap. You can connect Copilot to Drupal today through the Model Context Protocol (MCP), the same standard Claude and ChatGPT speak, and the modules to do it are published on drupal.org.

The gap is a governance gap. And the organizations that hit it first are the ones whose publishing already runs through an approval chain: universities, grant-funded NGOs, government agencies, and publishers with legal review.

What Does It Mean to Connect Copilot to Drupal Through MCP?

Connecting Copilot to Drupal through MCP means running Drupal as an MCP server that exposes a scoped set of actions, such as "create a draft" or "check this field," which an external AI agent can call over an authenticated endpoint.

MCP is the open protocol for how an AI client discovers and invokes tools on a remote system. The client is the assistant. The server is your CMS. The tools are whatever you decide to expose, and nothing else.

Which Drupal Module Turns a Site Into an MCP Server?

On the Drupal side, the MCP Server module is the strategic choice. It's built on the official PHP MCP SDK, uses Tool API for tool discovery, manages tools as Drupal configuration entities rather than code, and authenticates with OAuth 2.1 through Simple OAuth 2.1.

Is It Production Ready Yet?

One caveat matters more than the rest: the module is at 2.0.0-alpha1 as of June 2026, on Drupal 10 and 11, with no supported stable release. That means it isn't covered by Drupal's security advisory policy yet. Pilot it. Don't put it under a production publishing workflow this quarter.

Which of the Two MCP Modules Should You Start With?

There's a second module worth knowing about, because confusing the two will cost your team a day. The older Model Context Protocol module (drupal/mcp) is merging into MCP Server. Until that lands, the difference matters more than the roadmap does.

MCP Server is the strategic choice and sits at alpha, outside security advisory coverage, on 90 reported installs. The older module is at 1.2.3, a stable release that is covered, on 319. Acquia's developer guide documents the older one, installs it with composer require 'drupal/mcp:^1.2', and points clients at /mcp/post; MCP Server exposes /_mcp.

Both work. They aren't interchangeable. And if security advisory coverage is a hard requirement for your pilot, that constraint decides which one you start with, not the merge plan.

Can Microsoft Copilot Publish to Drupal Today?

Microsoft Copilot can publish to Drupal today, but not from the Copilot window your staff already open. Someone has to build an agent first, and grant it far less than the ability to publish.

The path runs through Copilot Studio. An admin adds your Drupal MCP server to an agent using the MCP onboarding wizard, or registers it through Agents 365 for tenant-wide approval, and then publishes that agent into the Copilot surface your team already opens every morning.

Two technical constraints decide whether the connection works at all:

• Transport: Copilot Studio supports Streamable HTTP and dropped SSE support for MCP after August 2025. Any Drupal guide still describing an SSE endpoint is describing a connection Copilot Studio won't make.
• Authentication: The onboarding wizard offers None, API key, or OAuth 2.0. API keys are fine for a dev environment. Production means OAuth 2.0, and in this architecture, Drupal is the authorization server, not Entra ID: Simple OAuth 2.1 supports dynamic client registration with discovery, which is the simplest of Copilot Studio's three OAuth configurations.
  One governance point that rarely appears in the architecture diagrams: Copilot Studio reaches MCP servers through Power Platform connectors, so any Power Platform data policy you already run governs this connection too.

Then there's the part that rarely makes it into the rollout plan. Copilot Studio is not a separate license for a team that already has Microsoft 365 Copilot: a Microsoft 365 Copilot license is one of the entitlements that grants Copilot Studio access. What is separate is metered capacity.

Microsoft moved the currency from messages to Copilot Credits on 1 September 2025, sold as a 25,000-credit prepaid pack at $200 per tenant per month on an annual commitment, or roughly $0.01 per credit pay-as-you-go through an Azure subscription.

The pack is a tenant-wide pool and unused credits do not carry over. Inside Microsoft 365 surfaces, classic answers, generative answers, and Graph tenant grounding are zero-rated for Microsoft 365 Copilot-licensed users. Agent actions are not, and every call from an agent to your Drupal MCP server is an agent action. Budget from the credit billing rates rather than the headline pack size.

The identity, the governance, and the chat surface are already paid for. The tool calls that let an agent talk to your CMS are the new line item.

Worth saying plainly: we haven't found a public, named reference implementation of Copilot Studio calling a Drupal MCP server end to end. The architecture supports it. Treat the first one you build as a pilot, not a rollout.

What Changes for the Content Team?

The change for a content team is the removal of handoffs, not the generation of text. Most enterprise editorial teams already have AI drafting. What they don't have is an assistant that can put the draft where it belongs.

Picture an NGO communications lead with a funder-approved press release sitting in a Word document. Today she pastes it into the CMS, reformats it, fixes the heading levels, adds the boilerplate, checks the alt text, tags it, and sends a link to two people for sign-off.

With an agent connected over MCP, she hands the document to the assistant she already has open. The agent calls a Drupal tool to create the node in a Draft state, calls a second tool that checks the content against brand and editorial rules held in Drupal, and reports back what failed. A human moves it through the moderation transition to publish.

Notice what the agent never gets: the publish permission. The workflow state is the control, and it's a control Drupal has shipped for years.

One risk deserves naming here rather than in a footnote. That press release is untrusted input. Text embedded in a document an agent reads can become an instruction the agent follows, which is the reason an agent that ingests outside content should never hold the permission to publish it.

Why the Agent Never Gets the Publish Permission

Image

Where We Land: The Integration Is the Small Part

Our view: connecting an agent to Drupal is a modest engineering job. What takes months is that MCP forces an organization to write down an editorial permission model it has never made explicit.

In our work with universities and NGOs, "who may publish what" mostly lives in habit, a Slack channel, and the fact that only four people know how the release process works. That's tacit knowledge, and it's held together by the fact that every actor in the system is a human who can ask.

An agent can't ask. Every tool you expose over MCP is a written, machine-readable claim about what a non-human actor is permitted to do on your public website. Most enterprise Drupal sites have never had to make that claim in writing.

Which leads somewhere counterintuitive. The organizations best positioned to connect an agent safely are the ones with the heaviest approval chains: federal agencies, grant-funded nonprofits, and universities with legal and accessibility review baked into publishing. They already document who approves what, because an auditor asks them annually. That documentation is the input MCP tool scoping needs. The compliance burden turns out to be the asset.

The teams that will struggle are the fast, informal ones, where publishing is quick precisely because nobody wrote the rules down.

How Should You Decide What an Agent Is Allowed to Do?

Decide agent permissions per content type, not per platform. Run each content type through four questions before you expose a single tool:

1. Who signs off on this today, and is that signature recorded in the system or sitting in someone's inbox?
2. What does a wrong publish cost? A misstated grant figure and a typo in an events listing are not the same risk.
3. Can the change be reverted without a developer?
4. Does this content type ingest text from outside the organization?

Those answers place each content type on a permission ladder. Start every content type at Rung 1 and promote it only after the previous rung has run clean through a pilot.

Agent permission ladder by content type

The Never row isn't a caution; it's a hard line. Acquia's guide is blunt that the Drush plugin is development-only and should never be enabled in production, and the same reasoning applies to anonymous access to the MCP endpoint.

Three pilots follow from the ladder, and they sequence naturally over a quarter:

• Pilot 1, read-only audit. Expose read tools to Claude or Copilot for internal content auditing. No write scopes. This is where your team learns what the agent is actually good at, at zero publishing risk.
• Pilot 2, governed drafting. Add create-and-update tools that write into a Needs Review state, plus a validation tool that checks brand and accessibility rules. Humans still publish. This is where the time savings show up.
• Pilot 3, assisted publishing. Grant a publish transition for one low-consequence content type, with audit logging and a rehearsed rollback. Run it after MCP Server reaches a covered stable release, not before.

Instrument each pilot for the same three things: how often a human overrode the agent, what the validation tool caught, and how long a rollback actually took when someone tried one.

What Has to Be True Before You Start?

Five conditions have to hold before an agent should touch your CMS at all:

• Content moderation is configured with real states, not a publish checkbox
• Simple OAuth 2.1 is in place with per-tool scopes, and the endpoint is not open to anonymous access
• Someone has written the inventory of Tool API plugins you intend to expose, and someone senior has signed it
• Audit logging attributes actions to the agent's identity, not to a shared service account
• The Copilot Studio capacity and the tenant approval are budgeted and granted

Does the EU AI Act Apply to This?

If you publish into the EU, the AI Act's Article 50 transparency obligations became enforceable on 2 August 2026, so an agent that generates or manipulates published content is in scope today.

The high-risk timeline is decided rather than pending: the Council gave final approval on 29 June 2026 to the Digital Omnibus on AI, following Parliament's endorsement on 16 June, setting 2 December 2027 for stand-alone Annex III high-risk systems and 2 August 2028 for product-embedded Annex I systems.

Vardot is a Drupal Diamond Certified Partner and a Gold Sponsor of the Drupal AI Initiative, and we build platforms for organizations where publishing carries legal, funding, or accessibility consequences: 200+ launched, including work for UN agencies and research universities. Those are the same organizations that stand to gain the most from an agent and have the most to lose from a careless one.

The pilot sequence above maps to the Assure and Operate phases of our delivery system, which is where permission models get written down and evidenced.