wpxmcp

Create content

create_content

Create WordPress posts, pages, or custom post types as drafts by default, with options to publish, schedule, set taxonomies, and assign custom fields.

Instructions

Create a post, page, or any custom post type. Content is created as a DRAFT unless you explicitly pass status: "publish" — this server never publishes to a live site implicitly. Schedule by passing status: "future" with a future date. Taxonomy terms can be given by name and are created if missing.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	No	Publish date in site time, ISO 8601 (2026-01-31T09:00:00). With status "future" (or "publish" and a future date) this schedules the post.
`meta`	No	Custom fields, as key/value pairs. A key only writes if it is registered with show_in_rest — use set_content_meta for unregistered keys.
`slug`	No	URL slug. Changing this on published content breaks existing links unless you add a redirect.
`type`	No	Content type to create.	post
`terms`	No	Taxonomy assignments keyed by taxonomy slug or REST base, e.g. {"categories": [3], "tags": ["news"]}. Replaces the item's terms in each taxonomy given. Names that do not exist yet are created.
`title`	No	The title, as plain text.
`author`	No	User ID of the author.
`format`	No	Post format. Only applies to types that support post formats.
`parent`	No	Parent ID, for hierarchical types such as pages. 0 for none.
`status`	No	publish \| future \| draft \| pending \| private \| trash. "future" needs a `date` in the future. "trash" moves the item to the trash (same as delete_content without force).
`sticky`	No	Pin the post to the top of the blog. Posts only.
`content`	No	Full content body, replacing whatever is there. For the block editor this is block markup (<!-- wp:paragraph --><p>…</p><!-- /wp:paragraph -->); classic content is plain HTML. Use `edits` instead for a small change.
`excerpt`	No	Hand-written excerpt.
`site_id`	No	Which configured WordPress site to act on. Optional — with a single site configured it is used automatically; with several, the default site is used unless you name one. Run list_sites for valid ids.
`password`	No	Password-protect the content. Empty string removes the password.
`template`	No	Page template file, e.g. "templates/full-width.php". Empty string for the default template.
`menu_order`	No	Sort order for hierarchical types.
`ping_status`	No	Whether pingbacks and trackbacks are accepted.
`comment_status`	No	Whether comments are open on this item.
`featured_media`	No	Attachment ID of the featured image, or 0 to remove it. Upload it with create_media first.

Schema Changelog

Changes observed during successful MCP inspections.

Changed21 schema fields changedv2.0.0Sep 15, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```
addedInput schema / properties / author / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / author / minimum
```
Added value: +-9007199254740991
```

changedInput schema / properties / date / description

Previous value: -"Publish date in site time, ISO 8601 (2026-01-31T09:00:00). With status \"future\" this schedules the post."New value: +"Publish date in site time, ISO 8601 (2026-01-31T09:00:00). With status \"future\" (or \"publish\" and a future date) this schedules the post."

changedInput schema / properties / featured_media / description

Previous value: -"Attachment ID of the featured image. Upload it with create_media first."New value: +"Attachment ID of the featured image, or 0 to remove it. Upload it with create_media first."

addedInput schema / properties / featured_media / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / featured_media / minimum
```
Added value: +0
```

changedInput schema / properties / format / description

Previous value: -"Post format: standard, aside, gallery, link, image, quote, status, video, audio, chat."New value: +"Post format. Only applies to types that support post formats."

addedInput schema / properties / format / enum

Added value: +[
+  "standard",
+  "aside",
+  "chat",
+  "gallery",
+  "link",
+  "image",
+  "quote",
+  "status",
+  "video",
+  "audio"
+]

addedInput schema / properties / menu_order / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / menu_order / minimum
```
Added value: +-9007199254740991
```
addedInput schema / properties / meta / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

changedInput schema / properties / parent / description

Previous value: -"Parent ID, for hierarchical types such as pages."New value: +"Parent ID, for hierarchical types such as pages. 0 for none."

addedInput schema / properties / parent / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / parent / minimum
```
Added value: +0
```

changedInput schema / properties / password / description

Previous value: -"Password-protect the content."New value: +"Password-protect the content. Empty string removes the password."

changedInput schema / properties / status / description

Previous value: -"publish | future | draft | pending | private | trash."New value: +"publish | future | draft | pending | private | trash. \"future\" needs a `date` in the future. \"trash\" moves the item to the trash (same as delete_content without force)."

changedInput schema / properties / template / description

Previous value: -"Page template file, e.g. \"templates/full-width.php\"."New value: +"Page template file, e.g. \"templates/full-width.php\". Empty string for the default template."

changedInput schema / properties / terms / description

Previous value: -"Taxonomy assignments keyed by taxonomy REST base, e.g. {\"categories\": [3], \"tags\": [\"news\"]}. Names that do not exist yet are created."New value: +"Taxonomy assignments keyed by taxonomy slug or REST base, e.g. {\"categories\": [3], \"tags\": [\"news\"]}. Replaces the item's terms in each taxonomy given. Names that do not exist yet are created."

addedInput schema / properties / terms / propertyNames
```
Added value: +{
+  "type": "string"
+}
```

First observedv1.0.0Aug 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description discloses critical behavior beyond annotations: content defaults to DRAFT, this server never publishes implicitly, scheduling requires status 'future' with a future date, and taxonomy terms are created if missing. These safety-relevant details are not visible in annotations and add real value.

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?

Three tightly written sentences, front-loaded with purpose and immediately followed by the most important behavioral guardrails. No filler or redundant restatement of the schema.

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?

For a 20-parameter tool, the schema already provides exhaustive parameter descriptions, so the description only needs to carry the behavioral and safety context. It covers the default draft state, publishing guardrail, scheduling requirement, and taxonomy auto-creation, which is enough for an agent to invoke the tool correctly.

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 baseline is 3. The description adds meaning beyond the schema by specifying the default status behavior (DRAFT unless 'publish' is explicit) and by clarifying how taxonomy terms behave when missing. Most parameter details are already in the schema, but the added defaults are valuable.

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?

The description names a specific verb and resource: create a post, page, or custom post type. It clearly distinguishes itself from sibling tools like update_content, delete_content, create_comment, and create_media by stating exactly what kind of entity it creates.

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?

The description makes the core use case obvious: create new content. It does not explicitly list when-not-to-use or name alternatives, but the context is clear enough for an agent to select this tool over update/delete or media/comment creation. It could be stronger with an explicit pointer to update_content for edits.

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

Deploy Server

Create content

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools