xpost

Posting rules per account

get_posting_rules

Read-onlyIdempotent

Every platform_configurations key each account accepts, with kind, accepted values, ceilings and placement gates — the catalog to read before setting anything beyond a caption. A key that is absent cannot be published through that connection: sent anyway it is refused or loses the delivery. Pinterest accounts also list boards, each with eligible. ONE POST CARRIES EVERY ACCOUNT: list them all in create_post's accounts and put a platform's own words in platform_configurations.<platform>.caption, its own options beside them. One post per platform is not how this works — it spends the free first post on a single network, walls the rest, and hands the person one card per network to read instead of one.

Input Schema

Name	Required	Description	Default
`social_account_ids`	No	Narrow to these accounts (ids from list_accounts); omit for all

Output Schema

Name	Required	Description
`ok`	No	Present and false only on a refusal.
`data`	No
`error`	No	What was refused, in a sentence, when `ok` is false.
`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."

Changed2 schema fields changedOct 14, 2026

changedOutput schema / properties / data / items / properties / limits / properties / caption_chars_available / description

Previous value: -"Caption room left once the project's signature is added."New value: +"Caption room left for your words."

addedOutput schema / properties / data / items / properties / posts_left_today

Added value: +{
+  "additionalProperties": {},
+  "description": "Absent where the account has no such daily allowance.",
+  "properties": {
+    "limit": {
+      "type": "number"
+    },
+    "remaining": {
+      "type": "number"
+    },
+    "resets_at": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

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 readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond them: absent keys are refused or silently lose the delivery if sent anyway, and Pinterest returns nested `boards` with `eligible`. It does not discuss pagination or rate limits, but for a read-only catalog that gap is minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the resource content well, but roughly half the text is a lecture about how create_post should be called ("ONE POST CARRIES EVERY ACCOUNT", per-platform caption placement). That guidance serves create_post more than this tool and crowds out detail about this tool's own behavior.

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?

An output schema exists, so return values need not be spelled out, yet the description usefully characterizes the payload shape (keys, accepted values, ceilings, gates, boards). With full schema coverage and a documented single optional filter, an agent has what it needs to call this correctly.

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% and the single `social_account_ids` parameter is fully documented inline, so the baseline is 3. The description never mentions this parameter, and its "list them all" instruction refers to create_post's `accounts`, not this tool's filter.

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 precisely what is returned: every `platform_configurations` key accepted per account, with kind, accepted values, ceilings and placement gates, plus Pinterest `boards` with `eligible`. It distinguishes itself from create_post by framing itself as the catalog to read first, though it opens with a noun phrase rather than a verb, making the read action slightly implicit.

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 catalog to read before setting anything beyond a caption" gives a clear trigger condition, and the note that absent keys cannot be published establishes a consequence for skipping it. It does not enumerate other alternatives (e.g., list_accounts for ids is only referenced in the schema), so the routing is clear but not exhaustive.

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.