Tailwind App

update_posts

DestructiveIdempotent

Use this when the user has seen and agreed to a bulk Pin edit that preview_update_posts returned, to save it. This is the second of the two calls a bulk edit takes. It takes the same accountId and posts that were previewed and the previewToken the preview returned; a batch that differs from the preview in any way, or a token older than 30 minutes, is rejected with nothing changed, and so is a call with no previewToken. Each Pin is then saved on its own, and results lists every entry in request order as updated, failed (with the reason) or not_attempted (not reached before the time limit; unchanged, and safe to send again). Each updated result's previous holds the edited fields' values from before the edit in this tool's input form; those entries, previewed and saved the same way, undo the edit. An empty title, description or url is absent from previous, since it cannot be emptied again; an empty alt text is reported as an empty string, which clears it. Editing is free and never changes when a Pin publishes. It cannot change a Pin's image or a Pin already published to Pinterest. For a single Pin, update_post is the equivalent call. 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
`posts`	Yes	One entry per Pin: its postId plus at least one field to change. A postId may appear only once.
`accountId`	Yes	Numeric Tailwind account ID returned by list_accounts
`previewToken`	Yes	previewToken from the preview_update_posts call for exactly these posts, within 30 minutes

Output Schema

Name	Required	Description	Default
`results`	Yes	One result per entry, in request order
`summary`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Despite annotations covering destructive/idempotent/open-world behavior, the description adds substantial context beyond them: the 30-minute token expiry, rejection of any batch that differs from the preview with nothing changed, per-Pin results in request order with updated/failed/not_attempted statuses, and undo semantics via previous values. It also discloses limits — cannot change image or published Pins, editing is free and does not alter publish time.

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?

The description is front-loaded with usage conditions and then adds operational detail. It is dense and long, but nearly every clause carries actionable information about validation, partial failure, or undo behavior. A slightly more structured presentation would improve scanability.

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 destructive bulk mutation requiring a preview handshake, the description supplies the full workflow, validation rules, result semantics, undo behavior, limitations, and account-selection prerequisite. Even though an output schema exists, the description correctly explains the important non-obvious return structure (per-Pin updated/failed/not_attempted and previous values).

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?

Schema coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema: the previewToken must come from preview_update_posts for exactly the same posts and be under 30 minutes old, and the posts/accountId must match the preview or the call is rejected. This materially clarifies the required parameters.

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 precise verb and scope: it saves a bulk Pin edit that preview_update_posts returned, as the second of a two-call workflow. It explicitly distinguishes itself from preview_update_posts and from the single-Pin update_post, so an agent can route correctly without opening the 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?

It states exactly when to use this tool: only after the user has seen and agreed to a preview, with the same accountId/posts and the previewToken. It also names alternatives (update_post for a single Pin) and a prerequisite/ambiguity rule (ask the user which Pinterest account if multiple accounts exist).

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?