Skip to main content
Glama
Perufitlife

PostWire

by Perufitlife
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Check a post's publishing status

get_post_status
Read-onlyIdempotent

Checks a published, scheduled, or pending post's current status and public link by platform and post id, including PostWire's independent verification of whether the post is really live.

Instructions

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". Can be omitted for a post waiting for approval or scheduled.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.4.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / brand_id
      Added value: +{
+  "description": "Brand whose account published it; omit for the default brand.",
+  "type": "string"
+}
    • changedInput schema / properties / id / description
      Previous value: -"the post id returned by post_to_social"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: -"e.g. 'tiktok' or 'youtube'"New value: +"Platform of the post, e.g. \"tiktok\". Can be omitted for a post waiting for approval or scheduled."
    • addedInput schema / properties / platform / enum
      Added value: +[
+  "telegram",
+  "bluesky",
+  "mastodon",
+  "discord",
+  "wordpress",
+  "devto",
+  "hashnode",
+  "slack",
+  "nostr",
+  "tiktok",
+  "youtube",
+  "reddit",
+  "linkedin",
+  "facebook",
+  "instagram",
+  "x"
+]
    • changedInput schema / required
      Previous value: -[
-  "platform",
-  "id"
-]New value: +[
+  "id"
+]
  2. Addedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false. The description adds substantial behavior beyond that: PostWire's independent verification states, the re-read schedule at 10 min/1 h/6 h/24 h/72 h, the fact that this call reads again now, and per-platform processing behavior. No contradiction with 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?

The description is front-loaded with the core purpose and return information, and most sentences carry specific operational value. It is dense and long, with several network-specific clauses packed into one paragraph, but that length is justified by the complexity of the tool.

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 non-destructive status-check tool with no output schema, the description thoroughly explains return values, verification states, special pending/scheduled behavior, and per-network differences. An agent has enough information to invoke and interpret the tool correctly.

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%, so the baseline is 3, but the description adds meaningful semantics not obvious from the schema: the id can be either the platform post id or the PostWire id for pending/scheduled posts, and platform can be omitted for pending or scheduled posts. This clarifies conditional parameter use beyond the raw schema.

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 states a specific verb and resource: it returns the status and link of a published post, keyed by platform and post id. It also clearly distinguishes special cases such as pending_approval, scheduled, rejected, and per-network processing states, so an agent can distinguish it from siblings like get_post_performance or list_scheduled_posts.

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 gives clear usage context for several scenarios: pass the id PostWire returned for approval/scheduled posts, use the id returned for Instagram videos still processing, and expect immediate published status on certain networks. It does not explicitly compare against sibling tools or state when not to use this tool, so it falls short of a full 5.

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

Deploy Server

Other Tools