Skip to main content
Glama

Publish Post

publish_post
Destructive

Publish a post to the public blog, then act on its distribution.

Makes the post publicly reachable and eligible for search indexing, the RSS feed and llms.txt — and delivers it wherever its distribution is selected: every selected Republish destination (dev.to) receives the post, and is updated in place on a later publish; every selected Announce destination (X, LinkedIn, Bluesky, Mastodon) that has not announced this post yet posts its text and the post's link, once; and a selected newsletter is emailed to the list, once. Publishing again never announces or mails twice. A third-party failure never fails the publish — it is recorded on that destination instead — and a newsletter blocker (no sending domain, no From address, no public address) means the email is not sent, so each delivery is attempted, not guaranteed.

get_post_distribution reports exactly where this will go. Those posts and that email go out in the user's name and cannot be recalled.

The post publishes with the fields it has: without a Description the search snippet publishes empty; without a Summary themed blogs render no lede; without an Author the structured data credits the GoodSender organisation instead of a person; AuthorAvatarURL is the byline photo (optional; a URL returned by upload_post_image, or the photo of the most recent post by the same author). get_post shows all of them.

The public date comes from PublishedAt: this stamps the current time only when that field is still empty, and keeps a value already set, so a back-dated draft publishes with its own date.

broadcast_post emails the list after publishing without requiring the newsletter to be selected in the distribution — also at most once per post.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "PostID": "<PostID>"
    },
    "name": "publish_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
PostIDYesId of the draft to publish, from create_post or list_posts.

Output Schema

NameRequiredDescriptionDefault
PlanYesExactly where this publish goes and what it sends, one line each, with WARNING lines for what will fail.
PostYesThe published post, once published.
TitleYesOn a local server with action guards on, the pending-confirmation notice while the publish awaits approval; empty otherwise.
DistributionYesThe distribution: as reviewed while awaiting confirmation, re-read once published.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only flag destructive/openWorld/non-idempotent; the description supplies the operational consequences: actions go out in the user's name and cannot be recalled, third-party failures are recorded on the destination rather than failing the publish, newsletter blockers silently skip the email, and per-post deduplication prevents double announcements. PublishedAt back-dating behaviour is also disclosed — none of this is in the annotations.

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?

Front-loaded with purpose and distribution effects, then caveats, then field/date semantics — a sensible ordering. It is long and paragraph-dense for a one-parameter tool, but most sentences carry distinct, non-redundant behaviour; minor trimming of the destination list would not cost information.

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 destructive, open-world, externally-visible mutation with a rich output schema, the description covers the failure model, the idempotency of side effects, prerequisites, and field-dependent output quirks. Return values are handled by the output schema, so nothing material is left for the agent to guess.

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% and PostID's provenance is documented in the schema itself. The description compensates by explaining what state the referenced post must be in and which post fields (Description, Summary, Author, AuthorAvatarURL, PublishedAt) materially change the published result, which the single-parameter schema cannot convey.

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?

Opens with a specific verb and resource: 'Publish a post to the public blog, then act on its distribution.' It goes on to enumerate the concrete effects (public reachability, search indexing, RSS, llms.txt, Republish/Announce destinations, newsletter), which clearly separates it from siblings like broadcast_post, reannounce_post and get_post_distribution.

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?

Gives strong context: it names get_post_distribution as the preview step ('reports exactly where this will go') and contrasts broadcast_post as the way to email the list without newsletter selection, plus the rule that republishing never re-announces or re-mails. It stops just short of an explicit when-not-to-use list (e.g. vs. send_post_test or create_post_preview).

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.