Tailwind App

update_feed

DestructiveIdempotent

Use this when the user wants to pause or resume a feed, or change the defaults applied to the Pins it generates (keywords, design tier and style, regeneration). Takes a feedId from list_feeds; send only the fields to change, and at least one. Pause with status "paused" and resume with status "active". Pausing keeps the subscription but stops the daily check, so the feed's record of already-seen posts stops advancing: everything the site publishes during the pause counts as new on resume and will generate Pins — and spend credits — until the backlog clears (up to 25 per feed per day). If the user wants generation to stop for good without that catch-up, use delete_feed instead. Resuming re-checks the feed's Pinterest account and is refused if it is no longer connected. The account a feed is assigned to cannot be changed. Editing spends no credits.

Input Schema

Name	Required	Description
`feedId`	Yes	The `id` of a feed returned by list_feeds, connect_feed or get_feed
`status`	No	"paused" stops the daily check; "active" resumes it and catches up on posts published during the pause.
`keywords`	No	Keywords applied to every Pin this feed generates, up to 50. Terms from list_saved_keywords work well here.
`designTier`	No	Design treatment for generated Pins, which also sets what each one costs in SmartPin credits. Omitting this leaves the feed on its current tier — it does not reset it to basic — so to move a feed to the cheaper basic tier you have to send designTier explicitly. premium requires premiumStyle.
`premiumStyle`	No	Required when designTier is premium, and must be null or absent otherwise. Send null when moving a feed off the premium tier so its stored style is cleared.
`autoRegenerate`	No	Whether each Pin this feed generates keeps being periodically redesigned on the generationFrequency cadence. Each redesign is a SmartPin generation of its own.
`generationFrequency`	No	How often each generated Pin is redesigned when autoRegenerate is on. This is NOT how often the feed is checked for new posts — that is once a day, always.

Output Schema

Name	Required	Description	Default
`feed`	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?

Goes well past the annotations: discloses the credit-spending catch-up consequence of pausing (backlog up to 25 Pins/feed/day), that resume is refused if the Pinterest account is disconnected, that a feed's account assignment is immutable, and that editing itself costs no credits. This directly explains the destructive hint in operational terms.

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?

Front-loads the trigger condition, then constraints, then consequences — well ordered. Somewhat dense with parenthetical detail (the 25-per-day figure, credit notes), but nearly every sentence carries operational weight.

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?

Covers the decision boundary, required inputs, partial-update rules, side effects, failure modes, and cost implications for a 7-parameter mutation tool; an output schema exists so return values need no explanation. Nothing an agent needs to call this correctly is missing.

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 already 100%, so the baseline is 3, but the description adds patch semantics not encoded in the schema (only send changed fields, at least one) and clarifies status intent. It does not restate designTier/premiumStyle coupling, which the schema already handles well.

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?

Opens with a specific verb and resource plus the three distinct operations it covers (pause/resume, edit defaults), and names delete_feed as the contrasting sibling. An agent can distinguish it from delete_feed and pause_publishing 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?

Explicitly states when to use it, when to prefer delete_feed instead, the partial-update rule ('send only the fields to change, and at least one'), and the exact enum values that pause vs resume. No inference required.

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?