Tailwind App

unschedule_post

DestructiveIdempotent

Use this when the user wants to take a scheduled (queued) Pinterest Pin off the schedule without losing it, for example to hold back a time-sensitive Pin or revise it before it publishes: moves the Pin back to draft by postId (from list_posts, create_post or schedule_post). The Pin keeps its postId, image, title, description, link, Board, Board section, alt text, product tags and carousel images; only its scheduled time is removed. Works on any queued Pin on the account, whether it was created in Tailwind, through the API or here, including a missed Pin whose time has passed. Any Pin credit charged for scheduling it is returned, as when unscheduling in the Tailwind dashboard; a Pin scheduled on a free-trial allowance or in an earlier billing period, or on a legacy or Shopify plan, has nothing to return. Scheduling the draft again with schedule_post charges again. Only queued Pins can be unscheduled: a published Pin has to be changed in the Pinterest app, and a draft is already off the schedule. Use this rather than delete_post plus a fresh create_post whenever the Pin should be kept. 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	Default
`postId`	Yes	Post ID of the scheduled (queued) Pin to move back to draft, from list_posts
`accountId`	Yes	Numeric Tailwind account ID returned by list_accounts

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.6/5.0

Behavior5/5

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

Goes well beyond the annotations by explaining exactly what is preserved (postId, image, title, description, link, Board, section, alt text, product tags, carousel images) and that only scheduled time is removed. It also discloses non-obvious side effects: Pin credit return behavior, exceptions for free-trial/legacy/Shopify plans, and that rescheduling charges again.

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-loads the core action and conditions before detailing preservation and credit behavior. It is somewhat long and dense, but nearly every sentence carries relevant operational nuance for a destructive scheduling tool.

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?

The tool has an output schema, so return values need not be explained, and the description covers preconditions, preservation behavior, credit side effects, alternatives, and account ambiguity. An agent has enough information to call this correctly without additional context.

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 description coverage is 100%, so both parameters are already documented. The description adds useful sourcing context for postId (list_posts, create_post, schedule_post) and account selection guidance, but does not substantially deepen the schema semantics beyond that.

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: unschedules a queued Pinterest Pin and moves it back to draft by postId. It explicitly distinguishes this from delete_post plus create_post and from schedule_post, so an agent can select it without opening sibling 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?

Provides explicit when-to-use guidance: taking a scheduled Pin off the schedule while keeping it, holding back time-sensitive Pins, or revising before publishing. It also states when-not-to-use it for published Pins and drafts, and gives the account-disambiguation rule when list_accounts returns multiple accounts.

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?