Skip to main content
Glama

Tailwind App

create_post

Use this when the user wants to create a Pinterest Pin from an image or video — as a draft (omit both sendAt and useNextOpenSlot), or published on a schedule. A 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, and it stays unpublished until it is scheduled with schedule_post. To schedule, pass title, description, url, EITHER boardId (numeric ID from list_boards) or intervalBoards, and ONE of: useNextOpenSlot: true, which places the Pin in the account's next open smart schedule slot, or sendAt, an explicit ISO 8601 time. To publish the SAME Pin to several Boards spaced over time — Tailwind's interval Pinning, and what a saved Board list describes — pass intervalBoards instead of boardId, with intervalType for the spacing; do that rather than calling create_post once per Board, which would publish them all at once. Prefer useNextOpenSlot whenever the user has not named a specific time ("schedule this", "post it at a good time", "add it to my queue") — Tailwind's smart schedule is the product, and it applies the account's Pin Spacing rules for the destination URL, which an invented timestamp cannot. Reserve sendAt for a time the user actually asked for. Scheduling is the charged step — drafts are free, and what a scheduled Pin costs depends on the account's billing: modular-billing accounts with Publishing access, whether subscribed or granted, spend one Pin credit per Pin, except on winback plans, which schedule without charge; modular accounts without Publishing draw on a limited free-trial allowance; and legacy and Shopify accounts spend no credits at all, bounded by their plan's post limit for the billing period instead. To put the Pin in a Board section, pass boardSectionId alongside boardId (from list_board_sections). The media comes from exactly one of two sources: mediaUrl for anything with a public URL, or uploadId for the user's own file bytes, staged first with create_media_upload. To create a multi-image carousel Pin instead of a single image, pass carouselItems: two to five images total, the cover in mediaUrl/uploadId and the rest as carouselItems, each with its own mediaUrl or uploadId — images only, no product tags, and every image must share the same width-to-height ratio. Returns the new Pin's postId. To change an existing Pin's title, description, link, Board, Board section, alt text or product tags, use update_post rather than deleting and recreating it — only a change of image needs delete_post plus a fresh create_post. To schedule an existing draft, use schedule_post. Neither this tool nor a Pinterest Pin has a keyword field: a keyword reaches Pinterest only as words in the Pin's title or description. Tailwind keeps keywords in the organization's Saved Keywords list, where each term can be tied to destination URLs; that list is what the Pin Scheduler's Add keywords control shows for a Pin's link. list_saved_keywords with url returns the keywords saved for a Pin's link, and save_keywords with urls adds terms to that list. 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

NameRequiredDescriptionDefault
urlNoDestination URL when the pin is clicked. Required when scheduling — it is also what Pin Spacing rules are keyed on, so useNextOpenSlot needs it.
titleNoPin title (max 100 characters). Required when scheduling.
sendAtNoExplicit publish time (ISO 8601, e.g. 2025-01-15T10:00:00Z), in the future. Use only when the user named a specific time — otherwise use useNextOpenSlot. Cannot be combined with useNextOpenSlot. Omit both for a draft. Requires title, description, url, and either boardId or intervalBoards. 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.
altTextNoAlt text for accessibility (max 500 characters)
boardIdNoTarget Pinterest board ID. Must be the numeric board ID (e.g. "1106196864631757445") from list_boards — not a board name or URL. Required when scheduling.
mediaUrlNoPublicly accessible URL of the image or video to pin. Exactly one of mediaUrl or uploadId is required; must be omitted when uploadId is provided.
uploadIdNoThe uploadId from create_media_upload, once its bytes are staged: during that call when it carried an attached file, otherwise by a PUT to its uploadUrl. This is how a file with no public URL gets pinned. Single-use: it can be attached to exactly one Pin. Exactly one of mediaUrl or uploadId is required; must be omitted when mediaUrl is provided.
accountIdYesNumeric Tailwind account ID returned by list_accounts
mediaTypeNoType of media (default: image). Ignored when uploadId is provided — the upload's own extension already determined its type.
descriptionNoPin description (max 800 characters). Required when scheduling.
intervalDaysNoExact number of days between Boards, overriding intervalType's preset. Use for a gap the presets do not cover — e.g. intervalType "weekly" with intervalDays 14 for a fortnight.
intervalModeNoHow each Board's time is chosen. "slots" (the default) lands every Board on a real smart schedule slot, so the gap may stretch when slots are full — prefer it. "exact" lands each Board exactly the interval after the previous one, keeping the first Pin's time of day, and ignores the schedule.
intervalTypeNoHow far apart the Boards publish. Required with intervalBoards, and only valid with it.
carouselItemsNoTurns this into a carousel Pin: further images in order after the cover in mediaUrl/uploadId, one to four entries so the carousel holds two to five images total (Pinterest's limit). Images only — a video carousel is rejected, as are product tags, and every image (cover included) must share the same width-to-height ratio. Each entry takes a mediaUrl or an uploadId, and the two forms can be mixed across entries.
boardSectionIdNoSection of boardId to publish into. Requires boardId, and is rejected if it is not a section of that board. Omit to publish to the board root. Use list_board_sections to look up section IDs.
intervalBoardsNoPublish this one Pin across several Boards, spaced out over time — Tailwind's interval Pinning. Give the Boards in the order they should publish; the first is the Board the Pin itself lands on and the rest follow one interval apart. Use this instead of boardId whenever the user wants one image on several Boards ("pin this to all my recipe boards", "spread this across my boards weekly"), rather than calling create_post once per Board — that would publish them all at the same time, for the same cost. Requires intervalType, and sendAt or useNextOpenSlot. Cannot be combined with boardId. Each Board becomes its own scheduled Pin and is charged accordingly: one Pin credit each on modular billing with Publishing access (winback plans excepted), and no credits on legacy and Shopify accounts, where they count against the plan's post limit instead.
isSimplifiedPinNoWhether to create a simplified pin (default: true). Set to false for a standard pin.
useNextOpenSlotNoSchedule 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. Cannot be combined with sendAt. Omit both for a draft. Requires title, description, url, and either boardId or intervalBoards.
productTagPinIdsNoPinterest product-catalog pin IDs to tag on the pin (business accounts only; max 24). Providing any forces a simplified pin, since Pinterest rejects tags on standard pins.

Output Schema

NameRequiredDescriptionDefault
postYes
intervalPostsNoEvery Pin an intervalBoards create produced, in Board order and including `post` itself. Absent for a single-Board Pin. This is the only place the grouping appears — each Pin is stored as an ordinary single-Board Pin, so a later get_post or list_posts cannot tell they belong together. Keep these IDs if the user may want to change or delete the set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / intervalPosts / items / 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"
      +}
    • 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"
      +}
  2. Changed2 schema fields changed
    • changedOutput schema / properties / intervalPosts / items / 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"
    • 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"
  3. Changed2 schema fields changed
    • changedOutput schema / properties / intervalPosts / items / 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"
    • 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"
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds the non-obvious consequences: a draft exists only in Tailwind and never reaches Pinterest, scheduling is the charged step with a per-billing-model cost breakdown, uploadId is single-use, and each intervalBoards entry becomes its own charged Pin. Nothing here conflicts with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded correctly — prose before scheduling before media before sibling routing — but at roughly 600 words it over-runs what a tool description needs. The keyword paragraph wanders into Saved Keywords behavior and two other tools' semantics, and the modular/legacy/winback billing breakdown is longer than the decision it supports.

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 19-parameter mutation tool this leaves nothing material unsaid: draft vs. publish semantics, required field combinations, carousel constraints, section placement, cost model, account disambiguation, and the return value (postId, also covered by the output schema). An agent has everything needed to call it correctly on the first attempt.

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?

With 100% schema coverage the schema already documents each parameter, so per the baseline this would be a 3. The description earns one more by adding cross-parameter semantics the schema states only locally: the media source must be exactly one of mediaUrl/uploadId, boardSectionId goes alongside boardId and must belong to that board, and intervalBoards requires intervalType plus sendAt or useNextOpenSlot. The carousel ratio/mixed-source rules are also restated in prose form an agent can act on.

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 opening sentence names a specific verb and resource (create a Pinterest Pin) and immediately splits the two modes — draft vs. scheduled — with the exact parameter condition distinguishing them. It also names the siblings it is not (schedule_post, update_post, delete_post, create_media_upload, create_post called per-Board), so an agent can place it in the toolset without opening a schema.

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?

Explicit routing rules throughout: use useNextOpenSlot when the user named no time, reserve sendAt for an explicitly named time, use intervalBoards rather than calling create_post once per Board, use update_post for edits and delete_post plus a fresh create_post only for an image change, and ask the user which account when list_accounts returns several. Each alternative comes with the condition that selects it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources