Give a WordPress MCP client its own user and a separately revocable Application Password, then grant only the capabilities needed for its tasks. Expose only the MCP abilities it should use, and make each ability’s permission callback check the appropriate capability. A server-wide transport check is an additional gate, not a substitute for those per-ability checks.
How WordPress MCP permissions work
An MCP client makes requests as an authenticated WordPress user. The WordPress MCP Adapter maps registered WordPress abilities into MCP components; it does not create a universal “MCP role.” WordPress roles bundle capabilities, and capabilities are the permissions that determine what a user can do. As WordPress puts it, “User capabilities are the specific permissions that you assign to each user or to a User role.” WordPress roles and capabilities
The exact capabilities depend on the operation and on the abilities registered by WordPress core, the adapter, and installed plugins. There is no fixed capability list that fits every site. Review the permission callback for each ability you plan to expose.
Two checks protect an MCP operation
Current adapter documentation describes two authorization layers. A transport-level permission can restrict access to the MCP server as a whole. Each ability also has its own permission callback, which should enforce the capability appropriate to that specific operation. Both checks must fit the intended access: passing the transport gate does not authorize every ability.
#1 Best Overall
Exposure is a separate control from authorization. Adapter documentation describes abilities as opt-in for MCP exposure; an exposed ability still needs to authorize the current user. Remove abilities the client does not need, and do not rely on tool annotations such as “read-only” as security enforcement. Use server-side WordPress permission callbacks instead.
Choose access according to the client’s tasks
| Workflow | WordPress user access | MCP exposure and checks |
|---|---|---|
| Read public content | Public REST API data is generally available anonymously. If the workflow needs only public data, an authenticated user may not be necessary. | Expose only the relevant read abilities. Public REST access does not mean every MCP ability should be exposed. |
| Read private or protected content | Use authentication and grant only the capabilities required to access the relevant content. | Expose the required read abilities and retain their per-ability permission checks. |
| Create or modify content | Grant the capabilities needed for the specific write operations, not blanket administrator access. | Expose only the required write abilities and verify their callbacks reject unauthorized requests. |
| Manage WooCommerce data | Follow WooCommerce’s recommendation to use a dedicated WordPress user with only the capabilities the client needs. | Review the WooCommerce abilities’ own permission callbacks; user access alone does not replace them. |
WordPress describes the REST API as providing “public data accessible to any client anonymously, as well as private data only available after authentication.” REST API authentication The REST API supports content creation and modification subject to authentication and permissions; the precise checks depend on the endpoint or ability. For example, adapter documentation describes GET for read-only abilities, POST for regular input-taking abilities, and DELETE for destructive abilities on its Abilities API endpoints.
Quick Recap
Set up a dedicated user and credential
- List the operations. Specify what the client must do, such as read published posts, access private content, create drafts, upload media, or manage store data. Avoid granting permissions for tasks it will not perform.
- Create a dedicated WordPress user. Assign the narrowest role or direct capabilities that support those operations. Do not use an administrator account by default; roles are capability bundles, so check the capabilities actually assigned to the account.
- Create an Application Password for the integration. Name it so you can identify its purpose and revoke it independently. WordPress describes these as “revocable, per-application credentials for programmatic access.” Application Passwords
- Use the credential only over HTTPS. Application Passwords authenticate requests as their associated WordPress user; they do not narrow that user’s capabilities. WordPress advises HTTPS because Basic Authentication credentials can otherwise be intercepted. Application Passwords are available by default for HTTPS requests, though site code or security plugins can disable or restrict them.
- Review both MCP authorization layers. Check the transport-level permission, then inspect the permission callback for every exposed ability. Remove abilities outside the task list.
- Test allowed and denied operations. Verify intended tasks work as this user and that an unneeded operation is rejected. Revisit capabilities, exposure, and callbacks when workflows or installed plugins change.
What to verify on your site
- Installed adapter release: Adapter behavior and documentation can change. Check the documentation for the release installed on your site; repository trunk documentation may not match it.
- Registered abilities: Review abilities from the adapter, WordPress core, WooCommerce, and other plugins, including their permission callbacks and exposure metadata.
- Authentication configuration: WordPress’s developer blog describes Application Passwords as the adapter’s default authentication method, while noting that OAuth or other methods can be implemented. Sites may customize authentication.
- REST API safeguards: Do not disable the REST API as a broad security measure. WordPress warns that doing so can break administrative functionality that relies on it. Protect access through authentication and authorization instead.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
