postnext

Schedule a draft post

schedule_post

Idempotent

Move a draft post into the publish queue at a future time. The draft must already exist (use create_post_draft first). Optional platform and channelName narrow which providers in a multi-channel cross-post get scheduled — e.g. queue only the @bogdanvazzolla X variant without scheduling the IG / Threads / other-X-account copies. When both are omitted, all providers in the PostGroup are queued.

Input Schema

TableJSON Schema

Name	Required	Description
`postId`	Yes	Draft postId from list_drafts
`platform`	No	On a multi-platform cross-post, scope the schedule to one platform (e.g. only the Twitter variant). When omitted, all platforms in the PostGroup get queued.
`timezone`	No	IANA timezone name (e.g. Europe/Bucharest, America/New_York). Used for downstream display + day-bucket logic. Optional — pass it when scheduledAt is a local time the user verbalised (e.g. "tomorrow at 9am their time").
`channelName`	No	When the user has multiple channels per platform (e.g. three Twitter accounts), pair with `platform` to scope the schedule to one specific account's copy. Matches against each provider's `channelName` field.
`scheduledAt`	Yes	ISO 8601 timestamp. Best practice: include the timezone offset (e.g. 2026-05-06T13:33:00+03:00) or use Z for UTC. If the user gives a local time without offset, include the timezone arg.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context: the multi-channel behavior (which providers get queued) and the timezone handling for local times. It does not contradict any annotations, and it explains the side-effect of scheduling (moving to publish queue) without hiding anything.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no filler. The core purpose is front-loaded, then the optional narrowing behavior is explained, and finally the default behavior. Every sentence earns its place and the structure is efficient.

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?

An output schema exists, so return values are covered. The description covers the main use case, the prerequisite, and optional scoping. It doesn't discuss edge cases like invalid postId or past times, but these are not essential for an agent to invoke the tool correctly. It is complete enough for a scheduling tool.

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 schema already documents every parameter. The description goes beyond by explaining the interaction between platform and channelName with a concrete example ('@bogdanvazzolla X variant') and clarifying the timezone usage for local times. This adds semantic value beyond the schema's individual field descriptions.

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 opens with a specific verb and resource: 'Move a draft post into the publish queue at a future time.' It clearly states the action and distinguishes itself from siblings like create_post_draft (creates) and cancel_scheduled_post (cancels). The scope is unambiguous.

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 explicitly states the prerequisite: 'The draft must already exist (use create_post_draft first).' It also explains when to use the optional platform and channelName to narrow scheduling, and the default behavior when omitted. It does not explicitly mention alternative tools for scheduling vs. cancellation, but the purpose is clear enough that an agent can infer when to use this tool.

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

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