Tailwind

View saved version →

---
name: onboarding
description: Set up Tailwind after it is installed in ChatGPT. Use when the user chooses Set up for Tailwind or asks to get started with Tailwind: confirms which Pinterest account to use, shows upcoming Pins, explains where the Tailwind sidebar app is and how to pin it, and suggests first things to try.
---

# Set up Tailwind

Tailwind schedules and creates Pinterest Pins for the user's connected Pinterest
accounts. Setup is a short, read-only walkthrough. It creates, schedules and
changes nothing, and it does not spend plan credits. The user can skip any step
or stop at any time. If they installed Tailwind in the middle of another task,
setup is brief and the conversation goes back to that task afterwards.

The steps below go in order. Each one is one short message, and a question gets
the user's answer before the next step starts.

Speak to the user directly throughout. Never quote these setup instructions or
mention that a skill or instructions say to do something; just do it.

## 1. Confirm the Pinterest account

`list_accounts` returns the Pinterest accounts connected to the user's Tailwind
organization. What happens next depends on the result:

- **One account:** name it by display name and username, and ask the user to
  confirm it is the account they want to use with Tailwind.
- **Several accounts:** list them by display name and username, and ask which
  one to use for the rest of setup. Tailwind does not pick one on the user's
  behalf.
- **No accounts:** the user's Tailwind organization has no Pinterest account
  connected yet. Accounts are connected from the Tailwind dashboard at
  tailwindapp.com, not from ChatGPT. If the user believes one is already
  connected, they may be signed in to a different Tailwind organization.
  Setup ends there, with an offer to pick it up again once an account is
  connected.

An account with `tokenStatus: "unauthorized"` has lost its Pinterest
connection, and nothing scheduled on it will publish until the user reconnects
it from the Tailwind dashboard at tailwindapp.com. Say so plainly when the
chosen account is in that state. `tokenStatus: "unknown"` means Tailwind could
not check the connection just now; it is not a reason to ask for a reconnect.

The chosen account applies to this conversation only. Other conversations ask
again when the user has more than one account.

## 2. Show what is coming up

`list_posts` with the chosen `accountId` and the default status (`queued`)
returns the Pins scheduled to publish. Where ChatGPT shows the result as Pin
cards, one sentence of framing is enough ("Here is what is scheduled next"):
the cards carry the titles, images and times, and a text list repeating them
adds nothing. Without cards, a short list of the next few Pins with their
times does the same job.

An empty result is normal for a new user. In that case, say nothing is
scheduled yet and go on to the next step.

## 3. The Tailwind sidebar app

This step applies only when `open_schedule_calendar` is among the available
tools. Without it, the calendar is not offered on this connection, so skip this
step and say nothing about a sidebar.

Tailwind has a calendar of the user's schedule that opens from ChatGPT's
sidebar, with weekly, 3-day and monthly views and a switcher between accounts.
ChatGPT does not pin it by default: it sits as "Tailwind Scheduler" in the
list behind the "…" (More) item in ChatGPT's sidebar. Hovering the "Tailwind
Scheduler" row there shows a pin icon on that row, labelled **Pin to
sidebar**; clicking it pins the calendar. Explain where it is and how to pin it, in those terms. Pinning is
something only the user can do; offer to open the calendar now with
`open_schedule_calendar`, and open it only if they say yes.

## 4. Things to try

Close with two or three prompts the user can send next, chosen to fit what step
2 showed. Examples:

- "Draft a Pin from my latest blog post: <link>"
- "What do I have scheduled this week?"
- "Schedule my next Pin at the next open time slot."
- "Show me my Boards."

Setup ends here. Anything the user asks for next is an ordinary request, not
part of setup.

View saved version →

---
name: tailwind-pinterest-board-audit
description: Audit how a connected Pinterest account's boards are organized through Tailwind — naming consistency, stale boards, board list coverage, dead list entries, and publishing timeslots, with optional public group board benchmarks. Use when the user asks for a board audit or wants to review their board setup.
---

# Pinterest board organization audit

This audit reports on how an account's boards are **organized**: what they are
called, which ones are covered by a board list, which list entries point at
boards that no longer exist, and whether a publishing schedule is configured.

It is read-only and consumes no credits.

It says nothing about whether a board is *good*. Board quality, topical
relevance, and performance are not visible here, and inventing them from board
names is the failure mode this audit is written to prevent.

## Gather the data

1. `list_accounts` — resolve the account. Ask which one if there are several.
2. `list_boards` — every board, with `isSecret`, `isCollaborator`, its
   description when it has one, `followerCount`, `pinCount`, and
   `pinsModifiedAt` when Pinterest has one.
3. `list_board_lists` — the account's board lists and their ordered entries.
4. `list_timeslots` — the configured publishing schedule.

If `list_board_lists` returns nothing, no board list on the account holds any
boards. That is a valid setup, not a finding on its own — report it as context.
Do not report it as "no board lists configured": a list that exists but holds
no boards is invisible to this endpoint, so an empty result cannot tell the two
apart.

## The checks

Every check below is mechanical. Compute it, report the count, and stop. None
of them requires a judgement about whether a board is worth having.

**Inventory.** Total boards, split by `isSecret` and `isCollaborator`. Secret
boards are private to the user and collaborator boards belong to someone else —
both are worth separating out, because advice that applies to a user's own
public boards often does not apply to either.

**Naming consistency.** Bucket board names by case convention — all lowercase,
Title Case, ALL CAPS, and anything else — and report the counts. A single
dominant convention with a few outliers is worth naming; an even spread is
worth reporting as "no consistent convention". Report the outliers by name so
the user can act.

**Duplicate names.** Report exact duplicates, and names that differ only by
case or whitespace. These are genuinely confusing when picking a board to
publish to, and they are unambiguous to detect.

**Missing descriptions.** Boards with no description. `list_boards` leaves
the field out entirely for those boards, so a missing field is the finding.
Report them by name.

**Pin counts.** Boards with a `pinCount` of zero. The count comes from a
cached snapshot and can lag behind Pinterest, so treat it as a lower bound:
say a board *may* be empty, not that it is.

**Stale boards.** Boards whose `pinsModifiedAt` is more than 90 days before
today. `pinsModifiedAt` is when Pinterest last recorded a change to the
board's Pins (ISO 8601; the text output shows it as "Pins last changed").
It is a last-activity date, not the date of the newest Pin: Pinterest does
not say which changes move it. Ninety days is a heuristic, not a Pinterest
rule, so say so, and report each stale board by name with its date. A board
with no `pinsModifiedAt` has unknown activity: count those separately and
never report them as stale.

**Board list coverage.** Boards present in `list_boards` but absent from every
board list. These are boards no grouping publishes to.

**Dead list entries.** Board ids inside a board list that do not appear in
`list_boards`. These point at boards that have been deleted or are no longer
on the account, and they are a known cause of failed Pins — a user cannot see
them from the Pinterest side, which is why this check earns its place.

**Ordering.** Report each list's entries in `order`. Report it verbatim. There
is no correct order to compare against.

**Timeslots.** Total configured slots, and which days of the week have none.
An account with no timeslots at all has no recurring schedule to publish into,
which is a real finding — but do not report it as being unable to schedule
Pins. Scheduling accepts an explicit time regardless of whether any slot
exists. Days with no slots are context, not a defect.

## Optional: public benchmark context

Only when the user supplies target keywords. Call `list_group_boards` with a
keyword and **check `status` before reporting anything**:

- `ready` — report the boards. An empty list means a completed search genuinely
  found no public group boards for that keyword. Say that.
- `warming` — a search is running and nothing is cached yet. Tell the user to
  check back. Do **not** report this as "no group boards found".
- `unavailable` — the search failed. Say the benchmark is unavailable for that
  keyword and continue with the rest of the audit.

These are **other people's public boards**, scraped from Pinterest. They are
context for how boards in a niche are named and sized. They are not the user's
boards, and their board ids cannot be used for scheduling.

Group boards are not Tailwind Communities. Communities (formerly Tribes) has no
MCP tool. Tailwind is replacing it with Turbo Groups, which has no tool either;
the user finds their Turbo Groups under My Groups in Turbo, in the Tailwind app.
A request for either one is a missing capability that `request_capability`
records; Pinterest group boards (`list_group_boards`) are a different feature
and do not answer it.

The benchmark is optional in the strict sense: the audit must be complete and
useful without it. If the scrape path returns nothing at any keyword, produce
the full API-only report and note that benchmark context was unavailable.

## Report structure

1. **Audit scope and data sources** — the account audited, and which of the two
   sources below each section draws on.
2. **Healthy checks** — what is in good shape.
3. **Findings and recommended actions** — ordered by consequence. Dead list
   entries and no-timeslots come before naming inconsistency.
4. **Public benchmark context** — only when requested and available.
5. **Not available in this audit** — the section below.

Label every claim with its source. Two labels are in play here and they are not
interchangeable:

- **Tailwind account data** — the user's own boards, lists, and timeslots.
- **Public scraped context** — group boards from `list_group_boards`.

A reader must never have to guess whether a number describes their account or
somebody else's. Never merge counts from the two sources into one figure.

## Not available in this audit

Say these explicitly:

- **When the last Pin was added.** `pinsModifiedAt` is the last recorded
  change to a board's Pins, not the newest Pin's date, so "your last Pin here
  was on this date" cannot be stated. The benchmark section describes other
  people's boards and says nothing about the user's.
- **Actual posting cadence.** Timeslots are the *configured* schedule, not
  observed publishing history. A full slot list does not mean Pins went out.
- **Board lists holding no boards.** `list_board_lists` only returns lists with
  boards in them, so an empty list is indistinguishable from one that was never
  created. Never state that an account has no board lists configured.
- **Private boards of other accounts.** The scrape path sees public boards only.
- **Board-to-keyword relevance.** This audit does not score it, and it must
  not be inferred from board names. `get_board_keyword_relevance` scores one
  board's live Pins against a keyword, but each scored call spends a plan
  credit, so offer it for the boards the user cares about rather than running
  it as part of the audit.
- **Performance.** Saves, impressions and clicks are not part of this audit.
  `list_top_pins` returns each top Pin's `boardId`, which is how to compare
  boards by performance when the user asks; it costs nothing.

When the user asks for one of these, name the gap and stop. Do not answer it
with a proxy — "you have 40 boards and only 12 in a list, so your reach is
probably suffering" is an invented conclusion, and it is the specific failure
this section exists to prevent.

View saved version →

---
name: tailwind-pinterest-draft-review
description: Review the Pinterest Pin drafts that Tailwind's AI generated — from a URL generation or a connected feed — against the user's own criteria, then schedule the good ones, fix the nearly-right ones, and discard the rest. Use when the user asks to review, approve, clear out, or publish their generated, AI-drafted, or SmartPin drafts, or to run that review on a schedule.
---

# Reviewing Tailwind's generated Pin drafts

A Pin that Tailwind's AI generates, from `generate_pins_from_url` or a
connected feed, is saved as a draft. It never publishes on its own: someone
has to look at it and either schedule it or discard it, and most people never
come back to do that, so generated Pins sit unpublished and the credits that
made them are wasted. This playbook is that review, done by you against the
criteria the user gives.

The tools' own descriptions cover their parameters. This file covers what
they cannot: the traps where a correct-looking review run still goes wrong.
The long-form version, with REST equivalents, is at
https://api-docs.tailwind.ai/guides/reviewing-generated-drafts.

## The criteria are the user's, not yours

Tailwind stores no review criteria and applies none of its own. The criteria
come from the user's request or from standing instructions they have given
you. If you have neither, ask before judging anything. Do not invent a
standard from the drafts themselves: a review that approves whatever looks
fine to you is not the review the user asked for, and scheduling spends
their credits.

Do not tell the user to write their criteria into this file. The installer
rewrites it on every run and plugin updates replace it, so anything stored
here is lost on the next upgrade. Their own instructions or project notes
are the right home.

## A review is not permission to act

"Review my drafts" asks for judgements, not for Pins on the schedule or in
the bin. Unless the user's request or their standing instructions say to
schedule what passes and delete what fails, stop after judging: report what
you would approve, fix, and discard, with the reason for each, and let the
user say which to apply. Scheduling spends their credits and deletion cannot
be undone, so neither is a side effect of being asked to look.

A run with no one watching, from a scheduled task or a cron, is the case to
be strict about. It can act only on a standing instruction that names the
actions: "schedule the ones that pass and delete the ones that fail". A
standing instruction that only gives criteria licenses the report, not the
changes.

## Find the drafts

Call `list_accounts` first and use a numeric account ID from it. If there is
more than one account and the user has not said which, ask.

Then `list_posts` with `status: "draft"` and `limit: 100`, and follow
`cursor` until a response comes back without one. Every draft assigned to
the account lists here, hand-made ones included. The generated ones carry a
`generationId`, and in the result text their line starts with `Generated`.
Those are the only drafts this review touches. A draft with no
`generationId` was made by hand, or through the API, and is left exactly as
it is: never scheduled, edited, or deleted by this workflow unless the user
asks for that separately.

A generated draft is "unreviewed" only in the sense that it is still a draft.
Tailwind keeps no record that a draft was looked at. Once it is scheduled or
deleted it leaves the list; until then it stays, however many times it has
been considered.

Drafts not yet assigned to any Pinterest account, such as some Made For You
drafts, do not list. The Pin Scheduler in the dashboard counts them in a
"drafts that aren't assigned to a Pinterest account yet" banner, and the
user assigns them from there. So the draft count here can be lower than the
dashboard's by that number. That is expected, not missing drafts, but a
larger gap is worth reporting.

## Judge each one

Each draft carries its title, description, destination link (`url`) and
image (`mediaUrl`). Compare those with the criteria. Three outcomes: approve
as is, fix then approve, or discard.

To see the picture, call `get_post_image` with the draft's `postId`. Not
every client passes the image on to the model. If it did not arrive, say so,
judge on the copy and link only, and never describe what the picture
"probably" shows. A criterion about the image that you cannot check is a
draft to leave for the user, not one to approve.

A draft you are unsure about is left where it is. It stays in the list and
comes up again next time. Leaving a draft is always safe; the other two
decisions are not.

## Fix the nearly-right ones

Copy and placement are edited in place with `update_post`, which is free.
Only the fields you send change. Fix a title, description, link, Board or
Board section this way rather than deleting and recreating the Pin, which
would throw away the generated design.

The picture is a separate surface. For a generated draft, call
`get_pin_design` and follow the `supportedOperations` it reports; the
operations differ by design tier, and calling one the Pin does not support
is rejected. `update_pin_design` re-renders a template design with a new
overlay title, colors or image for free, and `select_pin_design_variation`
switches to a design Tailwind already has, also free. The design read lists
the other pictures Tailwind found on the source page, so a wrong photo is
usually a free swap. `regenerate_pin_design` has the AI design a new one for
about 7 credits, runs asynchronously, and produces a variation you still
have to apply with `select_pin_design_variation`. Ask before spending that;
a review the user expected to be free should not come back having bought
new designs.

## Approve the good ones

Approving a draft is scheduling it. Call `schedule_post` with
`useNextOpenSlot: true`. That claims the account's next open smart schedule
slot and applies the account's Pin Spacing rules for the Pin's link. Never
compute a `sendAt` from `list_timeslots` or `get_schedule`: a slot that
reads as open can already be taken, and `sendAt` ignores Pin Spacing, so
approved Pins stack up off-schedule. A draft without a Board also needs
`boardId` on that call, a numeric ID from `list_boards`.

Scheduling is the charged step. On modular-billing accounts it spends one
Pin credit per draft (free on winback plans; a free-trial allowance where
the account has no Publishing access), and legacy and Shopify accounts count
it against the plan's post limit instead. Check `get_account_usage` before
a large batch. A payment-required error is a real billing outcome, not a
transient failure: stop scheduling, tell the user how many drafts remain,
and do not retry.

After the batch, confirm it landed with `list_posts` using
`status: "queued"` rather than trusting the response text alone.

## Discard the rest

A draft that fails the criteria and is not worth fixing is deleted with
`delete_post`. Deletion cannot be undone. It is also what keeps the next run
from judging the same draft again, so a draft you discard should be one the
criteria clearly reject, not one you were on the fence about. On the fence
means leave it.

## Running it again

Nothing in Tailwind starts the next run; the user does, or a scheduled task
in your own client does. The workflow is safe to repeat for the drafts it
decided: an approved draft leaves the list when scheduled and a discarded
one when deleted, so a later run only sees what was left.

Two runs that overlap can both try to schedule the same draft. The second
`schedule_post` then fails with a conflict, because the draft is no longer a
draft, and nothing is charged for the failed call. Treat that conflict as
"already decided": re-list before acting on anything else from the stale
page, and do not retry it. Overlap is still worth avoiding, since each run
reads the whole list; give a scheduled task an interval longer than a run
takes.

One trap. A generated Pin that was approved and later taken off the schedule
with `unschedule_post` returns to the draft list with its `generationId`,
and nothing marks it as already reviewed. The next run judges it again and
may schedule or delete it. If the user held a Pin back on purpose, they need
to tell you which one, or expect it to be decided by the criteria again.

## Report what you did

List each draft by title and `postId` under four headings: approved, fixed
then approved, discarded, and left for the user. Say what each fix changed
and why each discard failed the criteria. Say how many hand-made drafts
were skipped, so the user knows the list was read in full. If any picture
could not be seen, say so once rather than per draft.

## Not available in this review

Say these explicitly when they matter:

- **Whether a draft was reviewed before.** Tailwind keeps no record, so a
  draft in the list is one that was never decided, or one that was decided
  and unscheduled; the two look the same.
- **The criteria.** Tailwind has none to read back. If the user asks what
  standard their drafts were judged by, the answer is whatever they gave
  you, and nothing else.
- **How the draft will perform.** Nothing in a draft predicts saves or
  clicks. `get_account_analytics` and `list_top_pins` describe what already
  published Pins did, which can inform the user's criteria but is not a
  judgement on a draft.
- **The picture, in some clients.** See above. A review that could not see
  the images is a review of the copy, and the report should say so.

View saved version →

---
name: tailwind-pinterest-profile-audit
description: Audit the health of a connected Pinterest account's profile through Tailwind — authorization, domain verification, and profile completeness. Use when the user asks for a profile audit, an account checkup, or why their account may not be publishing.
---

# Pinterest profile health audit

This audit reports on the profile fields Tailwind can verify directly for a
connected Pinterest account. It is read-only: it consumes no credits, creates
nothing, and changes nothing.

It is also narrow, and the narrowness is the point. Users asking for an
"account audit" usually want to know why their impressions are low. That
question cannot be answered from the profile fields below, and guessing at it
from them produces confident advice built on nothing. Report what the checks
show, then say plainly what this audit cannot see.

## Run the checks

Call `list_accounts`. Every field this audit reports comes from that one call.

If the user has more than one connected account and hasn't said which, ask
rather than auditing all of them — a report about the wrong profile reads as
authoritative and wastes the user's time acting on it.

Check each field below against its healthy value. A field that is missing,
false, or not the healthy value is a finding, with one exception:
`tokenStatus: "unknown"` is not a finding (see below).

| Field | Healthy | Finding means | User action |
| --- | --- | --- | --- |
| `tokenStatus` | `"authorized"` | `"unauthorized"`: Tailwind cannot publish to this account at all. Nothing else in this report matters until it is fixed. | Reconnect the Pinterest account from the Tailwind dashboard. |
| `isDomainVerified` | `true` | Tailwind has no verified website domain for this account. | Claim the website on Pinterest, then reconnect in Tailwind so the status refreshes. |
| `avatarUrl` | non-null | No profile image. | Add a profile photo on Pinterest. |
| `username` | non-null | No Pinterest username on record — usually a legacy connection. | Reconnect the account so Tailwind picks up the username. |

`createdAt` is context, not a check. A recently connected account has little
history behind it, which is worth saying when the user is asking why they see
no results yet. Never report it as a problem.

`displayName` is not checkable and must never be reported as a finding. The
API falls back to the Pinterest username when an account has no name set, so
the field is non-empty for an account with no display name just as it is for
one with a display name — the two are indistinguishable from this response.
Claiming a display name is present would be as wrong as claiming it is
missing, so say nothing about it either way.

Order findings by consequence, not by the order above: an unauthorized token
stops publishing outright, a missing profile image does not.

## The domain verification trap

`isDomainVerified` is Tailwind's own record, and users regularly report that
Pinterest shows their site as verified while Tailwind shows it missing. When
you report this finding, say that it reflects what Tailwind has recorded, and
that a reconnect is what refreshes it. Do not tell the user their site is
unverified on Pinterest — you cannot see Pinterest's side of it.

## The connection status trap

Read `tokenStatus`, not `tokenAuthorized`. `tokenAuthorized` is `false` both
when the connection is revoked and when Tailwind could not check it, so an
audit built on it tells a healthy account to reconnect whenever a lookup
fails.

`tokenStatus` is resolved live at request time, so it is trustworthy in a way
the stored fields are not. `"unauthorized"` is the finding. `"unknown"` means
Tailwind could not check the connection just now: report it as context ("the
connection could not be verified right now; try the audit again later"),
never as a reason to reconnect. During a Tailwind service degradation every
account can come back `"unknown"` at once, which is the same situation, not
a fleet of broken connections.

## Report structure

Use these sections, in this order:

1. **Audit scope and data sources** — name the account audited, and state that
   every finding comes from Tailwind account data.
2. **Healthy checks** — the fields that passed. Say them; a report that lists
   only problems reads as a broken account.
3. **Findings and recommended actions** — one entry per finding, each with the
   user action from the table.
4. **Not available in this audit** — the section below.

Label every finding as **Tailwind account data**. This audit has no other
source. That labelling matters because the board audit does mix sources, and a
user reading both should be able to tell where each claim came from.

## Not available in this audit

State these explicitly rather than leaving them unmentioned — an unmentioned
gap reads as a clean bill of health:

- **Performance of any kind.** Impressions, saves, clicks and engagement are
  not part of this audit. `get_account_analytics` reports them for the account
  and `list_top_pins` shows which Pins did best; offer those when the user
  asks why their numbers are low. Their figures describe what happened, not
  why, so they do not license a cause either.
- **Profile content quality.** Bio text, board cover imagery, and whether the
  profile reads well for a niche are not visible.
- **Pinterest-side account standing.** Whether the account is in good standing,
  rate-limited, or has had content flagged is not visible.
- **Whether Pins are being distributed.** Nothing here reports how Pinterest is
  treating the account's content.

Do not substitute a proxy for any of these. "You have no profile image, which
is probably why your impressions are low" is exactly the kind of invented
causation this audit exists to avoid.

View saved version →

---
name: tailwind-pinterest-scheduling
description: Create, schedule, and review Pinterest Pins through Tailwind. Use when the user wants to schedule Pins, pick a Pinterest Board, manage drafts, or check what is queued to publish.
---

# Scheduling Pinterest Pins with Tailwind

The Tailwind MCP server creates and schedules Pinterest Pins on the user's
behalf. Each tool's own description covers its parameters. This file covers the
things the tools cannot tell you — the places where a correct-looking call still
fails.

## Start by resolving the account

Every tool takes an `accountId`, and it is Tailwind's numeric account ID, not a
Pinterest username or profile URL. Call `list_accounts` first and use an ID from
the response. If the user has more than one account and hasn't said which,
ask — publishing to the wrong Pinterest profile is not something you can undo
from here.

## Board IDs are where this usually goes wrong

Scheduling requires `boardId`, and it must be the **numeric board ID as a
string** — for example `"1106196864631757445"`. A Board name, a Pinterest URL,
or a slug will be rejected.

Board IDs come from `list_boards`, which takes the account ID and returns each
Board's numeric ID and name. Call it rather than asking the user to find an ID
by hand.

The same data is also published as a resource:

```
tailwind://accounts/<accountId>/boards
```

If you read it that way, substitute the real account ID — the server advertises
the URI with a literal `{accountId}` placeholder, and reading that string
verbatim will not return the user's Boards. `list_boards` needs no such care,
which is why it is the better route.

## Board sections and several Boards at once

To publish into a section of a Board, pass `boardSectionId` alongside
`boardId`. Section IDs come from `list_board_sections`. A section only belongs
to its own Board, so moving a Pin with `boardId` alone clears whatever section
it was in.

To put one Pin on several Boards, pass `intervalBoards` (in publishing order)
plus `intervalType` in place of `boardId`, on a single scheduled `create_post`
call. Tailwind spaces the Boards out over time. Calling `create_post` once per
Board instead publishes them all at once. Each Board becomes its own scheduled
Pin and is charged like any other scheduled Pin (see credits below).

## Drafts, scheduling, and editing

A `create_post` call that omits both `sendAt` and `useNextOpenSlot` saves a
draft, which is right when the timing is undecided. The draft is saved in
Tailwind only: nothing is created on Pinterest, so it does not appear in
Pinterest's own drafts or on the user's profile. It enters Tailwind's
publishing flow only once it is scheduled with `schedule_post`, so never tell
the user to look for it on Pinterest. To schedule in the same
call, pass **exactly one** of them, plus `title`, `description`, `url`, and
`boardId` (or `intervalBoards`). `schedule_post` puts an existing draft or
queued Pin on the schedule with the same one-of choice, and expects `title`,
`description`, and `url` to already be set. A draft saved without a Board also
needs `boardId` on that `schedule_post` call.

Prefer `useNextOpenSlot: true` unless the user named a specific time. It takes
the account's next open smart schedule slot and applies the account's Pin
Spacing rules for the destination URL, which a timestamp you invent cannot.
Never compute a `sendAt` from `list_timeslots`. Reserve `sendAt` for a time the
user actually asked for. It must be a future UTC instant ending in `Z`, such as
`2026-01-15T15:00:00Z`: a local-offset time like `2026-01-15T09:00:00-06:00` is
rejected as an invalid datetime, so convert the user's local time to UTC first.

An explicit `sendAt` only sets the Pin's first publish time. It is not an
exemption from Pin Spacing: a later respace or schedule shuffle can still move
the Pin, and no tool can lock it in place. To see how far apart Pins to a URL
will land, call `get_pin_spacing_rule` with that URL, or
`list_pin_spacing_rules` for every rule on the account. The rules themselves
can only be changed in the Tailwind dashboard.

After scheduling, confirm it landed with `list_posts` using `status: "queued"`
rather than assuming success from the tool's response text.

To fix a draft or queued Pin's title, description, link, Board, section, alt
text, or product tags, use `update_post`. It is free and never changes when the
Pin publishes. Do not delete and recreate a Pin to fix a typo. The image is the
exception: `update_post` cannot change it, so a new image means `delete_post`
plus a fresh `create_post`. Pins that Tailwind's AI designed have their own
design tools, starting with `get_pin_design`. Published Pins can't be edited
through Tailwind at all.

To take a queued Pin off the schedule without losing it, for example to hold
back a time-sensitive Pin, use `unschedule_post`. The Pin goes back to draft with
its image, copy and Board intact, and the credit charged for scheduling it is
returned where one was taken. Scheduling it again charges again. Do not
`delete_post` a queued Pin just to stop it publishing.

## Scheduling spends the user's credits

On modular-billing accounts, moving a Pin to scheduled consumes a Pin credit
(or free-trial allowance). Winback plans schedule free, and legacy and Shopify
accounts spend no credits; each Pin counts against their plan's post limit
instead. Saving a draft is always free, and rescheduling an already-queued Pin
is not charged again.

Two consequences worth respecting: don't schedule speculatively to "see if it
works" — create a draft instead. And if a call comes back as a payment-required
error, that is a real billing outcome (out of credits, trial exhausted, or no
plan access), not a transient failure to retry. Tell the user what happened
rather than trying again.

## When something fails

- **Rejected board ID** — you almost certainly passed a name or URL. Call
  `list_boards` and use an ID from the response.
- **Missing required field on a scheduled Pin** — `title`, `description`, `url`,
  and a Board are required once `sendAt` or `useNextOpenSlot` is present. Either
  supply them, or drop both timing fields to save a draft instead.
- **`intervalBoards` rejected** — it also needs `intervalType` and one of
  `sendAt` or `useNextOpenSlot`, and it can't be combined with `boardId`. A draft
  can't use it: to save a draft, pass a single `boardId` or no Board at all.
- **`delete_post` fails** — it only works on Pins that have not published yet.
  Published Pins have to be removed from Pinterest directly.