ViewPrinter

Schedule a post

posts_schedule

Create a post and queue it for every account named. Pass draft true to hold it here instead, sending nothing until posts_update promotes it. Name accounts with ids from accounts_list, or name a group from groups_list and get all of its members — the two combine, and a group is expanded now, so adding an account to it later does not add it to this post. Accounts must all be in one workspace. Attach media by id from media_list; a post is either a video or a set of images, never both. Omit scheduled_at to send as soon as possible. Nothing publishes yet: this records the intent. Publishing has to be enabled on the account; where it is not, this saves nothing at all and says so. Do not tell anyone their post is saved or scheduled until this has returned successfully.

Input Schema

TableJSON Schema

Name	Required	Description
`draft`	No	Hold the post here instead of sending it. Nothing is queued and nothing reaches any platform; use posts_update with draft false to send it. Unrelated to the per-platform draft option, which uploads to the platform for the creator to finish.
`groups`	No	Group names from groups_list, expanded to their members and combined with account_ids. Matched without regard to case.
`content`	No	The caption.
`media_ids`	No	Files to attach, in order. Order is the slideshow order.
`account_ids`	No	Which accounts to post to, from accounts_list. Optional when groups is given; naming neither is refused.
`scheduled_at`	No	ISO 8601. Omit to send as soon as possible.
`idempotency_key`	No	Reuse on retry to avoid posting twice; returns the original post.
`platform_options`	No	Per-platform settings, keyed by platform. Only the keys shown are accepted — an unknown key is refused rather than ignored. The names, types and accepted values are here; call platforms_list for what each one does, its default, and which kind of post it applies to.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`post`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 21, 2026
- addedInput schema / properties / platform_options / properties / instagram / properties / trialReel
```
Added value: +{
+  "enum": [
+    "MANUAL",
+    "SS_PERFORMANCE"
+  ],
+  "type": "string"
+}
```
First observedSep 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context: nothing publishes yet, publishing must be enabled on the account, if not enabled it saves nothing and says so, group expansion is frozen at scheduling time, and media is either video or images never both. It also warns not to tell the user it's saved until the call returns successfully. This goes well beyond the annotations.

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 description is dense but every sentence adds information. It front-loads the core action and then covers draft behavior, account/group selection, media constraints, scheduling, publishing requirements, and a user-facing warning. It is longer than average, but the tool is complex with 8 parameters and nested platform options, so the length is justified. Slight redundancy with the schema's draft description exists but the description adds the posts_update routing.

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?

For a complex tool with 8 parameters, nested objects, and an output schema, the description covers the key decision points: draft vs publish, account/group selection, media type constraints, scheduling, workspace constraint, publishing enablement, and idempotency retry behavior. The output schema exists, so return values don't need to be described. The only minor gap is not detailing every platform option, but the description explicitly routes to platforms_list for that.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it explains the draft flag's relationship to posts_update, clarifies that groups are expanded at scheduling time, states that a post is either video or images, and notes that naming neither accounts nor groups is refused. It doesn't enumerate every platform option, but the schema already covers those and the description points to platforms_list for semantics.

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?

The description opens with a specific verb and resource: 'Create a post and queue it for every account named.' It clearly distinguishes this from siblings like posts_update (promotes drafts) and posts_cancel, and explains the draft behavior. The title 'Schedule a post' is expanded with concrete scope and semantics.

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?

The description gives explicit when-to-use guidance: use draft true to hold the post, use posts_update to promote it, name accounts from accounts_list or groups from groups_list, and explains how groups expand. It also states constraints like 'Accounts must all be in one workspace' and 'Omit scheduled_at to send as soon as possible.' This is rich routing and usage context.

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

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

Resources

Need Help?