Tailwind

View saved version →

---
name: tailwind-pinterest-board-audit
description: Audit how a connected Pinterest account's boards are organized through Tailwind — naming consistency, 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` and `isCollaborator`.
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.

**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.

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:

- **Board descriptions.** Not exposed for the user's own boards. `list_boards`
  returns id, name, secret, and collaborator status — nothing else.
- **Empty or stale boards.** Pin counts and last-pinned dates are not available
  for the user's own boards, so "this board is empty" and "you haven't pinned
  here in months" cannot be determined. The pin counts in the benchmark section
  are other people's boards and are not a substitute.
- **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.** There is no relevance or quality score here.
  Do not infer one from board names.
- **Performance.** Saves, impressions, clicks, and which boards perform best
  are not available.

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-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 this data, and guessing at it from the fields
below 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. A field that is present and non-empty is a healthy
check; a field that is missing or false is a finding.

| Field | Healthy | Finding means | User action |
| --- | --- | --- | --- |
| `tokenAuthorized` | `true` | 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.

`tokenAuthorized` is resolved live from Pinterest at request time, so it is
trustworthy in a way the stored fields are not. One consequence worth knowing:
during a Tailwind service degradation every account can report `false` at once.
If every account in a multi-account org looks unauthorized simultaneously,
treat that as suspect and say so rather than telling the user to reconnect all
of them.

## 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, outbound clicks, follower
  counts, and profile visits are not exposed here. If the user asked why their
  numbers are low, this audit cannot answer that.
- **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.

## Get the copy right before you create anything

There is no tool to edit a Pin once it exists. `schedule_post` changes only the
time and the Board; `create_post` always makes a *new* Pin. So a draft with the
wrong title, description, media, or destination URL cannot be corrected through
these tools — the only route is `delete_post` and start again.

Confirm the copy and the media with the user **before** calling `create_post`.
Do not save a rough draft intending to refine it later.

The Board is the exception, and the one thing you can safely defer: `boardId`
can be supplied later when you call `schedule_post`.

`create_post` without `sendAt` saves a draft, which is right when the timing is
undecided but the content is settled. Adding `sendAt` schedules it, and makes
`title`, `description`, `url`, and `boardId` all mandatory. `schedule_post`
moves an existing draft or queued Pin to a time and expects `title`,
`description`, and `url` to already be set.

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

`sendAt` is ISO 8601 and must be in the future. Ask the user for their intended
time and time zone instead of inventing one.

## Scheduling spends the user's credits

Moving a Pin to scheduled consumes a Pin-scheduling credit from the user's plan.
Saving a draft does not, 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 `boardId` are only required once `sendAt` is present. Either supply them or
  save a draft instead.
- **`delete_post` fails** — it only works on Pins that have not published yet.
  Published Pins have to be removed from Pinterest directly.