Skip to main content
Glama
Sign In

ShortSync

by app.shortsync
OverviewDiscussionsAdmin

Schedule posts

batch_schedule_posts

Schedules multiple draft video posts in a single call. Equivalent to calling schedule_post for each post but batched — use this when scheduling more than one post. Pass scheduled_for (every post gets that time) or use_next_slot: true (each upload takes the next free saved posting time, in the order given, and all of an upload's platforms share it, like the app's bulk scheduling). Pass recurrence to repeat each upload on a cadence ("Repeat this post", same shape as the public API). Returns per-post results so you can see which succeeded and which failed.

Input Schema

NameRequiredDescriptionDefault
recurrenceNo"Repeat this post": publish the same post again on a cadence, like the app's Repeat option. scheduled_for is occurrence 1. Max 12 occurrences in total; each occurrence counts as one upload credit.
scheduled_forNoISO 8601 timestamp for when all posts should publish. Max 1 year out. Times in the past are nudged to now + 30 seconds. Required unless use_next_slot is true.
use_next_slotNoGive each upload the next free saved posting time (see get_posting_slots) instead of one shared scheduled_for.
video_post_idsYesArray of video_posts.id values to schedule (max 50). Typically obtained from create_post_draft or create_post_drafts.
idempotency_keyNoOptional client-generated key (e.g., a UUID) to make retries safe. Identical calls with the same key within 10 minutes return the original result instead of running the write twice.
notify_on_successNoEmail the user when each post successfully publishes. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / recurrence
      Added value: +{
+  "description": "\"Repeat this post\": publish the same post again on a cadence, like the app's Repeat option. scheduled_for is occurrence 1. Max 12 occurrences in total; each occurrence counts as one upload credit.",
+  "properties": {
+    "count": {
+      "description": "Total occurrences including the first. Required when end_type is count.",
+      "maximum": 12,
+      "minimum": 2,
+      "type": "integer"
+    },
+    "end_date": {
+      "description": "Last day (YYYY-MM-DD, inclusive). Required when end_type is date.",
+      "type": "string"
+    },
+    "end_type": {
+      "description": "End after a number of occurrences (count) or on a date (end_date).",
+      "enum": [
+        "count",
+        "date"
+      ],
+      "type": "string"
+    },
+    "interval": {
+      "description": "Repeat every N units.",
+      "maximum": 12,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "unit": {
+      "enum": [
+        "day",
+        "week",
+        "month"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "interval",
+    "unit",
+    "end_type"
+  ],
+  "type": "object"
+}
    • changedInput schema / properties / scheduled_for / description
      Previous value: -"ISO 8601 timestamp for when all posts should publish. Max 1 year out. Times in the past are nudged to now + 30 seconds."New value: +"ISO 8601 timestamp for when all posts should publish. Max 1 year out. Times in the past are nudged to now + 30 seconds. Required unless use_next_slot is true."
    • addedInput schema / properties / use_next_slot
      Added value: +{
+  "description": "Give each upload the next free saved posting time (see get_posting_slots) instead of one shared scheduled_for.",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "video_post_ids",
-  "scheduled_for"
-]New value: +[
+  "video_post_ids"
+]
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-destructive, open-world write. The description adds genuine behavioral context beyond them: partial success is possible ('per-post results so you can see which succeeded and which failed'), uploads consume next slots in the given order, and all of an upload's platforms share one time. It omits retry/idempotency behavior and any auth or rate-limit notes, which keeps it short of a 5.

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?

Purpose and the single-vs-batch routing are front-loaded, followed by the two scheduling modes and the return shape. It is dense and mostly earns its sentences, though the parenthetical asides ('same shape as the public API', 'like the app's bulk scheduling') could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the return-value burden, which it handles by stating per-post results are returned. For a batched write tool with a fully documented schema and safety annotations, the remaining gaps (auth prerequisites, failure/retry semantics) are minor.

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 coverage is 100%, so the baseline is 3. The description still adds meaning the schema does not: next-slot assignment is ordered by input order, platforms within an upload share the slot, and recurrence mirrors the app's 'Repeat this post' semantics. That is useful clarification on top of a fully documented schema.

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 states a specific verb and resource ('Schedules multiple draft video posts in a single call') and explicitly frames it as the batched equivalent of schedule_post. An agent can distinguish it from schedule_post and from the broader sibling list without opening the 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 names the alternative (schedule_post) and the exact condition that selects this tool ('use this when scheduling more than one post'). It also routes the agent between the two scheduling modes (scheduled_for vs use_next_slot) with the conditions for each.

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

All ShortSync toolsInspect
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