postmoderno

Schedule post

schedule_post

Destructive

Schedule the exact state the user confirmed from a preview. Requires that preview's preview_revision and the same post_id, time, and optional replies; changed content, targets, chain, media, quote, or resolved time is rejected until it is previewed and confirmed again. Accepts "now" (publishes as soon as this call commits), RFC3339, "YYYY-MM-DD HH:MM", "tomorrow 09:00", or "HH:MM" in the user's timezone. Each reply goes out delay_sec after its parent actually publishes.

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": {
      "post_id": "<post_id>",
      "at": "<at>",
      "preview_revision": "<preview_revision>"
    },
    "name": "schedule_post"
  }
}

Input Schema

Name	Required	Description
`at`	Yes	when to publish: 'now' (as soon as this call commits), RFC3339, 'YYYY-MM-DD HH:MM', 'tomorrow 09:00', or 'HH:MM' (resolved in the user's timezone)
`post_id`	Yes
`replies`	No	self-replies to publish under this post, in order. Each fires delay_sec after the one before it actually publishes.
`preview_revision`	Yes	opaque revision returned by preview_schedule for this exact post, time, and replies after the user confirmed that preview

Output Schema

Name	Required	Description	Default
`post`	Yes
`reused`	No
`series`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description adds what those mean in practice: publishing is irreversible in effect, mismatched state is refused rather than silently merged, and 'now' fires as soon as the call commits. The reply-chain timing rule (each reply fires delay_sec after its parent actually publishes) is real behavioral detail not derivable from annotations.

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 precondition is front-loaded into the second sentence, with the format list and the reply-timing rule following in descending priority. Three dense sentences, none wasted, though the `at` format enumeration is a partial restatement of the schema field description.

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?

For a destructive, non-idempotent publish operation the description covers the gate (preview revision), the drift rejection rule, time resolution and reply scheduling. An output schema exists, so return values need not be explained, and nothing an agent needs to invoke this safely 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 75%, so the schema carries most parameter documentation and the description mostly restates the `at` formats. Where it does add meaning is on preview_revision (it is bound to the exact post, time and replies, and invalidated by any drift) and on reply chaining, which is more precise than the schema's per-field wording.

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?

Opens with a specific verb and a precise object: scheduling 'the exact state the user confirmed from a preview'. That framing distinguishes it cleanly from create_post and from preview_schedule in the sibling list, since the agent immediately knows this is the confirm-and-commit step, not the drafting or preview step.

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?

States the precondition explicitly (must hold the preview's preview_revision plus the same post_id, time and replies) and the rejection condition (changed content, targets, chain, media, quote or resolved time is rejected until re-previewed). The route back to preview_schedule on any change is unambiguous, so the agent knows both when to call this and when it must loop back.

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

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