An MCP server for WordPress: the permission model that keeps an AI assistant out of trouble

The Model Context Protocol (MCP) is an open standard for connecting AI assistants such as Claude or ChatGPT to other systems through a fixed set of tools. Point it at a WordPress site and an assistant can draft a post, update a page, edit a WooCommerce product or upload an image.

That is useful, and it is also the moment to slow down. An assistant with an administrator login is a plugin installer, a theme editor and a user manager with no judgement. This post is about the permission model we use at Dzimark when we build an MCP server for WordPress, and why each piece is there.

1. A dedicated WordPress user per assistant

Each assistant gets its own WordPress user. Not a shared "bot" account, and never an administrator.

Why it matters:

• Every revision WordPress records is attributed to that user, so "who changed this?" has an answer.
• You can switch one assistant off without touching anyone else.
• The user's role caps what the assistant can do, even if the MCP server has a bug.

In practice that means a custom role with only the capabilities the job needs, for example edit_posts and upload_files for a content assistant, plus the WooCommerce product capabilities for a catalogue assistant. No install_plugins, edit_themes, manage_options, promote_users or edit_users.

2. Revocable credentials

The assistant connects with an application password or a token that can be revoked at any time. WordPress has supported application passwords for REST API access since version 5.6, which makes this simple: one credential per assistant, named so it is obvious in the user's profile, and deleted the day it is no longer needed.

Two rules we keep:

• The credential lives on the MCP server, never in the assistant's prompt or chat history.
• It is scoped to that one user, so a leaked credential can only do what that limited role can do.

3. A small, explicit tool list

An MCP server exposes tools, and the assistant can only call what you expose. So the safest tool is the one that doesn't exist.

A content assistant might get:

• create_draft(post_type, title, content, categories, tags, excerpt)
• update_draft(id, fields)
• list_posts(filters)
• upload_media(file, alt_text, caption)

A catalogue assistant might add product tools for descriptions, attributes and stock checks.

What it does not get: anything touching plugins, themes, settings or user accounts. If a task needs one of those, a person does it in the dashboard.

4. Draft first, publish by a person

By default every change lands as a draft. The assistant writes; an editor reads, edits and publishes in the normal WordPress screens.

This does two things. It keeps a human in charge of what readers and shoppers see, and it means your team doesn't need a new tool to review AI work: drafts show up where drafts always show up.

If a team later decides some low-risk jobs (say, filling in missing alt text) can go live directly, that is a deliberate change to one tool, not the default.

5. Revisions plus an audit log

WordPress revisions keep the earlier version of every post and page, so any edit can be rolled back. Revisions don't tell you why something changed, though, so the MCP server keeps its own log: which assistant made the change, when, which tool it called and at whose request.

That log is what you read when an editor asks, "Did the AI rewrite this paragraph, or did I?"

6. Staging before live

We set the server up against a staging copy of the site first and test every tool against the real content types: custom post types, ACF fields, WooCommerce variations, whatever the site actually uses. Only then does it connect to the live site.

This is also where you find the surprises, such as a page builder storing content somewhere the REST API doesn't expect.

Where this pays off

The jobs that benefit most are the slow, repetitive ones teams put off:

• refreshing older articles and their meta descriptions across a section
• writing or standardising product descriptions across a category
• filling in missing alt text and captions in the media library

Each is a long list of small edits, each edit is easy to review as a draft, and none of them needs an assistant that can install a plugin.

A short checklist

• [ ] One WordPress user per assistant, with a custom least-privilege role
• [ ] An application password or token per assistant, stored server-side, revocable
• [ ] Tools only for the content types and fields the job needs
• [ ] No tools for plugins, themes, settings or users
• [ ] Drafts by default; a person publishes
• [ ] Revisions on, plus an audit log of tool calls
• [ ] Tested on staging before it touches the live site

If you want the non-technical version of this for a client or a manager, the full write-up is on the Dzimark site: MCP server development for WordPress.