xpost

Metrics for a post

get_post_metrics

Read-onlyIdempotent

Per-platform engagement for one published post: views, likes, comments, shares, reach, saves, engagement, and the live URL. A null metric is one the platform does not report, not zero; empty data means the numbers have not synced yet (roughly every 6 hours).

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 platform. EMPTY means the numbers haven't synced yet, not that nobody saw it.
`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.
`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.

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 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"
+}

First observedSep 25, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description is free to spend its words elsewhere — and it does: null vs zero semantics, empty `data` meaning unsynced, and a ~6-hour refresh cadence are exactly the interpretive context an agent needs and cannot get from structured fields. It does not cover rate limits or per-platform keying details, keeping it at 4.

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?

Two sentences, both front-loaded with the highest-value information: what comes back first, then how to read ambiguous results. No filler, no restatement of the title.

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, return-value structure need not be explained, yet the description still supplies the semantics that a schema cannot express (null meaning, empty-data meaning, sync cadence). The remaining gap is sibling differentiation against get_insights/get_top_posts.

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 one required parameter at 100% schema coverage, and the schema already documents it as 'The post id from create_post' including UUID format and pattern. The description adds nothing about the parameter, so the baseline 3 applies.

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 the resource precisely ('per-platform engagement for one published post') and enumerates the returned metrics, so an agent knows exactly what it yields. It does not distinguish itself from plausible siblings such as get_insights or get_top_posts, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is only implied by the phrase 'for one published post' — the agent can infer this is the single-post lookup, but there is no explicit when-to-use statement and no routing away from get_insights, get_top_posts, or list_posts. No prerequisites or exclusions are stated.

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.