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 @acme X variant without scheduling the IG / Threads / other-X-account copies. When both are omitted, all providers in the PostGroup are queued.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "postId": "<postId>",
      "scheduledAt": "<scheduledAt>"
    },
    "name": "schedule_post"
  }
}

Input 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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 2, 2026
- removedOutput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```
First observedSep 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already disclose that this is a non-read-only, open-world, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations: the prerequisite draft state and the cross-post scoping/default behavior. It does not describe failure modes or permission requirements, but the annotation coverage lowers the burden.

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 front-loaded with the core action, followed by the prerequisite and then the optional scoping behavior. Every sentence contributes useful information with no repetition or filler.

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?

Given the rich input schema, existing output schema, and annotations, the description is complete enough for an agent to invoke the tool correctly. It supplies the key prerequisite and scoping semantics without needing to restate return values.

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 description coverage is 100%, so parameter documentation is already strong. The description still adds meaning by explaining that platform and channelName narrow a multi-channel cross-post and that omitting both queues all providers in the PostGroup, beyond what the schema alone states.

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: moving a draft post into the publish queue at a future time. It also distinguishes the operation from create_post_draft by explicitly naming it as a prerequisite, so an agent can tell which sibling to call first.

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 gives clear usage context: the draft must already exist, create_post_draft should be used first, and platform/channelName are optional scoping filters. It also explains the default behavior when both filters are omitted. It does not explicitly list when not to use this tool, but the main selection context is covered.

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?