WordPress gives an AI two ways in: the REST API with an Application Password, or an MCP plugin that signs in with OAuth. Both can put an AI to work on your site. The difference that matters is the credential you hand over: what it can do, how long it lasts, and the record it leaves behind.
If you have been weighing AI assistants for WordPress, this is the MCP vs API question in practice: keep using the REST API password your AI can already handle, or add an MCP plugin that gives each connection an access level and keeps a change record. The overview comes first, then the five situations where the difference shows.
The two options, side by side
Application Passwords are built into WordPress core and have shipped with it since version 5.6. You generate them per user on the profile screen, and each one authenticates REST API requests over HTTPS. Where XML-RPC is enabled, the same password also works for that legacy API in place of the account’s real password. WordPress documents it in the REST API authentication handbook.
MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems. Where an API exposes endpoints for code to call, an MCP server exposes named tools with descriptions that an AI client discovers and calls, and it often sits on top of an existing API. For servers reached over HTTP, its optional authorization spec builds on OAuth 2.1 and recommends short-lived access tokens. New to the acronym? Start with what MCP means for WordPress.
On WordPress, the MCP route is a plugin such as Easy MCP AI. It runs inside your site: the AI signs in with OAuth on a consent screen, each connection gets an access level you choose (never more than the WordPress account behind it can do), and each access token lasts 1 hour.
Easy MCP AI is made by Themeisle, the company behind this blog.
The line “MCP is just another API” is half right, since many MCP servers wrap one. On a WordPress site, what separates the two routes is the credential, its limits, and the record it leaves:
| REST API + Application Password | MCP plugin (Easy MCP AI) | |
|---|---|---|
| Credential | A password generated for one user account | An OAuth connection approved on a consent screen |
| What it can do | Everything that user can do via the REST API; no per-password scope | Capped by the access level you picked and what the WordPress account can do |
| Expiry | None; works until revoked | Access tokens last 1 hour and refresh; refresh tokens last 30 days; revocable anytime |
| Record on the site | Post revisions, plus a Last Used date and IP | Revisions, an audit row per call, and a change history of every write |
| After removing the plugin | Still works; it is part of WordPress core | Connections and data removed with it |
| Built for | Scripts, apps and fixed workflows | AI clients editing the site |
Your AI can already use the REST API
Chat apps that can run code, such as claude.ai and ChatGPT, can call your REST API themselves if you paste an Application Password into the chat. No plugin to install, no new protocol to learn: generate the password, paste it, describe the job. To connect Claude to your site without pasting a password, see how Claude connectors work.
The cost sits in the credential. That password is unscoped, so the chat can do anything the account can do through the REST API. It has no expiry. It stays in the chat history. And once the job is done, WordPress core keeps no record of what the AI changed beyond the usual post revisions: the password’s only trace is a Last Used date and IP, and several apps sharing one password overwrite each other’s trace.
claude.ai itself has suggested revoking an Application Password after it was shared in a chat. Sound advice, as long as someone remembers to follow it.
⚠️ NOTE: an Application Password can’t open wp-admin, which sounds reassuring. Through the REST API, though, it can do whatever its user can do through that API. Treat it with the same care as the account’s real password.
You run a WooCommerce store 🛒
Raw REST calls do exactly what they say, including the part you didn’t mean. WooCommerce’s product endpoint replaces the whole category list when you send categories, so asking an AI to add a product to a category can quietly drop the ones it already had, unless the request includes them too.
Easy MCP AI’s category tool adds a category and keeps the ones the product already has. Every write through it also lands in the change history with the tool, the time and the account behind it, kept for 30 days by default, so you can see what the AI touched and when.
You automate with n8n, Zapier or scripts
If the workflow does the same thing every time and no AI is deciding anything, REST plus an Application Password is the right tool. For ideas, see these WordPress Zapier recipes.
💡 PRO TIP: create a dedicated user account for the automation and give it the lowest role that still works. The password inherits that role, so a leaked password can only do what the role allows.
Someone else needs AI access
A writer, a VA or a client sometimes needs an AI working on your site. With an Application Password, the credential inherits that person’s whole user role, and there is no way to narrow a single password today: WordPress says scoping is expected “in future versions“.
Easy MCP AI handles this on its consent screen. Each connection picks an access level: Full access, Match a role (such as Editor or Author), Read-only, or Custom, and none of them goes beyond what the WordPress account behind it can do. An optional approvals setting can hold destructive actions until a person approves them, and you can revoke a connection without touching anyone’s password. It also refuses to create Application Passwords through its tools, because a new password would outlive the connection and bypass its tool list.
When you stop using it
An Application Password lives in WordPress core, so removing any plugin leaves it working. It works until you revoke it on the user’s Edit User or Profile screen, one by one or with “Revoke all application passwords”.
Removing Easy MCP AI runs the other way: uninstalling it removes its connections and data, its endpoint returns a 404, and its tokens die with it.
When the REST API is the better choice
Some situations belong to the plain REST route:
- Nothing about the job changes from run to run, so a fixed request is all it needs.
- You are a developer working in an agent that can run code, and you would rather write the requests yourself.
- No plugin may be installed on the site.
And this isn’t a one-way decision. Easy MCP AI itself ships REST read and write tools, so an MCP connection can still make a plain REST call when that’s the right tool for the job. 👍
The quick chooser 🧭
One line per situation:
| Situation | REST API + Application Password | MCP plugin |
|---|---|---|
| Your chat app can run code | Works today with a pasted password; revoke it afterwards | OAuth on the site’s consent screen, plus an access level and a record |
| WooCommerce store edits | The product endpoint replaces the category list; send the existing ones too | A category tool that keeps existing ones, and a record of every write |
| Fixed automations | The right tool; use a dedicated low-role user | Also works, through Easy MCP AI’s REST read and write tools |
| Access for a writer, VA or client | Inherits the whole role, nothing narrower | Pick an access level on the consent screen; revoke anytime |
| A clean exit | Revoke passwords one by one, or all of a user’s at once | Removing the plugin removes its connections |
Whichever route you pick, the checklist stays short: know what the credential can do, know how long it lasts, and know what record it leaves. If the MCP route fits your site, see the best WordPress MCP server plugins. Which setup are you running? Let us know in the comments section below! 👋
FREE GUIDE
4 Essential Steps to Speed Up Your WordPress Website
Follow the simple steps in our 4-part mini series and reduce your loading times by 50-80%. 🚀
