Frontman for WordPress

wp_update_post

Destructive

Updates an existing post or page. For one or more specific content fragments, prefer edit_many: read the post first, dry-run the proposed edits, then save with the same content hash. edit_many changes content only and returns a compact receipt; update titles, status, and other fields in a separate call. For a user-requested author task, resolve the account with wp_find_users; never guess IDs or choose an ambiguous match. Read back successful author assignment with wp_read_post. Only the fields you provide will be changed. Do not use content on Elementor-managed pages; use wp_elementor_* tools for Elementor content/layout changes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_id": "<site_id>",
      "id": "<id>"
    },
    "name": "wp_update_post"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	The post ID to update.
`mode`	No	replace accepts full content. edit changes one unique exact fragment and retains full before/after snapshots. edit_many changes one or more distinct, non-overlapping exact content fragments in one post and returns a compact receipt. Do not combine edit_many with title, status, or other post fields. Both edit modes require a fresh wp_read_post.content_sha256 as expected_current_sha256. Conflict detection is best-effort, not an atomic lock. Elementor content is not supported.	replace
`slug`	No	Optional permalink slug. Omit to retain the current slug, subject to WordPress status transitions. WordPress sanitizes it and applies uniqueness. Empty allows an empty draft/pending slug; published posts derive one from the title. See after.slug for the persisted value.
`tags`	No	Existing tag term IDs. Supplied arrays replace assignments; empty clears tags. Omit on update to preserve. Never creates terms. Read IDs with wp_read_post.
`edits`	No	edit_many only: distinct exact fragments from the original content. Each must occur exactly once, and matches must not overlap.
`title`	No	New post title.
`author`	No	Native WordPress account ID. Omit to preserve the current author. Requires author support; an explicit other account requires edit_others_posts even when unchanged.
`dryRun`	No	edit_many only: validate and report exact match offsets and proposed hash without saving. Defaults to false; a later save rechecks the original content hash.
`status`	No	New post status.
`content`	No	New post content as HTML or block markup.
`excerpt`	No	New post excerpt.
`newText`	No	Required in edit mode only: replacement bytes, different from oldText. Empty deletes the fragment.
`oldText`	No	Required in edit mode only: nonempty exact fragment from stored content, occurring exactly once.
`site_id`	Yes	The connected site's id returned by list_sites. Call list_sites first; do not use a URL or WordPress post ID.
`template`	No	Pages only: an available native page-template slug/file, or default to reset. Omit on update to preserve. Read the actual assignment in wp_read_post.template.
`categories`	No	Existing category term IDs. Supplied arrays replace assignments; omit on update to preserve. Empty uses the WordPress default category for posts (and filtered default-category post types), except auto-drafts; otherwise clears. Never creates terms. Read IDs with wp_read_post.
`expected_current_sha256`	No	Required in edit and edit_many modes: lowercase SHA256 from a fresh wp_read_post.content_sha256. Any content change requires reading again.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare destructive=true, openWorld=true and non-idempotent, so the safety profile is known. The description does add real value beyond that: partial-update semantics ("Only the fields you provide will be changed") and the caveat that conflict detection is best-effort rather than an atomic lock. It still says nothing about what a successful response contains or how failures are surfaced, so a 3 rather than higher.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence and each following clause carries a distinct rule. The density is high but justified for a 17-parameter destructive tool; a small amount is redundant with the schema's own mode description.

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

Completeness4/5

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

For a broad, destructive mutation tool with no output schema, the definition covers partial-update behavior, sha256 concurrency guard, author resolution, Elementor exclusion and edit_many sequencing. The remaining gap is return-value expectations, partly offloaded to wp_read_post and to a parenthetical about the compact receipt.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all 17 parameters, and some description text repeats it (edit_many excludes title/status). What it adds beyond the schema is procedural: the read-then-dryRun-then-save-with-same-hash workflow and the author permission nuance, which give the parameters operational meaning.

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?

"Updates an existing post or page" gives a specific verb and resource, and the text immediately carves out the sibling cases: edit_many for fragment edits and wp_elementor_* for Elementor-managed content. An agent can distinguish this from wp_create_post, wp_delete_post and wp_update_block without opening a schema.

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

Usage Guidelines5/5

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

It states when to prefer edit_many (fragment edits, read-dry-run-save flow), when to split title/status into a separate call, how to handle author assignment (resolve via wp_find_users, never guess), and an explicit exclusion for Elementor pages. When-not and alternative-tool guidance are both present.

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

All Frontman for WordPress tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.