Building WordPress sites with AI agents: what MCP changes for developers

Building WordPress sites with AI agents: what MCP changes for developers

For years, “AI for WordPress” meant a chatbot that wrote blog posts. That has changed. AI coding agents in editors like VS Code can now connect to a live WordPress site and create pages, templates, global styles and components directly. I’ve rebuilt my own site this way, and it changes how I work.

The pieces

  • Model Context Protocol (MCP) is an open standard that lets AI assistants use external tools in a consistent way. A site exposes tools; the agent decides when to call them.
  • The WordPress Abilities API, added in WordPress 6.9, gives plugins a standard way to describe what they can do. The MCP Adapter plugin turns those abilities into MCP tools.
  • Builder integrations, such as Elementor’s MCP tools, expose actions like creating pages, building layouts, managing global variables and classes, and creating Theme Builder parts.
  • The agent (for example GitHub Copilot in agent mode, or Claude Code) reads your brief and files, plans, and calls the tools.
How an AI agent edits a WordPress site
The agent can only use the tools the MCP server exposes, and nothing goes live without review.

What works well

  • Design systems: creating global colors, fonts and classes from a stylesheet, consistently.
  • Rebuilding from a design: turning an HTML mockup into editable builder pages section by section.
  • Repetitive work: creating twenty similar landing pages, or updating a component everywhere.
  • Audits: reading page structures and listing what doesn’t match the design.

Where it struggles

  • Visual judgement: the agent can’t always see the rendered result. Screenshots and side-by-side checks are still your job.
  • Theme and plugin settings that aren’t exposed as tools, such as customizer options or caching configuration.
  • Ambiguous briefs: vague prompts produce vague pages.

Guardrails I use

  1. A rules file in the repository, such as .github/copilot-instructions.md, with the design system, naming rules and what the agent must never do.
  2. Drafts only: nothing is published without review.
  3. Plan first: the agent shows its plan, and I approve before it builds.
  4. Manual approval of every tool call that writes to the site.
  5. Backups before every session, and a staging site for anything risky.

Is this the future of WordPress development?

It’s a big productivity gain for the repetitive 70% of a build. The remaining 30% (design decisions, debugging, performance and judgement) is where experience still matters. If you’d like a site built this way, faster but still hand-checked, let’s talk.

Abul Faez

More about me
Rather not do this yourself?

Get a fixed-price speed fix, done on staging first.

See the speed service

Tell me what’s slow, broken or not built yet.

Book a free 30-minute call or send a short brief. You’ll get a clear plan and a fixed quote, usually within one working day.

MD Abul Faez Full-stack developer, replies within a few hours