Skip to main content
Glama
Sign In

Simplo

by ai.getsimplo
OverviewDiscussionsAdmin

Schedule post

schedule_post
Idempotent

Schedules an existing post, or moves a scheduled one to a new time. A scheduled post is published to the real social accounts automatically at scheduledAt — ask the user before scheduling, then pass confirm: true. Works on drafts (including draft_scheduled), scheduled, missed and failed posts; a post that already went out cannot be rescheduled. Pass the time as localTime with timeZone (Simplo resolves the offset), or as scheduledAt with its offset. Without a time the post keeps the time it already has. The time must be in the future and on the hour: Simplo publishes once an hour, on the hour. possibleDuplicateOf in the answer names another planned post within 14 days that opens the same way: tell the user.

Input Schema

NameRequiredDescriptionDefault
postIdYes
confirmYesMust be true — confirms the user approved auto-publishing at that time
timeZoneNoThe user's IANA time zone, e.g. America/Edmonton. Needed with localTime; with scheduledAt it only sets the zone scheduledLocal is shown in. The answer's scheduledLocal says how the saved time reads there: check it against what the user asked for
localTimeNoThe time as the user's clock shows it, YYYY-MM-DDTHH:MM with no offset (e.g. 2026-11-09T12:00), with timeZone. Preferred over scheduledAt: Simplo works out the UTC offset in force on that date. Not together with scheduledAt
projectIdYesSimplo project id (from list_projects)
scheduledAtNoISO 8601 time with offset, in the future and on the hour (e.g. 12:00, never 11:45); defaults to the post's current scheduledAt. localTime with timeZone is safer

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / localTime
      Added value: +{
+  "description": "The time as the user's clock shows it, YYYY-MM-DDTHH:MM with no offset (e.g. 2026-11-09T12:00), with timeZone. Preferred over scheduledAt: Simplo works out the UTC offset in force on that date. Not together with scheduledAt",
+  "type": "string"
+}
    • changedInput schema / properties / scheduledAt / description
      Previous value: -"ISO 8601 time with offset, in the future and on the hour (e.g. 12:00, never 11:45); defaults to the post's current scheduledAt"New value: +"ISO 8601 time with offset, in the future and on the hour (e.g. 12:00, never 11:45); defaults to the post's current scheduledAt. localTime with timeZone is safer"
    • addedInput schema / properties / timeZone
      Added value: +{
+  "description": "The user's IANA time zone, e.g. America/Edmonton. Needed with localTime; with scheduledAt it only sets the zone scheduledLocal is shown in. The answer's scheduledLocal says how the saved time reads there: check it against what the user asked for",
+  "type": "string"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say this is a non-read-only, idempotent, non-destructive write; the description goes well beyond by disclosing that the post is auto-published to real social accounts, that user confirmation is mandatory, that publishing is hourly on the hour, that the time must be in the future, and that a duplicate-detection field (possibleDuplicateOf, 14-day window) may come back and should be surfaced.

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?

Roughly a hundred words for a genuinely complex tool, with the core action first, then preconditions, then time-format guidance, then return-value hints. No filler sentences; the 'publishes once an hour, on the hour' clause justifies rather than repeats the constraint.

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?

No output schema exists, yet the description names the two return fields that matter for correctness (scheduledLocal to verify the saved time, possibleDuplicateOf to warn the user) and instructs how to act on them. Combined with the confirmation gate and time-format rules, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 83%, so the schema already documents confirm, timeZone, localTime and scheduledAt in comparable detail. The description largely restates those rules (localTime with timeZone vs scheduledAt, future-and-on-the-hour) and adds only modest framing, such as the consequence of omitting a time entirely.

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 with scope: scheduling an existing post or moving an already-scheduled one. The phrase 'an existing post' and 'a post that already went out cannot be rescheduled' cleanly separates it from create_post and publish_post in the sibling list.

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?

Explicit when-to-use and when-not: works on drafts (including draft_scheduled), scheduled, missed and failed posts, but not published ones. It also states the consent precondition ('ask the user before scheduling, then pass confirm: true') and the no-time fallback, and routes between the localTime and scheduledAt options with a stated preference.

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

All Simplo 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