Skip to main content
Glama

Update post

update_post

Edit existing blog posts in place, updating only the specified fields. Also manage scheduling by setting status to scheduled or draft, and adjust publish dates.

Instructions

Edit an existing post in place. Only the fields you pass are changed. Also the way to schedule an existing draft (status "scheduled" plus publish_at), to unschedule one (status "draft"), or to correct a post's date (publish_at in the past).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNo
siteYes
tagsNo
titleNo
statusNo
post_idYes
og_imageNo
og_titleNo
meta_titleNo
publish_atNoa 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. Note that Ghost refuses to move an already-published post back to "scheduled" (it answers "Your post is already published"); set it to "draft" first.
canonical_urlNo
feature_imageNo
twitter_imageNo
twitter_titleNo
custom_excerptNo
og_descriptionNo
feature_image_idNoThe native id upload_image returned alongside the url, 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
codeinjection_headNo
twitter_descriptionNo
feature_image_captionNo
Behavior3/5

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

The description discloses the key behavioral trait that only passed fields are changed, which is valuable for a partial-update tool. It also mentions the scheduling/unscheduling/backdating behaviors. However, with no annotations, it omits details about permissions, error conditions, or whether changes are irreversible, leaving the agent to infer mutation safety.

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?

The description is three short, purposeful sentences. The first states the core action, the second explains the partial-update behavior, and the third lists additional use cases. Every sentence earns its place with no redundancy or filler.

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

Completeness3/5

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

The description gives enough context to understand primary use and the scheduling nuances. But with 22 parameters, no output schema, and no annotations, it leaves out return values, error handling, and permission requirements. It is adequate for basic usage but not fully complete for an agent operating autonomously.

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?

The description adds semantics for status and publish_at by explaining their combined usage for scheduling/unscheduling/backdating, and it clarifies that any subset of fields can be updated. Schema coverage is only 9%, so the description should compensate for the other 20 parameters; it does not, though most property names (e.g., title, tags, html) are self-explanatory.

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 opens with 'Edit an existing post in place,' which clearly states the verb (edit), resource (existing post), and scope (in place). It further distinguishes itself from the sibling create_post by emphasizing edits to existing posts and by enumerating specific use cases like scheduling/unscheduling drafts and backdating.

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 explicitly lists when to use the tool: to edit a post, schedule an existing draft, unschedule one, or correct a date. It implicitly signals this is not for creating new posts, but it does not explicitly name create_post as an alternative or state what not to do. Clear context exists, but no formal exclusions are given.

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