Mark

Reschedule Post

reschedule_post

Moves a post to a new future time. A draft keeps its status; any other post goes back to review at the new time and publishes only once approved again. Pass scheduledAt for any time, or slotId and date (both, from get_calendar's open slots) to fill one posting slot occurrence: Mark puts the post at that slot's time on that date in the workspace timezone, and refuses a slot on another channel, a past occurrence, or one another post already holds, so two callers can't double-book it. The same status rules apply either way. Related: get_post, get_calendar, search_posts.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	The slot occurrence's local date (YYYY-MM-DD, workspace timezone), on the slot's weekday. Pass with slotId.
`postId`	Yes	Post id.
`slotId`	No	Posting slot id from get_calendar. Pass with date, instead of scheduledAt.
`scheduledAt`	No	New publish time as a UTC ISO string, in the future. Omit when you pass slotId and date.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rev`	Yes
`appUrl`	Yes
`postId`	Yes
`status`	Yes
`scheduledAt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 19, 2026

addedInput schema / properties / date

Added value: +{
+  "description": "The slot occurrence's local date (YYYY-MM-DD, workspace timezone), on the slot's weekday. Pass with slotId.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

changedInput schema / properties / scheduledAt / description

Previous value: -"New publish time as a UTC ISO string, in the future."New value: +"New publish time as a UTC ISO string, in the future. Omit when you pass slotId and date."

addedInput schema / properties / slotId

Added value: +{
+  "description": "Posting slot id from get_calendar. Pass with date, instead of scheduledAt.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "postId",
-  "scheduledAt"
-]New value: +[
+  "postId"
+]

addedOutput schema / properties / scheduledAt
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "appUrl",
-  "postId",
-  "rev",
-  "status"
-]New value: +[
+  "appUrl",
+  "postId",
+  "rev",
+  "scheduledAt",
+  "status"
+]

First observedOct 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: a draft keeps its status, any other post returns to review and re-publishes only after approval, and the tool refuses cross-channel slots, past occurrences, and already-occupied occurrences (double-booking protection). The openWorld/idempotency hints do not carry any of this.

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 core action and status rule, then the two modes, then the refusal conditions. The single dense paragraph is efficient, though the slot-mode clause is long enough that a reader may need to re-read it.

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?

An output schema exists so return values need no explanation, and the description covers the mutation's side effects, the two input modes, the prerequisite (get_calendar), the timezone interpretation, and the failure conditions. Nothing needed 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: slotId and date must be passed together, come from get_calendar open slots, and Mark interprets them in the workspace timezone on the slot's weekday. It also clarifies scheduledAt must be a future UTC string.

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 ('Moves a post to a new future time') and immediately branches into the two supported modes with their distinct semantics. An agent can distinguish this from update_posting_slots or review_post 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?

Explicitly tells the agent to pass scheduledAt for any time, or slotId+date from get_calendar's open slots to fill a slot occurrence, and names get_calendar as the source of slot ids. It lacks an explicit 'don't use this when...' exclusion, but the routing context is clear.

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

All Mark 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?