WordPress, Django, and MCP: Where Each Boundary Belongs

Modified Mar 13, 2026

When WordPress, Django, a hosted assistant widget, and MCP servers appear in the same AI system, the fastest way to create confusion is to let every layer do everything. The cleaner architecture gives each layer a job and keeps the contracts explicit.

The practical architecture

For AI The Architect, WordPress should be the publishing surface. It owns public posts, pages, categories, navigation, SEO metadata, and article presentation. The hosted assistant widget can appear on the page, but the CMS should not become the assistant runtime.

Django, inside the AITokenGuard application, is the governed application runtime. It can own assistant packages, authenticated configuration, knowledge source publishing, conversation policy, citations, workspace permissions, and operational APIs. MCP servers then sit at the tool boundary, exposing specific capabilities to the AI workflow under those application controls.

Reader browser
  -> WordPress article page
  -> Hosted AITokenGuard widget
  -> Django assistant runtime and policy layer
  -> MCP server tool contracts
  -> Jira, docs, files, search indexes, or business APIs

WordPress publishes

WordPress is strong at editorial workflows. It should make the article easy to read, keep routes stable, manage topic archives, and provide metadata for search engines. It may include a script tag for a hosted widget, but it should not store private conversation state, route tool calls, or implement source-grounded answer logic.

Django governs

Django is the better place for authenticated workflows because it already understands users, tenants, packages, permissions, billing, source configuration, and audit data. If a site owner enables an AI The Architect assistant package, Django should decide what sources are available, which citations can be shown, and which actions require approval.

MCP integrates

MCP belongs at the boundary between AI workflows and external capabilities. A server might expose a document search tool, a Jira lookup tool, or a release evidence retrieval tool. Those tools should be narrow, observable, and governed by the policy layer before any sensitive backend is touched.

Example request path

A reader asks a question about an article. The WordPress page provides public article context and the hosted widget handles the interaction. Django decides whether the user is anonymous or authenticated, which AI package is active, and whether the question may use public article content only or additional private sources. If a tool is needed, the runtime calls an MCP server with a bounded request and stores the correlation ID.

The best integration is not the one with the fewest systems. It is the one where each system has a defensible reason to exist.

Boundary checklist

• Use WordPress for public content, archives, metadata, and stable URLs.
• Use Django for packages, users, source governance, policy, and conversation records.
• Use the hosted widget as the presentation bridge, not as a hidden runtime.
• Use MCP servers for explicit tool capabilities.
• Log correlation IDs across Django, MCP servers, and target systems.
• Keep private sources and credentials out of WordPress.

This split keeps the website maintainable and lets the AI platform evolve without turning the CMS into a second application runtime.