Key Takeaways
- There are three practical ways AI can interact with a WordPress site today: the REST API, the Model Context Protocol (MCP), and SSH combined with WP-CLI. Each has distinct strengths and trade-offs.
- WordPress is officially investing in MCP: The WordPress Abilities API (shipped in WordPress 6.9) and the official MCP Adapter mean AI agents can now discover and execute WordPress functionality through a standardised protocol.
- SSH with WP-CLI remains the most powerful option: It provides unrestricted access to both WordPress and the underlying server, making it my preferred approach for AI-assisted site management and deployment.
- This is already changing how I build websites: AI agents in development environments like VS Code can now research, code, deploy, and manage entire WordPress sites through these interfaces — reducing costs and development time for clients.
There is a practical conversation happening in web development right now that will affect your website directly: how AI tools actually connect to and manage WordPress sites. Not chatbots or image generators — the real infrastructure that lets AI create content, deploy code, and diagnose problems on a live website.I use AI agents to build, deploy, and maintain client websites every day. In my previous article on AI coding agents, I covered how these tools have changed development costs and timelines. This article goes deeper — into the three specific methods AI uses to interact with WordPress, and why the choice matters.
Why AI Needs a Way In
AI models like Claude, ChatGPT, and Gemini are remarkably capable at generating code and content. But to actually publish a blog post, update a page, or diagnose a server issue, the AI needs a structured connection to your WordPress installation. There are currently three meaningful options: the REST API, the Model Context Protocol (MCP), and SSH combined with WP-CLI. I have used all three extensively.The REST API: The Oldest Route
The WordPress REST API has been part of core since version 4.7 in 2016. It exposes your site's content as structured JSON data that any application can read and write via HTTP requests. For AI integration, it can work — an AI agent could use it to create posts, update content, or retrieve site data. But I have a love-hate relationship with the REST API.The endpoint exposure problem. By default, WordPress broadcasts a complete list of all available API endpoints at/wp-json/. Anyone can visit that URL and see exactly what your site exposes. While this is by design — REST APIs are meant to be discoverable — it gives potential attackers a detailed map of your site's surface area. You can restrict this, but it requires additional code or plugins, and most site owners never think to do it.Server caching conflicts. This one frustrates me regularly. Many hosting providers and caching plugins aggressively cache API responses by default. When you update content through the REST API, the cached response still serves the old data until the cache expires or is manually purged. For AI-driven workflows where you need to write content and immediately verify it was published correctly, this creates unreliable feedback loops. You can configure cache exclusions for API routes, but it is another layer of complexity that should not be necessary.Authentication complexity. Application passwords work, but managing them securely across multiple AI tools requires care. Every tool needs its own credential, and if any one is compromised, you need to revoke and regenerate.The REST API was designed for web applications to consume WordPress data, not for AI agents to manage entire sites. You can make it work, but you are fighting the tool rather than using it naturally.MCP: The New Standard
The Model Context Protocol (MCP) is an open standard created by Anthropic in November 2024 to solve exactly this problem. Think of it as USB-C for AI — instead of every tool needing a custom integration for every data source, MCP provides one standardised protocol.WordPress has officially embraced it. The Abilities API, shipped with WordPress 6.9, lets core and plugins declare what they can do. The official WordPress MCP Adapter (February 2026) bridges those Abilities to MCP — meaning AI agents like Claude Desktop, VS Code Copilot, and Cursor can discover and execute WordPress functionality directly. WordPress.com has gone further, adding OAuth 2.1 authentication that makes connecting an AI agent as simple as adding a URL and approving access.This is the right direction. But for self-hosted WordPress — which is what most of my small business clients run — there are practical limitations.What MCP does well
Standardisation. A single protocol that works across multiple AI platforms is genuinely valuable. Build one MCP server, and Claude, ChatGPT, Cursor, and VS Code can all use it. That is a major improvement over building separate integrations for each tool.Security model. MCP connections use proper authentication — OAuth 2.1 on WordPress.com, or application passwords for self-hosted sites. Permission callbacks control what each AI agent can actually do. This is well-designed security.Discovery. AI agents can query what Abilities are available before trying to use them. This "discover, then execute" pattern reduces errors and lets the AI choose the right tool for each task.Where MCP has friction
You are limited to what has been coded. WordPress 6.9 ships with only three default Abilities: getting site info, user info, and environment info. That is a foundation, not a feature set. For anything beyond basic diagnostics, you need plugins that register their own Abilities — and those plugins are still being developed.Remote connections need Node.js. For local WordPress, the MCP Adapter uses WP-CLI directly, which is straightforward. But for production sites, you need the@automattic/mcp-wordpress-remote npm package, which requires Node.js on your local machine.Self-hosted OAuth is not solved yet. WordPress.com has elegant OAuth 2.1 built in. Self-hosted WordPress currently relies on application passwords or JWT tokens. As confirmed on the official developer blog, full OAuth for self-hosted sites is not yet available.Plugin dependency. If you need AI to manage WooCommerce orders or update custom fields, you need those plugin developers to expose their functionality as MCP Abilities. Until they do, MCP cannot reach those parts of your site.In two or three years, I expect MCP will be the default way AI interacts with WordPress. But right now, for the kind of deep site management I do daily, it is not yet sufficient on its own.SSH with WP-CLI: The Power Tool
WP-CLI is the official command-line interface for WordPress — it lets you do everything the admin dashboard does, and more, from a terminal. SSH (Secure Shell) is the protocol for securely connecting to a remote server. Combine them, and you get unrestricted, secure access to both WordPress and the underlying server. For AI-assisted site management, this combination is extraordinarily powerful.Why SSH with WP-CLI wins for me
No artificial limitations. Unlike the REST API (limited to exposed endpoints) or MCP (limited to coded Abilities), SSH with WP-CLI gives AI access to everything. Create a custom post type entry, run a complex database query across ten tables, check server email configuration, modify a PHP file, regenerate image thumbnails, inspect error logs — all from the same interface. The AI is not constrained by what a plugin developer anticipated you might need.Beyond WordPress. This is the critical differentiator. SSH does not just give you WordPress access — it gives you server access. When a client's emails stop arriving, the AI can check the mail queue, inspect DNS records, verify SPF and DKIM configuration, and fix the problem. When a page loads slowly, the AI can check server resource usage, analyse Apache logs, and identify the bottleneck. Try doing that through a REST API endpoint.Code deployment. AI agents in development environments like VS Code can write code locally, test it, then deploy it to production via SSH — transferring files, running deploy scripts, and verifying the result in one continuous workflow. This is how I build entire websites now. The AI codes the HTML and CSS, I review and refine the architecture, and we deploy through SSH. No FTP, no cPanel file manager, no manual uploads.Security. SSH key authentication is among the strongest authentication methods available. You generate a cryptographic key pair — a private key stays on your machine, the public key goes on the server. No passwords are transmitted. Combined with server-level IP whitelisting (only approved IP addresses can even attempt to connect), this is significantly more secure than any token-based API authentication. My hosting provider also runs SSH on a non-standard port, adding another layer of obscurity.The trade-offs
SSH with WP-CLI is not for everyone. It requires a developer who understands server administration, command-line interfaces, and the consequences of running commands with full server access. An AI agent with SSH access could, if poorly instructed, delete files, drop database tables, or misconfigure the server. This power demands expertise and careful oversight.It is also not a user-facing tool. You would not give a client SSH access to manage their own site. For that, WordPress's dashboard — potentially enhanced with MCP-enabled AI features — is the right interface.But for a developer using AI to build, deploy, and maintain client websites? SSH with WP-CLI is the most capable tool available today, and it is the backbone of my current workflow.How This Works in Practice
To make this concrete, here is how a typical development session works for me now.I work in VS Code with an AI coding agent (currently Claude via GitHub Copilot). The AI has access to my project files, a set of architectural guidelines I have written, and an SSH connection to the production server. A typical sequence looks like this:- Research. I give the AI a topic — say, a new service page or blog article. The AI researches the topic online, gathering facts and sources from authoritative sites.
- Content creation. Following my writing guidelines and brand voice, the AI drafts the content as semantic HTML — headings, paragraphs, lists, links. No page builder needed.
- Design implementation. The AI writes the CSS, using our design tokens and component library. It follows my architectural standards — no inline styles, no jQuery, mobile-first responsive design.
- Local testing. I review the work locally, checking design, content accuracy, and code quality. The AI takes feedback and iterates.
- Deployment. Via SSH, the AI transfers files to the production server using base64 encoding (to prevent character corruption), runs deploy scripts via WP-CLI, and verifies the deployment by checking the live output.
- Verification. The AI confirms the content is live, the cache is purged, and everything renders correctly.
