Tailwind App

get_recommended_pins

Read-onlyIdempotent

Use this when the user asks what Pins they should add to a board, how to fill a gap on a board, or wants content ideas for a board and keyword. Searches Pinterest's public content for Pins matching the keyword, drops any the board already has and any promoted/ad content, and returns what is left ranked strongest first, each with its own relevance as the reason it fits. Free — this spends no plan credits, unlike get_board_keyword_relevance. Pairs with that tool: score the board first to find a weak keyword, then call this to fix it. These are candidates from across Pinterest, not the user's own Pins, so present them as suggestions to review rather than as content they already own. To act on the result, pass the ids the user picked to save_pins_to_board — that saves these existing Pins onto the board, and is the middle step of build-a-board-about-X: create_board → get_recommended_pins → save_pins_to_board. Use create_post only when the user wants a new Pin of their own instead of saving one of these. An empty list means nothing on-topic was found for that keyword, not that the board is bad. Results exclude Pins added with save_pins_to_board too: a save stores a copy under a new id, and the exclusion matches that copy back to the Pin it was saved from, so calling this again after a save returns what is still missing rather than re-suggesting what was just added. 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
`limit`	No	How many recommendations to return (1-25). Defaults to 10.
`boardId`	Yes	Numeric Pinterest board ID from list_boards — never a board name or URL
`keyword`	Yes	The keyword or topic to find Pins for
`accountId`	Yes	Numeric Tailwind account ID returned by list_accounts

Output Schema

Name	Required	Description	Default
`pins`	Yes	Recommended Pins, strongest first

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/open-world, and the description still adds substantial non-obvious behavior: no plan credits spent, promoted/ad content dropped, already-on-board Pins excluded, exclusion tracking through save copies, and empty-list meaning. It also clarifies provenance (these are other people's Pins, present as suggestions), which directly shapes how an agent should phrase the result.

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?

Trigger conditions are front-loaded in the first sentence and the workflow/alternatives follow in a logical order. It is long and a few clauses (the save-copy exclusion detail, the account-disambiguation note) could be tightened, but nothing is padding.

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?

An output schema exists, so return shape needn't be explained, yet the description still covers ordering, per-item relevance rationale, and the empty-result case. Combined with the workflow ordering and prerequisite on account selection, an agent has everything needed to call and interpret this correctly.

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

Parameters3/5

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

Schema coverage is 100%, so boardId, keyword, accountId, and limit are all documented in structured fields; baseline 3 applies. The description does add indirect meaning about boardId (it drives the already-on-board exclusion) but says nothing about limit or accountId beyond what the schema states.

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?

States a specific verb chain (search Pinterest public content, filter, rank) and a specific resource (candidate Pins for a board + keyword). It explicitly distinguishes itself from get_board_keyword_relevance, save_pins_to_board, and create_post, so an agent can place it without opening any 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?

Gives concrete trigger conditions ('user asks what Pins they should add to a board, how to fill a gap'), names the alternatives and when to prefer each (score first with get_board_keyword_relevance; use create_post for a brand-new Pin), and lays out the build-a-board-about-X sequence. It also states a prerequisite behavior: ask the user which account when list_accounts returns multiple.

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?