xpost

Delivery receipt for a post

get_delivery_receipt

Read-onlyIdempotent

Per-account delivery receipt for a post: status, the live URL, plain_reason on failure, and note where less was published than was attached. approval_link is the post as a page. Not needed straight after create_post or update_post: their card already follows the delivery live. Not needed before take_down_post either: it takes the post id and draws the post once it is down.

Input Schema

Name	Required	Description	Default
`post_id`	Yes	The post id from create_post

Output Schema

Name	Required	Description
`ok`	No	Present and false only on a refusal.
`data`	No	One row per destination account.
`error`	No	What was refused, in a sentence, when `ok` is false.
`post_id`	No
`retriable`	No	False when asking again cannot change the answer.
`error_code`	No	Machine reason for a refusal.
`post_status`	No
`release_url`	No	POST once, after every picture is on the post, and it goes out on its own.
`replaced_by`	No	The id the post has now, when you asked with one an edit retired. An edit gives a post a new id: get_delivery_receipt and get_post_metrics answer for this current version (and `asked_for` is the id you sent); update_post and delete_post refuse with error_code `replaced`. Use this id from here on.
`approval_link`	No	The post as a page; the card draws the same thing.
`picture_on_it`	No	The picture has landed; only the release call is missing.
`held_for_picture`	No	Created with media_pending and not released yet.
`made_by_you_just_now`	No	You created this post minutes ago; its card is already on screen.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedOutput schema / properties / replaced_by / description

Previous value: -"With error_code `replaced`: the id the post has now. An edit gives a post a new id; use this one."New value: +"The id the post has now, when you asked with one an edit retired. An edit gives a post a new id: get_delivery_receipt and get_post_metrics answer for this current version (and `asked_for` is the id you sent); update_post and delete_post refuse with error_code `replaced`. Use this id from here on."

Changed1 schema field changedOct 27, 2026

addedOutput schema / properties / data / items / properties / retry_helps

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "On a failure: false means retry_delivery fails the same way — do what `plain_reason` says instead."
+}

Changed3 schema fields changedOct 20, 2026

addedOutput schema / properties / held_for_picture

Added value: +{
+  "description": "Created with media_pending and not released yet.",
+  "type": "boolean"
+}

addedOutput schema / properties / picture_on_it

Added value: +{
+  "description": "The picture has landed; only the release call is missing.",
+  "type": "boolean"
+}

addedOutput schema / properties / release_url

Added value: +{
+  "description": "POST once, after every picture is on the post, and it goes out on its own.",
+  "type": "string"
+}

Changed1 schema field changedOct 2, 2026

addedOutput schema / properties / replaced_by

Added value: +{
+  "description": "With error_code `replaced`: the id the post has now. An edit gives a post a new id; use this one.",
+  "type": "string"
+}

Changed1 schema field changedSep 28, 2026

addedOutput schema / properties / made_by_you_just_now

Added value: +{
+  "description": "You created this post minutes ago; its card is already on screen.",
+  "type": "boolean"
+}

First observedSep 25, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world, so the safety profile is done. The description adds real behavioral context beyond that: it discloses that failures surface as plain_reason, that partial publishing is signalled via note, and that approval_link renders the post as a page — useful signals about outcome states the agent would otherwise have to guess.

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 purpose is front-loaded in the first clause, followed by return-field enumeration and then two tight exclusion sentences. The heavy use of backticked field names is dense but each sentence earns its place; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return structure, yet it still summarizes the key fields and their failure/partial-publish meaning. Combined with annotations and full schema coverage, an agent has enough to call this correctly; only the positive 'use when' trigger is left implicit.

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?

There is a single required post_id parameter at 100% schema description coverage, which already documents it as 'the post id from create_post'. The description text adds nothing about the parameter, so the baseline of 3 applies — correct behavior, no added value.

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 names a specific resource (per-account delivery receipt for a post) and enumerates the exact fields it returns (status, live URL, plain_reason, note, approval_link), which lets an agent tell it apart from get_post_metrics or get_insights. It never states an explicit verb like 'fetch', but the receipt framing is unambiguous.

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?

It gives unusually specific negative routing: don't call it straight after create_post or update_post because their card already follows delivery, and don't call it before take_down_post because that tool draws the post itself. The positive trigger (call it when you need delivery state later) is only implied, so it falls short of a full when/when-not/alternative triad.

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

All xpost tools Inspect

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.