WordPress content tool reference
Thirteen tools for posts, pages and public custom post types. They are the most used group in the server and the one whose writes are most visible.
The tools
Reading
| Tool | Does |
|---|---|
wp_get_posts |
List posts and public custom post types |
wp_get_post |
Read one post |
wp_get_pages |
List pages |
wp_get_page |
Read one page |
wp_count_posts |
Count by status |
wp_get_post_types |
List public post types |
wp_search |
Search public content |
Writing
| Tool | Does |
|---|---|
wp_create_post |
Create a post |
wp_update_post |
Update a post |
wp_delete_post |
Trash or delete a post |
wp_create_page |
Create a page |
wp_update_page |
Update a page |
wp_delete_page |
Trash or delete a page |
Pages are posts
The six page tools are thin wrappers around the post tools with post_type fixed to page. Same arguments, same behaviour, same responses.
They exist so a client can express intent clearly. Where this reference describes wp_get_posts, the page equivalent behaves identically.
What they can reach
Only public post types. A post type registered as non-public is refused with pom_ai_mcp_post_type_denied, and does not appear in wp_get_post_types.
Reading a published item needs no capability beyond authentication. Reading anything else — drafts, private, pending — requires edit_post on that item, or edit_posts/edit_pages for a listing.
That asymmetry is worth knowing: a read-only token can list published content but not drafts.
Permissions for writes
All writes need Allow content writes open, plus:
| Tool | Capability |
|---|---|
| Create | edit_posts, or edit_pages for pages |
| Update | edit_post on that specific item |
| Delete | delete_post on that specific item |
Scopes: mcp:read, mcp:write, wp:content:read, wp:content:write.
The response shape
Every tool returning a post returns the same fields: id, post_type, title, slug, status, date, modified, link and excerpt.
Single-item reads and write responses also include content. Listings do not — a design choice that keeps a page of results manageable, and one to remember when an assistant claims to have read the content of twenty posts from one listing call.
Dry runs
wp_create_post, wp_update_post and wp_delete_post all support dry_run, along with their page equivalents:
- create returns
would_createwith the payload; - update returns
beforeandafter; - delete returns
would_deletewith the record.
The update comparison is the most useful of the three. Use it for anything published.
Status behaviour
Creating without a status produces a draft. That is the safe default and it means an assistant cannot publish by omission.
Updating without a status leaves the stored status unchanged. Changing status is an explicit act — pass status when you mean to publish or unpublish.
Pagination
Listings take page and per_page. per_page is clamped between 1 and 100, defaulting to 20, so a request for everything returns at most a hundred items with a total telling you the real size.
Read the total. An assistant that processed "all the posts" from one call processed at most a hundred.
Related
- Create and review a post
- Update a page safely
- Build POM builder content
- Comment and meta tools for post meta and SEO fields