Skip to main content
Glama

Create post

create_post

Publish a blog post to Ghost or WordPress with support for drafts, scheduling, multiple authors, images, and SEO metadata.

Instructions

Publish an article. Defaults to status "published" — pass "draft" only when the user asked for a draft, or "scheduled" with publish_at to go live at a set time. The author accepts a persona slug and resolves to that site's author id. HTML must not still contain [[content_image]]. Every article gets a hero (feature_image) and an inline by default when an image provider is configured — refused otherwise; pass images: "hero" | "inline" | "none" to opt out.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
faqNoBuilds FAQPage JSON-LD. Must match the visible FAQ section exactly.
htmlYes
siteYes
tagsNo
titleYes
authorNoByline. Either a persona slug (resolved to that site's author id) or a raw platform-native author id, to attribute the post to someone with no persona file — the id's format is specific to the target site's platform and is not the same across every site. Omit to use the site default_author. Run list_authors against the target site to find its ids.
imagesNoWhich of the hero image (feature_image) and the in-body <img> are required before publishing. Only enforced when an image provider is configured; pass "none" if this article genuinely has no image.both
schemaNoInject Article (+FAQPage) JSON-LD into the page head for AEO/GEO
statusNo"published" goes live now, "draft" is not visible, "scheduled" goes live at publish_at (which is then required).published
keywordsNoFeeds Article JSON-LD
og_imageNoDefaults to feature_image
og_titleNoFacebook/LinkedIn card title
meta_titleNoSEO title; defaults to title
publish_atNoWhen the post should be published, as a date and a time of day — "2026-08-04T10:00". **It is read in the TARGET BLOG'S OWN timezone, never yours and never the user's.** So "publish at 10am tomorrow" is simply "2026-08-04T10:00": pass the wall-clock time the user said, verbatim. Do NOT convert it to UTC, do NOT convert it to your own timezone, and do NOT ask the user which timezone they mean — the blog decides, and Byline looks its timezone up from the platform. The same string sent to two blogs in two countries is two different instants, on purpose. An explicit offset ("2026-08-04T10:00:00+05:30" or "...Z") is also accepted and is then taken at face value, but only use one if the user actually named a timezone. Required with status "scheduled", where it must be at least 2 minutes in the future. With status "published" it must be in the PAST — that backdates the post; a future time with status "published" is refused, because Ghost would publish it immediately while WordPress would schedule it. The result reports publish_at_local, the time as the blog's own clock reads it — tell the user that one, not the UTC value.
canonical_urlNo
feature_imageNoURL from upload_image
twitter_imageNoDefaults to feature_image
twitter_titleNoX card title
custom_excerptNoShown in listings and feeds
og_descriptionNo
feature_image_idNoThe native id upload_image returned alongside the url (its `id` field), needed by platforms that reference media by id rather than URL — e.g. WordPress's featured_media. Ghost has no such field and ignores this.
meta_descriptionNo
feature_image_altNo
twitter_descriptionNo
feature_image_captionNo
Behavior4/5

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

With no annotations, the description carries full behavioral burden. It discloses default status, author resolution, the [[content_image]] placeholder constraint, and image requirement/refusal behavior. While it doesn't cover every edge case, it addresses the most consequential behaviors.

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?

Four sentences, each providing necessary operational detail. It front-loads the core action and then layers critical caveats without redundancy or fluff.

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?

For a 25-param create tool with no output schema, the description covers the main behavioral complexity (status, images, author) while the schema's rich parameter descriptions handle the rest. It lacks explicit return-value info, but the schema and sibling context partially compensate.

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 60%, and the description adds practical semantics for key parameters: status defaults, author resolution, and image options with default behavior. It compensates for gaps but doesn't fully explain all 25 parameters.

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 'Publish an article' with a specific verb and resource, and clarifies default status (published) and creation semantics. Clearly distinguishes from siblings like update_post and upload_image by framing it as the create/publish action.

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?

Provides clear context on when to use 'draft', 'scheduled', or 'published' statuses, and explains author field resolution. Does not explicitly name alternatives like update_post for existing posts, so it lacks explicit when-not-to-use guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/indianic/byline'

If you have feedback or need assistance with the MCP directory API, please join our Discord server