Skip to main content
Glama
Sign In

Posteady

by com.posteady
OverviewDiscussionsAdmin

Get publish status

get_publish_status
Read-only

Get the current state of a TikTok Business video, Instagram media, YouTube video, or Facebook Page publish job. Returns queued, scheduled, processing, published, failed, canceled, or unknown. Only a published job with postId identifies a completed native platform post. This reads stored state and does not submit or retry a publish. unknown means the outcome is not confirmed yet; publishing again with a new requestId would start a separate publish. The target workspace is determined from jobId and your current access is checked.

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": {
      "jobId": "<jobId>"
    },
    "name": "get_publish_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobIdYesTikTok, Instagram, YouTube, or Facebook jobId returned by publish_post or schedule_post.
workspaceIdNoOptional assertion of the expected workspace. The target is determined from the publish job.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark this read-only and non-destructive, and the description goes well past them: it lists the exact status vocabulary, explains that only published + postId means a real native post, and clarifies that unknown is not a failure and that re-publishing with a new requestId starts a separate publish. It also discloses the access check on the workspace, which no annotation conveys.

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 the core purpose, then layered with status semantics and constraints in a logical order, with no filler. Slightly dense: the unknown-related sentences and the final workspace sentence could be tightened, but every sentence still carries distinct 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?

There is no output schema, so the description must carry return semantics itself, and it does so by enumerating every possible status value and explaining the one that matters most (published with postId). For a two-parameter read tool with strong annotations, nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, with both jobId and workspaceId already documented including their formats and origin in publish_post/schedule_post. The description largely restates that (workspace derived from jobId) and adds only the detail that current access is verified; the added meaning over the schema is marginal, so 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?

States a specific verb and resource ("Get the current state of a ... publish job") and enumerates the four supported platforms. It also draws the boundary against sibling tools by declaring "This reads stored state and does not submit or retry a publish," which separates it from publish_post and repost_post.

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?

Implies the workflow clearly: call after publish_post/schedule_post (jobId is returned there) to check progress, and do not re-publish to 'fix' an unknown result. It gives a strong negative case (no submit, no retry) but never names a sibling alternative by name, e.g. pointing to cancel_scheduled_post for cancellation.

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

All Posteady 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