Socialync

get_scheduled_posts

Read-only

List the user's scheduled posts: pending ones, failures from the last 14 days and posts published in the last 2 days (get_post_history has older published posts). Shows platform, profileId, caption, scheduled time and status. caption is the text that platform will publish: its own override from platformSpecificSettings when the post has one (captionIsPlatformOverride is then true), otherwise the shared caption. instagramTrialReel is "MANUAL" or "AUTO" on an Instagram post that will publish as a Trial Reel, and null on every other post. A post with status "failed" carries an error object: code (stable, e.g. connection_signed_out, connection_reauth_required, trial_reel_ineligible, media_rejected, rate_limited, platform_unavailable), a plain message to relay to the user, action (reconnect, edit_post, retry, wait_and_retry), retryable, retryAfterReconnect, and the platform's raw platformError. When action is "reconnect", tell the user which account to reconnect in Socialync Settings; do not reschedule until they have. A post with status "held" did not publish because the account had no active plan (payment failing or plan ended) when it came due, and it will never publish late on its own: its held object has the reason and message, and the fix is to reschedule it. A still-pending post carries onHold when the account currently has no active plan: it publishes only if the payment goes through within an hour of its time, so tell the user to update their payment in Socialync Billing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_scheduled_posts"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The annotations already declare this a safe read, so the bar is lower, and the description still adds substantial behavior the annotations cannot: the status taxonomy (pending, failed, held, published), the 14-day/2-day retention windows, and the exact semantics of held and onHold (never publishes late, publishes only if payment clears within an hour). It also gives the agent prescriptive handling rules for reconnect and retry actions, which is genuine beyond-schema context.

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?

It is front-loaded well: the listing scope and the sibling alternative land in the first sentence, before any field-level detail. The remainder is dense but each clause carries distinct diagnostic value (error codes, action values, held vs onHold). It is longer than ideal and could compress the error-code enumeration into a tighter clause, which keeps it off a 5.

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 no output schema, no parameters, and a rich return payload, the description carries the full burden and meets it: it documents the returned fields (platform, profileId, caption, scheduled time, status), the caption override rule, the instagramTrialReel values, and the full failure/held/onHold object shapes. An agent has everything needed to interpret and act on the response.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate at the input layer and the baseline of 4 applies. The description instead spends its space on output semantics, which is the correct allocation here.

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 opening sentence gives a specific verb and resource plus the exact scope of the listing: pending, failures from the last 14 days, and posts published in the last 2 days. It explicitly routes older published posts to the sibling get_post_history, so an agent can distinguish it from that tool without opening either schema.

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?

It names the alternative (get_post_history) and the boundary condition that selects it, which is real usage guidance. It also tells the agent what to do operationally in specific situations (relay the message, direct the user to Socialync Settings, do not reschedule until reconnected, do not expect a held post to publish late). It stops short of a full when-to-use/when-not-to-use statement against the broader sibling set such as get_post_insights or delete_scheduled_post.

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

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