PostWire

Set up a recurring post

create_recurring_post

Set posts to repeat daily, weekly, monthly, or every N days/weeks/months with rotating text variants and duplicate protection; upcoming occurrences are queued as editable scheduled posts.

Instructions

Sets up a post that repeats on a schedule: daily, weekly on some weekdays, or monthly on some days of the month (31 falls on the last day of shorter months; -1 = the last day), every N days, weeks or months, at 1-4 times a day in a timezone (daylight saving handled), from a start date until an end date or for a number of times. variants (a list of texts) are used in turn, so the same text does not repeat every time. The duplicate guard (guard_days, default 3, 0 = off) skips a network where the same text went out in the last guard_days when an occurrence is published: networks flag repeated posts. Occurrences are put in the queue up to 7 days ahead as ordinary scheduled posts (each can be edited or canceled alone), and go through the brand's approval rules and the plan's limits like any post. On every paid plan (Starter 25, Pro 100, Agency 500 at a time); not on Free. Returns the recurring post with its next occurrences and any warnings (for example: one text every day with a 3-day guard would be skipped).

Input Schema

Name	Required	Description
`rule`	Yes	When it repeats.
`text`	No	The post, when there is one text.
`label`	No	Name shown in the queue, e.g. "Monday tip".
`brand_id`	No	Brand whose accounts to use; omit for the default brand.
`variants`	No	Texts used in turn: the 1st occurrence uses the 1st, the 2nd the 2nd, and so on, starting again after the last.
`photo_url`	No	Optional image (public https link).
`platforms`	Yes	Connected platforms to post to.
`video_url`	No	Optional video (public https link).
`guard_days`	No	Skip a network where the same text went out in the last N days. Default 3; 0 = off.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: DST handling, duplicate-guard skipping, queueing up to 7 days ahead, per-occurrence editability, approval rules, plan limits, and returned warnings. These details are directly useful for an agent deciding whether and how to call the tool.

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?

The description is front-loaded with the core purpose and the length is justified by a complex recurring-scheduling tool with nested rule parameters. It is dense and delivered as one long paragraph, which slightly reduces readability despite every part being relevant.

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 no output schema, the description explicitly covers the return value: the recurring post with next occurrences and warnings. It also covers plan limits, approval behavior, queue timing, and duplicate-guard interactions, leaving little an agent needs to infer before calling it.

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 baseline is 3, but the description adds real meaning beyond the schema: monthly day 31 fallback behavior, -1 as last day, variants rotating in turn, guard_days skipping networks, and the duplicate-guard warning example. It does not explain every parameter, but it enriches the most semantically complex ones.

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: it sets up a post that repeats on a schedule. It immediately distinguishes the tool from ordinary scheduling by explaining recurrence, variants, guard behavior, and queued occurrences.

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, including that occurrences become ordinary scheduled posts, go through approval rules and plan limits, and are available on paid plans but not Free. It does not explicitly name sibling alternatives such as schedule_post or bulk_schedule, so it falls short of full when-to-use/when-not guidance.

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

Set up a recurring post

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools