Skip to main content
Glama

Change the status of many posts

wp_bulk_update_status
Destructive

Update the status of up to 500 posts, pages, or media files at once by ID list to publish, draft, pending, private, or trash, with unknown IDs skipped and per-post results returned.

Instructions

Change the status of many posts at once by id list (posts, pages, other post types and media files alike) to publish, draft, pending, private or trash; at most 500 ids per call (over_limit counts the rest, which are not touched). Suited to batches; one post's status and other fields change with wp_update_post. Unknown ids are skipped, posts already in the status are left as they are and an id given twice counts once, so a repeated call changes nothing more, except where WordPress stores another form than asked (stored_as below): those posts are written again. Publishing makes posts public at once. On a site without a trash, "trash" is refused, since WordPress would delete for good. A media file set to draft, pending or publish becomes "inherit" (shown wherever its parent is published, everywhere without one), which needs the right to publish. Returns updated (the count); ids, the posts that have the status now, with stored_as where WordPress stores a form of its own ("future" for a post dated ahead, "inherit" for a file); failed, each with the status it has (null if unreadable) and, where telling, an error: update_failed, trash_refused or untrash_refused (refused by WordPress or a plugin), unreadable (nothing written) or unverified (written, not readable back); forbidden, the posts the account may not change (edit right per post, delete right for trash). failed and forbidden list 100 each; failed_omitted and forbidden_omitted count the rest. undo is the token of an undo point with the previous statuses, for wp_undo (null when none was recorded). A call begins no further post once the request has run 60 seconds (the first post is always handled, and one already begun is finished), so a long list is answered in parts; remaining lists the ids it did not reach, in their order (empty when it reached all), and those ids, sent in a further call, continue where it stopped, with an undo point of their own. Needs edit_others_posts.

Input Schema

NameRequiredDescriptionDefault
idsYesPost ids (integers) of any post type. An id given twice counts once; ids beyond the first 500 are not touched, nor those a call does not reach in its time (remaining).
statusYesTarget status: publish, draft, pending, private or trash; any other value is refused and nothing changes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.10.0

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations say only destructive/openWorld/not-idempotent; the description goes far beyond them by disclosing that trash is refused on sites without trash support because WordPress would delete permanently, that publishing makes posts public immediately, that media files collapse to 'inherit', and that edit_others_posts is required. It also documents retry semantics (duplicates count once, repeats are near no-ops except stored_as rewrites), the 60-second partial-completion behavior with 'remaining', and the undo token.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and limits are front-loaded, but the body is two enormous multi-clause sentences that pack return-shape, edge cases and retry rules into an undifferentiated block. Every fact earns its place, yet the density hurts parseability and no structure (lists, separators) is used.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the return contract itself and does so in full: updated, ids with stored_as, failed/forbidden with error codes and 100-item caps, omitted counts, undo token, and remaining. Combined with permission and time-limit disclosure, an agent has everything needed to call it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents duplicates, the 500-id cap and the 'remaining' overflow, so the description largely restates the same facts. It adds a little beyond the schema (media files treated alike, statuses refused leave nothing changed), but not enough to exceed the baseline for fully documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: change the status of many posts at once by id list, across posts/pages/other post types/media, to publish, draft, pending, private or trash. It also names the single-post sibling (wp_update_post), so an agent can separate this from the per-post tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Suited to batches; one post's status and other fields change with wp_update_post' routes the agent to the right alternative, and the 500-id cap plus 60-second cutoff tell it when to split work across calls. Exclusions are implied rather than crisply stated, which keeps it just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools