Skip to main content
Glama

Publish article

publish_article

Publish a new article on Misar.Blog immediately or schedule it for later, with support for Markdown, tags, visibility settings, and cover images.

Instructions

Publish a new article (or schedule it) on Misar.Blog

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": {
      "title": "<title>",
      "body_markdown": "<body_markdown>"
    },
    "name": "publish_article"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoUp to 10 tags
titleYesArticle title
visibilityNoWho can read this articlepublic
schedule_atNoISO 8601 timestamp to schedule. Omit to publish immediately.
body_markdownYesFull article body in Markdown
cover_image_urlNoURL of the cover image

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv5.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed6 schema fields changedv5.1.3
    • changedInput schema / properties / body_markdown / description
      Previous value: -"Complete article body as Markdown. Images may be referenced by URL."New value: +"Full article body in Markdown"
    • changedInput schema / properties / cover_image_url / description
      Previous value: -"Absolute URL of the hero image. generate_cover_image returns a URL suitable here."New value: +"URL of the cover image"
    • changedInput schema / properties / schedule_at / description
      Previous value: -"ISO 8601 timestamp to publish at, e.g. '2026-09-01T09:00:00Z'. Omit to publish immediately. A past timestamp publishes immediately."New value: +"ISO 8601 timestamp to schedule. Omit to publish immediately."
    • changedInput schema / properties / tags / description
      Previous value: -"Up to 10 topic tags used for discovery and filtering."New value: +"Up to 10 tags"
    • changedInput schema / properties / title / description
      Previous value: -"Headline, 1-250 characters."New value: +"Article title"
    • changedInput schema / properties / visibility / description
      Previous value: -"Audience: 'public' anyone, 'subscribers' newsletter subscribers, 'paid' paying members, 'private' only you. Defaults to 'public'."New value: +"Who can read this article"
  3. Changed6 schema fields changedv5.1.0
    • changedInput schema / properties / body_markdown / description
      Previous value: -"Full article body in Markdown"New value: +"Complete article body as Markdown. Images may be referenced by URL."
    • changedInput schema / properties / cover_image_url / description
      Previous value: -"URL of the cover image"New value: +"Absolute URL of the hero image. generate_cover_image returns a URL suitable here."
    • changedInput schema / properties / schedule_at / description
      Previous value: -"ISO 8601 timestamp to schedule. Omit to publish immediately."New value: +"ISO 8601 timestamp to publish at, e.g. '2026-09-01T09:00:00Z'. Omit to publish immediately. A past timestamp publishes immediately."
    • changedInput schema / properties / tags / description
      Previous value: -"Up to 10 tags"New value: +"Up to 10 topic tags used for discovery and filtering."
    • changedInput schema / properties / title / description
      Previous value: -"Article title"New value: +"Headline, 1-250 characters."
    • changedInput schema / properties / visibility / description
      Previous value: -"Who can read this article"New value: +"Audience: 'public' anyone, 'subscribers' newsletter subscribers, 'paid' paying members, 'private' only you. Defaults to 'public'."
  4. First observedv2.0.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false and destructive=false, so the mutation and safety profile is covered. The description adds that publication can be deferred via scheduling, but says nothing about what happens on publish (does it go live immediately, can it be unpublished, does it return a URL or id).

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?

A single short sentence with the action front-loaded and the scheduling variant parenthetical. There is no filler or redundancy.

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?

With 6 parameters, no output schema, and no authentication context, the description leaves the agent without any indication of the return value or auth requirements for a publishing operation. Annotations and the fully-documented schema carry most of the load, but a publishing tool's outcome is worth one more clause.

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%, so every parameter (title, body_markdown, tags, visibility, schedule_at, cover_image_url) is already documented in the schema. The description only echoes the scheduling concept without adding format, default, or constraint detail beyond the schema, which is the baseline case for full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description pairs a specific verb ('Publish') with a specific resource ('a new article') and names the destination platform, Misar.Blog. It also flags the scheduling variant. It stops short of distinguishing itself from sibling tools like create_draft or update_article, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'new' weakly implies this is for fresh articles rather than edits, but there is no explicit when-to-use guidance, no exclusion of update_article, and no mention of prerequisites such as being logged in or needing an author profile.

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