Skip to main content
Glama
Sign In

PostWire

by io.github.Perufitlife
OverviewDiscussionsAdmin

Check a post's publishing status

get_post_status
Read-onlyIdempotent

Returns the status and link of a published post, by platform and the post id returned when it was published, plus verification: PostWire's own independent read-back of the post from the network (state live / processing / accepted / not_public / gone / failed / unverifiable, with what the network answered and when), separate from the API response the publish got. PostWire re-reads every post 10 min, 1 h, 6 h, 24 h and 72 h after publishing; this call reads it again now. For a post that is waiting for approval or scheduled, pass the id PostWire returned for it (platform can then be omitted): the status is pending_approval (with who was asked and the review link), rejected (with the reason), scheduled, or each network's result once it went out. For TikTok and YouTube it asks the platform for the processing status and returns the public link once there is one. For an Instagram video returned as "processing", pass the id it returned: the answer is processing, published (with its id and link) or failed (with the reason). For networks that publish immediately it returns status "published" and, where the id allows it, the post's link (Telegram channels, including private ones as t.me/c//; Bluesky; LinkedIn; Facebook).

Input Schema

NameRequiredDescriptionDefault
idYesThe post id returned when it was published on that platform, or the id PostWire returned for a post waiting for approval or scheduled.
brand_idNoBrand whose account published it; omit for the default brand.
platformNoPlatform of the post, e.g. "tiktok". Optional: without it PostWire finds the network from the post it recorded (or from the id itself for TikTok, Bluesky and LinkedIn); pass it for a post published outside PostWire.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / platform / description
      Previous value: -"Platform of the post, e.g. \"tiktok\". Can be omitted for a post waiting for approval or scheduled."New value: +"Platform of the post, e.g. \"tiktok\". Optional: without it PostWire finds the network from the post it recorded (or from the id itself for TikTok, Bluesky and LinkedIn); pass it for a post published outside PostWire."
  2. Changed1 schema field changed
    • changedInput schema / properties / platform / enum
      Previous value: -[
-  "telegram",
-  "bluesky",
-  "mastodon",
-  "discord",
-  "tiktok",
-  "youtube",
-  "reddit",
-  "linkedin",
-  "facebook",
-  "instagram",
-  "x"
-]New value: +[
+  "telegram",
+  "bluesky",
+  "mastodon",
+  "discord",
+  "wordpress",
+  "devto",
+  "hashnode",
+  "slack",
+  "nostr",
+  "tiktok",
+  "youtube",
+  "reddit",
+  "linkedin",
+  "facebook",
+  "instagram",
+  "x"
+]
  3. Changed3 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"The post id returned when it was published on that platform."New value: +"The post id returned when it was published on that platform, or the id PostWire returned for a post waiting for approval or scheduled."
    • changedInput schema / properties / platform / description
      Previous value: -"Platform of the post, e.g. \"tiktok\"."New value: +"Platform of the post, e.g. \"tiktok\". Can be omitted for a post waiting for approval or scheduled."
    • changedInput schema / required
      Previous value: -[
-  "platform",
-  "id"
-]New value: +[
+  "id"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / platform / enum
      Previous value: -[
-  "telegram",
-  "bluesky",
-  "mastodon",
-  "discord",
-  "tiktok",
-  "youtube",
-  "reddit",
-  "linkedin",
-  "facebook",
-  "instagram"
-]New value: +[
+  "telegram",
+  "bluesky",
+  "mastodon",
+  "discord",
+  "tiktok",
+  "youtube",
+  "reddit",
+  "linkedin",
+  "facebook",
+  "instagram",
+  "x"
+]
  5. Changed1 schema field changed
    • changedInput schema / properties / platform / enum
      Previous value: -[
-  "telegram",
-  "bluesky",
-  "mastodon",
-  "discord",
-  "tiktok",
-  "youtube",
-  "reddit",
-  "linkedin",
-  "facebook",
-  "instagram",
-  "x"
-]New value: +[
+  "telegram",
+  "bluesky",
+  "mastodon",
+  "discord",
+  "tiktok",
+  "youtube",
+  "reddit",
+  "linkedin",
+  "facebook",
+  "instagram"
+]
  6. Changed1 schema field changed
    • addedInput schema / properties / brand_id
      Added value: +{
+  "description": "Brand whose account published it; omit for the default brand.",
+  "type": "string"
+}
  7. Changed1 schema field changed
    • changedInput schema / properties / id / description
      Previous value: -"The id returned by post_to_social for that platform."New value: +"The post id returned when it was published on that platform."
  8. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: the independent `verification` read-back with its state vocabulary and timestamp, the automatic re-read cadence, and the live platform polling for TikTok/YouTube and Instagram 'processing' responses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, but the body is one sprawling sentence followed by a dense platform-by-platform enumeration whose detail (t.me/c/ URL shape, per-network immediate-publish list) is mostly implementation trivia. It is informative but bloated and hard to scan for the one or two facts an agent needs.

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 read tool with no output schema, the description fully documents what comes back: status/link, the verification block and its states, and the special-case returns for pending, rejected, scheduled, processing and failed posts. There is no meaningful gap an agent would need filled before calling it.

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 the schema already explains `id`, `brand_id` and `platform`, including the optionality of platform and the fallback id inference. The description restates the pending/scheduled id case without adding format or syntax the schema lacks, so the baseline 3 applies.

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 ('Returns the status and link of ... a published post') and immediately narrows scope to status/link rather than metrics, which separates it from get_post_performance. It also expands the resource to cover pending-approval and scheduled posts, so an agent knows this is the status-lookup tool for any post lifecycle stage.

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 concrete when-to-use contexts: call it to read the post again now rather than waiting for the 10 min/1 h/6 h/24 h/72 h re-reads, and pass PostWire's id when the post is awaiting approval or scheduled. It does not name a sibling alternative or state when NOT to use it, so it stops short of a full routing instruction.

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

All PostWire toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources