Socialync

update_scheduled_post

DestructiveIdempotent

Change a scheduled post that has not published yet: its time, its caption (for every platform, or per platform), the YouTube title, the first comment, or drop platforms from it. Pass a groupId to change every platform of a grouped post together (the ids publish_scheduled returns share a groupId), or a postId for one platform's entry. Prefer this over delete_scheduled_post plus a new post: it keeps the post's id, media and settings. Media cannot be swapped and platforms cannot be added here; for that, cancel and schedule again. Before calling, show the user exactly what will change and get their explicit confirmation in chat. If the user has switched on the publish confirmation dialog in Socialync settings (off by default) and their client supports MCP elicitation, Socialync also shows a dialog; a decline changes nothing and comes back as success false with consent "declined". A new time must be at least 3 minutes away and inside the plan's scheduling window; moving a post to another UTC day uses that day's 10-post allowance. Posts already publishing, published, failed or cancelled are skipped with a reason. Call get_scheduled_posts to find ids.

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": "update_scheduled_post"
  }
}

Input Schema

Name	Required	Description
`title`	No	New YouTube video title (YouTube entries only).
`postId`	No	One platform entry to change (an id from get_scheduled_posts).
`caption`	No	New caption for every platform in the edit (including a platform that had its own caption).
`groupId`	No	Change every platform entry sharing this groupId. Takes precedence over postId.
`firstComment`	No	New first comment for the platforms that support one; an empty string removes it.
`scheduledFor`	No	New publish time, ISO 8601 UTC (e.g. 2026-04-15T14:00:00Z). At least 3 minutes from now.
`removePlatforms`	No	Platforms to drop from the post. The rest still publish. To drop every platform, use delete_scheduled_post.
`platformCaptions`	No	Per-platform captions, keyed by platform id (e.g. {"twitter": "short version", "linkedin": "long version"}). Wins over caption for those platforms.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses the 3-minute lead time and plan scheduling-window constraint, the 10-post daily allowance when crossing UTC days, that posts already publishing/published/failed/cancelled are skipped with a reason, and the optional MCP elicitation dialog with the exact decline shape (success false, consent "declined"). It also confirms id/media/settings preservation, which reconciles the destructiveHint=true annotation with the fact the post itself survives.

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?

Front-loaded with the capability and the editable field list, then constraints and the confirmation requirement. Dense but nearly every clause carries decision-relevant information; the confirmation-dialog sentence is long and could be trimmed without losing the decline semantics.

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 an 8-parameter mutation over grouped posts with nested per-platform captions and a destructive annotation, the description covers preconditions, scoping, partial-failure behavior, consent flow, and sibling routing. No output schema exists, and the decline response shape is described, so nothing an agent needs to call it correctly is missing.

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 the parameters are already documented (including precedence between groupId and postId, caption vs platformCaptions, and empty string to clear firstComment). The description reinforces the groupId/postId choice and the 3-minute/window constraint on scheduledFor, but adds little new per-parameter syntax. Baseline 3 is appropriate.

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?

A specific verb (change) on a specific resource (a scheduled post that has not published yet), with the exact editable fields enumerated: time, caption (global or per platform), YouTube title, first comment, and platform removal. It is clearly distinguished from delete_scheduled_post and from a new post, and it names the id sources (get_scheduled_posts / publish_scheduled's groupId).

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?

Explicit when-to-use (prefer over delete+recreate because id/media/settings are retained), when-not-to-use (media swap and platform addition are not supported; cancel and reschedule instead), routing rules (groupId vs postId, delete_scheduled_post for removing all platforms), and a required pre-call workflow (show the user exactly what changes and get explicit confirmation).

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.