Tailwind App

schedule_post

DestructiveIdempotent

Use this when the user wants to schedule or reschedule an existing Pin draft or queued Pin in Tailwind: takes the postId of an existing Pin (from create_post or list_posts) plus exactly ONE of useNextOpenSlot: true or an ISO 8601 sendAt. Prefer useNextOpenSlot whenever the user has not named a specific time — it places the Pin in the account's next open smart schedule slot and applies the account's Pin Spacing rules for the Pin's destination url, which a timestamp you compute yourself cannot. Reserve sendAt for a time the user actually asked for. The Pin must already have title, description, and url set; a draft without a board also needs boardId (numeric ID from list_boards). Pass boardSectionId to schedule it into a Board section — and note that passing boardId on its own clears any section the Pin already had, since a section is only valid on its own Board. Does not work on published Pins. A draft exists only in Tailwind, not on Pinterest, until this step: scheduling is what puts it into Tailwind's publishing flow. Moving a draft onto the schedule is the charged step: one Pin credit on modular billing with Publishing access, whether subscribed or granted, though winback plans schedule without charge and modular accounts without Publishing draw on a free-trial allowance; legacy and Shopify accounts spend no credits and count it against the plan's post limit instead. Rescheduling a Pin that is already queued costs nothing on any of them. To create and schedule a new Pin in one step, use create_post instead. To take a queued Pin off the schedule and back to draft, use unschedule_post. If the user did not say which Pinterest account to use and list_accounts returns more than one, ask the user which account to use before calling this — do not choose for them.

Input Schema

Name	Required	Description
`postId`	Yes	Post ID of the draft or queued Pin to schedule, from create_post or list_posts
`sendAt`	No	Explicit publish time (ISO 8601, e.g. 2025-01-15T10:00:00Z), in the future. Use only when the user named a specific time. Provide exactly one of sendAt or useNextOpenSlot. It sets only the initial time and is not an exemption from Pin Spacing: a later respace or schedule shuffle can still move the Pin.
`boardId`	No	Target Pinterest board ID. Must be the numeric board ID (e.g. "1106196864631757445") from list_boards — not a board name or URL. Required when scheduling a draft post that doesn't already have a board assigned.
`accountId`	Yes	Numeric Tailwind account ID returned by list_accounts
`boardSectionId`	No	Section to publish into, validated against the board this Pin ends up on. Send "" to publish to the board root. Sending boardId WITHOUT this field clears any section the Pin already had, because a section is only valid on its own board. Use list_board_sections to look up section IDs.
`useNextOpenSlot`	No	Schedule into the account's next open smart schedule slot, honoring its Pin Spacing rules for this Pin's url. Use this instead of computing a time yourself whenever the user has not named one. Provide exactly one of sendAt or useNextOpenSlot.

Output Schema

Name	Required	Description	Default
`post`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

addedOutput schema / properties / post / properties / boardName

Added value: +{
+  "description": "Name of the Board in boardId, as Tailwind last saw it when listing the account's Boards. Returned by get_post and list_posts only; absent when the Pin has no Board or the Board has not been listed yet, such as one just made with create_board",
+  "type": "string"
+}

Changed1 schema field changedOct 29, 2026

changedOutput schema / properties / post / properties / generationId / description

Previous value: -"ID of the AI generation that produced this post, from generate_pins_from_url or a connected feed; absent for posts created any other way. A draft with one is a generated draft waiting for review"New value: +"ID of the AI generation that produced this post, from generate_pins_from_url or a connected feed; absent for posts created any other way. A draft with one is a generated draft waiting for review. Required by get_pin_design and the tools that edit a Pin's design; without it they fail with design_not_found"

Changed1 schema field changedOct 22, 2026

changedOutput schema / properties / post / properties / generationId / description

Previous value: -"ID of the AI generation (generate_pins_from_url) that produced this post; absent for posts created any other way"New value: +"ID of the AI generation that produced this post, from generate_pins_from_url or a connected feed; absent for posts created any other way. A draft with one is a generated draft waiting for review"

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark this as a non-read-only, destructive, idempotent, open-world mutation, and the description layers substantial context on top: prerequisites (title/description/url must be set, boardId needed for boardless drafts), a subtle data-loss trap (passing boardId alone clears an existing section), and the credit/billing consequences by plan type, including that rescheduling a queued Pin is free. That is exactly the kind of consequence disclosure annotations cannot express.

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?

Front-loaded with the decision-critical rule (exactly one of useNextOpenSlot or sendAt) and then the trap and prerequisites, so the most important content comes first. It is a single dense paragraph and the plan-by-plan billing taxonomy (winback, modular trial, legacy, Shopify) is longer than most agents need, costing some economy without burying the leading guidance.

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 six-parameter mutation with an output schema and full schema coverage, everything an agent needs is present: prerequisites, the one-of constraint, the section-clearing hazard, cost implications, account-disambiguation policy, and sibling routing. Return values need not be described because an output schema exists.

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 carries the parameter meanings and the baseline is 3. The description nonetheless adds decision-level semantics the schema does not: why useNextOpenSlot beats a self-computed timestamp (Pin Spacing rules), that exactly one of the two may be supplied, and the boardId/boardSectionId interaction; it also redirects to list_boards for numeric IDs.

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?

Opening clause names the specific verb (schedule/reschedule) and the specific resource (an existing Pin draft or queued Pin in Tailwind), and immediately pins down its identity with the required postId plus one-of sendAt/useNextOpenSlot signature. It explicitly distinguishes itself from create_post and unschedule_post, so an agent can route correctly without opening schemas.

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?

Gives explicit when-to-use rules with a stated default preference (use useNextOpenSlot when the user named no time, reserve sendAt for an explicitly requested time) and names the alternatives for adjacent tasks (create_post, unschedule_post). It also adds a real precondition for invocation flow: if the user didn't name an account and list_accounts returns multiple, ask before calling. Exclusions are stated too (does not work on published Pins).

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

All Tailwind App 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?