Ravenpost

Preview a post

preview_post

Read-onlyIdempotent

Render a post as each destination platform will show it — WITHOUT creating anything. Nothing is written, scheduled or published; call create_post afterwards with the same arguments to actually post it. Takes the same arguments as create_post (caption, hashtags, accountIds, mediaIds, type, thread, replyTo, quote, audio, collaborators, reelCover, trialReel, firstComment), and returns the same preview a client with MCP Apps renders as an interactive card, one tab per platform. Use this before create_post whenever the user is composing rather than dictating: it is the cheapest way to show them what goes out, and it reports what would be rejected or silently dropped — a caption over the tightest platform's budget, a platform that requires media when there is none, a thread longer than the strictest limit, audio on a platform with no music API, Instagram collaborators on an account that cannot invite them, a reel cover or trial on a post that is not a reel (or a cover create_post would refuse), a first comment on a story, on a post with no Instagram account, or beside networks that get none, media Bluesky leaves behind (it takes up to four images or one video), and X's own rules — more than one $cashtag in a post, a thread reply @mentioning somebody new to the conversation, the same post on two X accounts, a reply or quote X only takes from an account the target post names, media X leaves behind. The character counts it returns are per platform and authoritative: they are the same ones create_post enforces. For Pinterest, include board (and link/title) too — the preview warns when a Pinterest target has no board, which is the way a Pinterest post most often fails. The board name is taken as given: create_post checks it against the account's boards (see list_boards) and refuses an unknown one before writing anything. A preview reads only this workspace's own accounts and media and calls no social network, so nothing outside Ravenpost is touched or shown to anyone.

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": {
      "caption": "<caption>",
      "accountIds": "<accountIds>"
    },
    "name": "preview_post"
  }
}

Input Schema

Name	Required	Description
`link`	No	Facebook link card / Pinterest pin destination URL
`type`	No	Instagram format; defaults to IMAGE
`audio`	No	Instagram reel track, for the preview caption line
`board`	No	Pinterest board name or id — pass it so the preview does not warn about a board you already picked
`quote`	No	X quote: tweet id or URL to embed as a card — X only takes it when that post is the account's own or @mentions it
`title`	No	Pinterest pin title
`thread`	No	Follow-up posts, previewed as the reply chain they publish as
`caption`	Yes	The post caption / text body
`replyTo`	No	X reply: tweet id or URL the head post replies to — X only takes it when that post is the account's own or @mentions it
`hashtags`	No	Hashtags to append to the caption (with or without a leading #)
`mediaIds`	No	Ordered media asset ids (from upload_media / list_media)
`reelCover`	No	Instagram reel cover, as you would pass it to create_post — checked against the media library the way create_post checks it, and drawn on the card.
`trialReel`	No	Instagram trial reel graduation, as you would pass it to create_post.
`accountIds`	Yes	Target social account ids (from list_accounts)
`workspaceId`	No	Which workspace to act in — an id from list_workspaces. Optional with a single workspace; REQUIRED once there are several, where guessing would mean posting one client's content to another client's accounts. Ask the user which one before publishing.
`firstComment`	No	Instagram first comment, as you would give it to create_post — drawn under the Instagram caption, and warned about where it would not be posted: a story, a post with no Instagram account, and the other networks, which get no comment.
`collaborators`	No	Instagram co-author usernames, as you would pass them to create_post. Nothing in the card draws them — pass them so the preview can warn when the targeted Instagram accounts cannot invite them and they would be dropped.

Output Schema

Name	Required	Description	Default
`type`	No
`audio`	No
`media`	No
`postId`	No
`status`	No
`thread`	No
`confirm`	No
`linkUrl`	No
`targets`	No
`pinTitle`	No
`warnings`	No
`reelCover`	No
`trialReel`	No
`publishedAt`	No
`scheduledAt`	No
`quoteTweetId`	No
`replyToTweetId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / firstComment

Added value: +{
+  "description": "Instagram first comment, as you would give it to create_post — drawn under the Instagram caption, and warned about where it would not be posted: a story, a post with no Instagram account, and the other networks, which get no comment.",
+  "type": "string"
+}

First observedNov 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The readOnlyHint/idempotent/openWorld annotations are confirmed and then substantially exceeded: the description says nothing is written, scheduled or published, that the tool reads only this workspace's own accounts and media, that it calls no social network, and that its character counts are the same ones create_post enforces. That last point is a genuinely non-obvious behavioral guarantee an agent could not derive from annotations or schema.

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 opening three sentences are front-loaded and excellent, but the value proposition then collapses into a single ~150-word run-on sentence enumerating every rejection rule across Instagram, X, Bluesky and Pinterest. That enumeration is informative, yet as prose it is dense and hard to scan, and a bulleted or grouped structure would have made the same content markedly more usable.

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 and an MCP Apps card is described, so the description does not need to explain return formatting and does not. For a 17-parameter, zero-side-effect dry-run tool, everything an agent needs to decide to call it and to interpret what the preview is telling it is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the schema already documents all 17 properties, so most of the argument list here is a restatement. The description does add real cross-parameter meaning the schema does not: board is taken as given and only checked against the account's boards by create_post, and it explains why optional params like collaborators and firstComment should be passed even when not drawn on the card.

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?

"Render a post as each destination platform will show it — WITHOUT creating anything" gives a precise verb (render a preview) and resource (a post per destination platform), and immediately rules out the mutate reading that the sibling create_post would otherwise create ambiguity with. An agent can distinguish this from create_post, publish_post and schedule_post from the first clause alone.

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

Usage Guidelines5/5

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

It states the triggering condition explicitly ("Use this before create_post whenever the user is composing rather than dictating") and names the follow-up alternative with its exact handoff ("call create_post afterwards with the same arguments"). It also routes the agent to list_boards for Pinterest board validation, which is a concrete alternative-tool pointer rather than a vague implication.

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

All Ravenpost 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.