Skip to main content
Glama
Sign In
MCP Hub

MCP Hub

by airano-ir
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

WordPress: Update post

wordpress_update_post
Destructive

Update an existing WordPress post's title, content, status, categories, tags, metadata, or multilingual fields by specifying the site and post ID.

Instructions

[UNIFIED] Update an existing WordPress post. Can update any field including title, content, status, categories, tags, REST-registered post meta, and generic multilingual metadata.

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": "<site>",
      "post_id": "<post_id>"
    },
    "name": "wordpress_update_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
metaNo
siteYes
slugNo
tagsNo
titleNo
statusNo
contentNo
excerptNo
post_idYes
languageNo
categoriesNo
featured_mediaNo
translation_ofNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.14.0
    • addedInput schema / properties / language
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • addedInput schema / properties / meta
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • addedInput schema / properties / translation_of
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
  2. Changed1 schema field changedv3.13.1
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv3.4.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is an unsafe mutation. The description adds capability context (REST-registered meta, multilingual metadata) beyond the annotations, but leaves critical behavior unstated: whether omitted fields are preserved or cleared, whether content overwrites wholesale, and whether the operation is reversible.

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?

Two tight sentences, front-loaded with the action and resource followed by the field coverage. The '[UNIFIED]' prefix is noise and the field list is somewhat padded, but there is no wasted prose.

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

Completeness2/5

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

For a 13-parameter destructive mutation with no output schema and no per-parameter documentation, the description is thin. An agent still cannot tell how to format categories/tags (IDs vs. comma-separated names), what the response contains, or whether site selects a blog in a multisite setup.

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

Parameters2/5

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

Schema description coverage is 0% across 13 parameters, so the description carries the burden entirely. It names several updatable fields (title, content, status, categories, tags, meta) but adds no format or value semantics, and never touches slug, excerpt, featured_media, language, translation_of, or site — roughly half the parameters remain opaque beyond their bare names.

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?

States a specific verb and resource ('Update an existing WordPress post') and enumerates the updatable field families: title, content, status, categories, tags, post meta, and multilingual metadata. It is clearly not a create or get tool, but it never distinguishes itself from close siblings such as wordpress_update_page, wordpress_update_post_seo, or the bulk update variants.

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

Usage Guidelines2/5

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

The description implies usage only through the word 'existing' — nothing says when to pick this over wordpress_specialist_wp_bulk_post_update for multiple posts, or over wordpress_update_post_seo for SEO fields. No prerequisites, no exclusivity conditions, and no mention of required permissions for mutating posts.

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