xpost

Best times to post

get_best_times

Read-onlyIdempotent

Posting slots (weekday × hour, UTC) ranked by this workspace's own past engagement. signal says what the order is worth: none means no engagement is recorded and the order is arbitrary; thin means some slots rest on one or two posts (samples); ok means three or more each.

Input Schema

Name	Required	Description
`format`	No	Filter to one format (feed post / reel / story)
`platform`	No	Filter to one platform, e.g. instagram
`since_days`	No	Window in days (default 90)

Output Schema

Name	Required	Description
`ok`	No	Present and false only on a refusal.
`error`	No	What was refused, in a sentence, when `ok` is false.
`slots`	No	Best first. Empty when there is not enough history to rank anything.
`signal`	No	How much the ORDER is worth. "none": no engagement recorded, so the order is arbitrary. "thin": some slots rest on one or two posts. "ok": every slot has 3+.
`retriable`	No	False when asking again cannot change the answer.
`error_code`	No	Machine reason for a refusal.
`since_days`	No
`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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the trust model: it explains that `none` means the order is arbitrary, `thin` means one or two underlying posts (`samples`), and `ok` means three or more. That is exactly the kind of behavioral context an agent needs before presenting the ranking as advice.

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?

Two sentences, front-loaded with what the tool returns, then the interpretation key for `signal`. Dense but every clause earns its place; the only slight redundancy is that `signal` may also be documented in the output schema.

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?

An output schema exists so return values need not be spelled out, the three optional filters are fully documented in schema, and the description closes the main remaining gap by warning when the ranking is meaningless. Nothing an agent needs in order to call or interpret this tool 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 description coverage is 100%, including the enum for `format` and the 1–365 bounds and default for `since_days`, so the schema carries the parameter burden. The description adds only the UTC timezone qualifier, which pertains to the output rather than to any filter 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 states a concrete resource (posting slots at weekday × hour granularity in UTC) and the ranking basis (this workspace's own past engagement), which an agent can grasp immediately. It stops short of naming how it differs from overlapping siblings such as get_insights or get_top_posts, so it is clear but not fully differentiated.

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: an agent must infer that this is for scheduling/planning rather than analytics review. There is no explicit when-to-use or when-not guidance, and no alternative sibling is named, though the `signal` explanation implicitly tells the agent when the ranking is trustworthy enough to act on.

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.