Skip to main content
Glama
MCP WordPress CrunchTools

MCP WordPress CrunchTools

by crunchtools

Wordpress Edit Post

wordpress_edit_post

Edit an existing WordPress post by replacing exact source text without resending the post; optional version checks prevent overwriting newer changes.

Instructions

Replace text in a WordPress post's source, without resending the post.

Input Schema

NameRequiredDescriptionDefault
post_idYesPost ID
new_textYesReplacement text
old_textYesExact text from get_post's content to replace; must occur exactly once
replace_allNoReplace every occurrence instead of requiring exactly one
expected_versionNoRefuse the edit unless the post is still at this version (get_post)

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden, and it does disclose one meaningful trait: this is a targeted patch that does not resend/overwrite the whole post. However, it says nothing about permissions, whether revisions are created, what happens when the replacement target is missing or ambiguous, or how failures surface — all relevant for an unannotated mutation tool.

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

Conciseness5/5

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

One short sentence, front-loaded with verb and resource, zero filler. Nothing in it is redundant with the schema or annotations.

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?

With a full output schema present and 100% parameter description coverage, the description need not explain return values or field semantics. What remains thin is the sibling disambiguation and any note about failure/conflict handling, but for a five-parameter tool whose schema already encodes the tricky constraints, it is close to adequate.

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 itself is unusually rich — old_text documents the exactly-once constraint, replace_all documents the override, and expected_version documents the optimistic-concurrency check. The description adds no parameter meaning beyond that, so the baseline 3 is appropriate.

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

Purpose4/5

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

A specific verb+resource pair: 'Replace text in a WordPress post's source,' which is meaningfully narrower than a whole-post rewrite. The closing phrase 'without resending the post' implicitly distinguishes it from wordpress_update_post and wordpress_edit_draft, but neither sibling is named, so the agent must infer the boundary.

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

Usage Guidelines3/5

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

'Without resending the post' hints at when this is preferable to a full update, but there is no explicit when-to-use statement, no preconditions, and no named alternative. Usage is implied rather than stated, which leaves the agent guessing between edit_post, update_post, and edit_draft.

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