Skip to main content
Glama

Check a post before sending it

preview_post
Read-onlyIdempotent

Dry run: what would happen if you sent this post, without saving or posting anything. Returns ok (would it go out), problems (fix these first) and warnings, character counts per network and part the way each network counts (X: links 23, emoji/CJK 2; Bluesky: graphemes), X units it would use vs what's left this month, media checks per network (counts, video, missing alt text), which connected account each network would post as, and guardrails (this connection's daily limit, same text posted recently, blocked terms that would hold it for approval).

Takes the same arguments as create_post. Call it before a create_post / schedule_post / queue_post you're unsure about.

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": {
      "content": "<content>",
      "platforms": "<platforms>"
    },
    "name": "preview_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
pollNoPoll, as on create_post.
contentYesThe post text.
accountsNoOptional. Which account per network when a platform has several, e.g. {"twitter": "@handle"}. See create_post.
segmentsNoThread reply segments, as on create_post.
variantsNoOptional. A different version per network, e.g. {"linkedin": {"content": "..."}}; what it leaves out comes from the main post. See create_post.
platformsYesNetworks it would go to.
video_urlNoOptional video URL.
media_urlsNoMedia it would carry: URLs or {url, alt}. See create_post.
first_commentNoFirst comment, as on create_post. Its character counts per network are checked too.
allow_duplicateNoOptional. true to send text already sent to that network within 7 days (refused otherwise). See create_post.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent annotations by enumerating the exact response fields (ok, problems, warnings) and the specific checks performed: per-network character counting rules (X counts links as 23, emoji/CJK as 2; Bluesky counts graphemes), monthly X unit quota consumption, media/alt-text validation, which connected account each network would use, and guardrails including daily limits, duplicate-text detection and blocked terms that hold a post for approval. That is substantive behavioral context an agent cannot get from the structured fields.

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 lead sentence is front-loaded with the core purpose and the no-side-effects guarantee, and the second paragraph carries the routing guidance where it belongs. The return-value enumeration is one very long comma-chained sentence that is dense to parse, though nearly every listed item is information an agent needs.

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?

With 10 parameters, nested variant/segment objects and no output schema, the description carries the burden of explaining the return shape — and it does so field by field. Combined with the "same arguments as create_post" pointer for the complex nested params, an agent has everything needed to call and interpret it.

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%, so every parameter is already documented in the schema, and the description mostly repeats the schema's own framing ("takes the same arguments as create_post"). The counting-rules detail explains the output rather than the inputs, so it does not add parameter meaning beyond the schema. Baseline 3 applies.

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?

"Dry run: what would happen if you sent this post, without saving or posting anything" names a specific verb (preview/dry run) and resource (post), and immediately negates the side effects the sibling create_post would have. An agent can distinguish it from create_post, schedule_post and queue_post without opening any schema.

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 exact trigger condition ("before a create_post / schedule_post / queue_post you're unsure about") and names the three alternatives it precedes. The implicit exclusion — skip it when you are sure — is clear from that phrasing, so the routing decision is fully determined.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources