Skip to main content
Glama

Create a post or page

wp_create_post
Destructive

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. Page-builder data in "meta" (keys such as panels_data or dslc_code) takes the unfiltered_html capability, which on a multisite network only a super admin has; the keys are those of the core's list (filter ab_mcp_builder_markup_meta_keys) and of Pro's own (filter ab_mcp_pro_markup_meta_keys), and without the capability the call is refused before anything is written. Forwarded by AlphaBridge Connect to the one site this connection reaches.

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; 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. Changed10 schema fields changed
    • addedInput schema / properties / author / description
      Added value: +"Author 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."
    • addedInput schema / properties / excerpt / description
      Added value: +"Excerpt. Default empty."
    • changedInput schema / properties / meta / description
      Previous value: -"Key/value meta to set. 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."New value: +"Key/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."
    • addedInput schema / properties / parent / default
      Added value: +0
    • addedInput schema / properties / parent / description
      Added value: +"Parent post id, for hierarchical types such as pages. Default 0: none."
    • addedInput schema / properties / slug / description
      Added value: +"URL 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."
    • changedInput schema / properties / terms / description
      Previous value: -"Taxonomy => array of term ids or names, e.g. {\"category\":[\"News\"]}."New value: +"Taxonomy => 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; unknown taxonomies and taxonomies the account may not assign are skipped without an error."
    • changedInput schema / properties / title / description
      Previous value: -"Title."New value: +"Title. Default empty."
    • addedInput schema / properties / type / default
      Added value: +"post"
    • changedInput schema / properties / type / description
      Previous value: -"Post type. Default \"post\"."New value: +"Post type, as wp_get_post_types lists it. Default \"post\"."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true, idempotentHint=false and openWorld, but the description adds real substance on top: repeated calls create duplicates, empty title/content/excerpt is refused (empty_content), page-builder meta requires unfiltered_html and is refused before any write, and publish/future need the publish right. That is capability, side-effect and failure-mode context the annotations cannot express.

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, side effects and alternatives are front-loaded in the opening sentences. The rest is dense semicolon-chained prose, but nearly every clause carries a real constraint (permissions, refused-before-write, meta key filters) rather than filler.

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 an 11-parameter creation tool with no output schema, the description still names the return shape ({created: true, post} plus the wp_list_posts fields) and covers permissions, defaults and failure modes. An agent has enough to call it correctly on the first attempt.

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 description coverage is 100% and the parameter docs are already detailed (date formats, slug derivation, terms behavior, author capability). The description adds only marginal semantics beyond that, such as the draft default and status permission implications, so the baseline of 3 is appropriate.

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?

Starts with a specific verb and resource ("Create a post, page or entry of a custom post type") and enumerates the settable fields. It also distinguishes itself from wp_update_post and wp_upload_media in the same breath, so an agent can separate creation from mutation or file upload without opening any 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?

Explicitly routes the agent: existing entries go to wp_update_post, files go to wp_upload_media. It also states the default state (saved as draft unless status says otherwise) and the permission conditions for publish, private and future, which is exactly the when/when-not guidance needed before calling.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources