Skip to main content
Glama
Sign In

ShortSync

by app.shortsync
OverviewDiscussionsAdmin

Update posting slots

update_posting_slots
Destructive

Sets the user's daily posting times for a workspace, like editing the time slots in Settings. Pass times (hand-picked "HH:mm" list, replaces the current list and clears any interval) or interval (a range that generates the times, like the app's auto-fill), plus optional timezone and platform_times. Omitted fields stay as they are. move_posts_past_limits turns the workspace's automatic move past daily limits on or off (owners and admins only) and can be sent on its own. Returns the saved slots and the next free ones. Same behavior as PUT /api/v1/posting-slots.

Input Schema

NameRequiredDescriptionDefault
timesNoDaily times in 24-hour "HH:mm", e.g. ["09:00", "17:30"]. Replaces the saved list; [] clears it.
intervalNoGenerate times from a range instead of listing them. An end at or before the start wraps past midnight. null clears the interval but keeps the times.
timezoneNoIANA timezone the times are in, e.g. "Europe/Helsinki". null clears it (UTC is used).
workspace_idYesWorkspace to update. Get one from list_workspaces.
platform_timesNoPer-platform default times that seed the per-platform picker, e.g. { "twitter": "07:00" }. null clears them.
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.
move_posts_past_limitsNoWorkspace setting, on by default. true moves a scheduled post to its next free slot when it hits a platform's daily limit; false lets it fail. Applies to everyone in the workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / move_posts_past_limits
      Added value: +{
+  "description": "Workspace setting, on by default. true moves a scheduled post to its next free slot when it hits a platform's daily limit; false lets it fail. Applies to everyone in the workspace.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, and the description earns credit by explaining what is destroyed: passing times replaces the existing list and clears any interval, and omitted fields are left intact. It also discloses permission scoping for move_posts_past_limits and that the call can be sent with that field alone, though it omits side effects on already-scheduled posts and does not mention the idempotency/retry behavior documented only in the schema.

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?

Dense but front-loaded: the core action and the two mutually exclusive input modes come first, followed by optional fields and the return value. It is one long block rather than a structured list, and the closing endpoint reference is mildly redundant against the title.

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?

For a 7-parameter mutation with destructiveHint and no output schema, the description covers the essential mechanics, what persists, the permission gate, and what is returned (saved slots plus next free ones). Remaining gaps are edge cases like invalid time formats and effects on existing scheduled posts.

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 adds value by spelling out the mutual exclusion between times and interval (one replaces/clears the other) and that move_posts_past_limits can be sent on its own as a standalone workspace toggle. That mutual-exclusion framing is the main non-obvious semantic an agent needs.

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?

States a specific verb and resource ("Sets the user's daily posting times for a workspace") and grounds it in the familiar Settings UI and the PUT /api/v1/posting-slots endpoint, which makes it clearly distinct from the read-only get_posting_slots sibling.

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?

The description makes the times-vs-interval choice explicit (using one replaces/clears the other) and notes that omitted fields are preserved, plus the owner/admin restriction on move_posts_past_limits. It does not say when to read current slots first (e.g. call get_posting_slots) or when not to use it, so it stops short of explicit alternatives.

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