Skip to main content
Glama

Create a post or page

wp_create_post
Destructive

Create a WordPress post, page or custom post type entry with title, content, status, excerpt, terms and custom fields. Each call adds a new draft unless a status is specified.

Instructions

Create a post, page or entry of a custom post type with title, content, status, excerpt, terms and custom fields; each call creates a new entry, so a repeated call makes a second one. Saved as a draft unless status says otherwise; publish, private and future need the right to publish, and a published entry shows on the site at once where its post type is publicly viewable. WordPress refuses an entry with empty title, content and excerpt for types that support all three, such as posts (empty_content). Returns {created: true, post} with the new entry's summary (the fields of wp_list_posts). Needs the right to create entries of the type. Existing entries are changed with wp_update_post, files are added with wp_upload_media.

Input Schema

NameRequiredDescriptionDefault
dateNoPublish date. Site time as "Y-m-d H:i:s" (or "Y-m-d H:i", "Y-m-d"), or RFC 3339 with an offset, the form of the dates this plugin returns, e.g. "2026-10-02T09:00:00+02:00". Times that do not exist in the site's timezone (clocks skip them) are refused, as is a time where the clocks go back that WordPress would read as the other of the two.
metaNoKey/value custom fields to set. Keys are stored as sanitize_key() writes them (lower case; letters, digits, _ and -). Keys starting with "_", protected or credential-like keys and keys the account may not edit are skipped without an error. Page-builder data (keys such as panels_data, dslc_code or pagelayer-data; filter ab_mcp_builder_markup_meta_keys) takes the unfiltered_html capability, which on a multisite network only a super admin has; without it the call is refused before anything is written.
slugNoURL slug. Default: WordPress derives it from the title, except for drafts and pending entries, which keep none until a save with another status (publish, private or future). Once the entry is no longer a draft or pending, WordPress adds a numeric suffix to a slug already in use.
typeNoPost type, as wp_get_post_types lists it. Default "post".post
termsNoTaxonomy => array of term ids or names, e.g. {"category":["News"]}. A name that does not exist yet is created where the account may manage the taxonomy's terms, else left out; a taxonomy whose list holds a term the account may not assign (assign_term) is skipped; unknown taxonomies and taxonomies the account may not assign are skipped without an error.
titleNoTitle. Default empty.
authorNoAuthor user id. Applied only for an account that may edit others' entries of this type; otherwise, and by default, the connected user is the author.
parentNoParent post id, for hierarchical types such as pages. Default 0: none.
statusNodraft, publish, pending, private, future. Default "draft". "future" needs a date at least five minutes ahead; "publish" with such a date schedules the post, as in WordPress.
contentNoContent (HTML or block markup).
excerptNoExcerpt. Default empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.7.0

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial context beyond annotations: each call creates a new entry (consistent with idempotentHint=false), default draft status, publish/private/future require publish capability, a published entry is immediately visible on the site, empty title+content+excerpt is refused with empty_content, and the return shape {created, post} is given. None of this is derivable from the readOnly/openWorld/destructive hints alone.

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 and the non-idempotency warning are front-loaded, then permissions, failure mode, return value, and sibling routing follow in a logical order. It is a dense single paragraph, though, and the permission clauses are packed tightly enough to slow scanning.

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?

Covers what an agent needs for a zero-required-parameter mutation tool: default status, capability requirements, the refusal condition, immediate visibility of published content, non-idempotency, return payload, and which sibling to use instead. No output schema exists, and the description names the returned fields regardless.

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 already 100%, so baseline is 3, but the description adds cross-parameter semantics the schema states only per-field: draft-unless-status-says-otherwise, and that invisible/refused combinations (e.g. builder meta needing unfiltered_html) fail before anything is written. It doesn't restate the date/status scheduling rule in detail, leaving that to the schema.

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 (create a post, page or custom post type entry) and enumerates the fields it can set. It clearly separates itself from wp_update_post (existing entries) and wp_upload_media (files), so an agent can pick it without opening sibling schemas.

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?

Explicitly routes edge cases to alternatives: existing entries go to wp_update_post, files to wp_upload_media. It doesn't spell out a full 'when not to use' (e.g. bulk creation vs. duplicate), but the create-vs-update boundary is unambiguous.

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