Skip to main content
Glama
Sign In

Tailwind App

by ai.tailwind
OverviewDiscussionsAdmin

update_post

DestructiveIdempotent

Use this when the user wants to change an existing Pinterest Pin's copy — its title, description, destination link, board, Board section, alt text, product tags, or whether it is a simplified or standard Pin — on a draft or a scheduled (queued) Pin, by postId (from create_post, list_posts or get_post). Supply at least one of title, description, url, boardId, boardSectionId, altText, productTagPinIds or isSimplifiedPin — a call with only accountId and postId is rejected. Use productTagPinIds to tag catalog products on a Pin that was created without them, to change which products it tags, or — with an empty array — to remove its tags; there is no need to delete and recreate the Pin for any of that. Use isSimplifiedPin to switch a Pin between simplified (true) and standard (false) in place, again without recreating it. Moving the Pin with boardId alone clears any Board section it was in, because a section is only valid on its own Board: pass boardSectionId as well to land it in a section of the new Board, or "" to put it at the Board root. Only the fields you send are changed; everything else is left as it is. This edits one Pin per call; the same edit across several Pins goes through preview_update_posts and then update_posts, which take up to 50 Pins at once and show each Pin's before-and-after before anything is saved. Editing is free and does not consume a credit. This does NOT schedule, reschedule or unschedule: use schedule_post or unschedule_post for that, and note the Pin's image cannot be changed at all — that needs a delete_post plus a fresh create_post. A Pin already published to Pinterest cannot be edited through Tailwind; the user has to edit it in the Pinterest app. 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
urlNoNew destination URL for the Pin
titleNoNew Pin title. Cannot be empty.
postIdYesPost ID of the draft or scheduled Pin to edit, from create_post or list_posts
altTextNoNew accessibility alt text
boardIdNoMove the Pin to this board. Numeric Pinterest board ID from list_boards — never a board name or URL
accountIdYesNumeric Tailwind account ID returned by list_accounts
descriptionNoNew Pin description. Cannot be empty.
boardSectionIdNoMove the Pin into this section, validated against the board it ends up on. Send "" to move it 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.
isSimplifiedPinNotrue makes the Pin a simplified Pin, false a standard Pin; omit it to leave the Pin's design as it is. false is refused while the Pin has product tags, since Pinterest rejects tags on standard Pins: send productTagPinIds: [] in the same call to remove them.
productTagPinIdsNoPinterest product-catalog pin IDs to tag on the Pin, replacing whatever tags it has now (business accounts only; max 24). Send an empty array to remove every tag; omit the field to leave the Pin's tags alone. Tagging forces a simplified Pin, since Pinterest rejects tags on standard Pins, and tags are refused on a carousel Pin because Pinterest will not publish that combination — an empty array is still accepted on one, so tags can be cleared off it.

Output Schema

NameRequiredDescriptionDefault
postYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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. Changed1 schema field changed
    • 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. Changed1 schema field changed
    • 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.6/5.0
Behavior4/5

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

Annotations already flag this as a non-readonly, destructive, idempotent mutation, and the description adds real behavioral context on top: partial-update semantics ('Only the fields you send are changed'), the fact that editing costs no credit, the publisher-side restriction on already-published Pins, and the image being immutable. It loses a point because the boardId/boardSectionId clearing rule and the productTagPinIds replacement semantics are largely restatements of what the input schema already documents.

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?

The core is front-loaded and efficient, but the middle section drifts into a three-sentence digression on keywords, the Saved Keywords list, list_saved_keywords and save_keywords that is only loosely connected to editing a Pin. That padding sits between the operational rules and the closing account-disambiguation instruction, diluting a description that would otherwise be tight.

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 10-parameter mutation tool with an output schema, everything an agent needs is present: valid inputs, cross-field constraints, mutation scope, cost, irreversibility paths, sibling routing, and an account-selection prerequisite. Nothing about calling it correctly is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description earns more by adding constraints the schema cannot express — at minimum one of the eight editable fields must be supplied or the call is rejected, postId must come from a listed source, and empty-array productTagPinIds removes tags while isSimplifiedPin toggles design in place. It also ties parameters together (boardId plus boardSectionId, isSimplifiedPin false refused while tags exist).

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 description opens with a specific verb plus resource — 'change an existing Pinterest Pin's copy' — and enumerates exactly which fields are editable (title, description, url, board, section, alt text, product tags, simplified flag). It also states the scope ('This edits one Pin per call', 'draft or a scheduled (queued) Pin'), which cleanly separates it from update_posts, create_post and delete_post.

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 when-to-use with the required identifier source (create_post, list_posts, get_post), explicit when-not for scheduling ('use schedule_post or unschedule_post'), for image changes (delete_post plus create_post), for bulk edits (preview_update_posts then update_posts, up to 50 Pins), and for already-published Pins. It even adds a prerequisite rule: if list_accounts returns more than one account and the user didn't specify, ask rather than choose.

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

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