Skip to main content
Glama

Tailwind App

list_board_pins

Read-onlyIdempotent

Use this when the user wants to see, audit, export or reorganize the Pins already saved on one of their Pinterest boards, including secret boards: what is on a board, what was added to it recently, or which Pins sit in which section. Returns every Pin on the board however it got there, with its Pinterest URL, image URL, destination link, saved time and section. Free: no credits. get_board_keyword_relevance only scores a board's Pins against a keyword and spends a credit, so it is not a way to list them.

Pins come in Pinterest's board order, which is mostly newest first but not strictly; to sort by date, sort by createdAt yourself. startDate and endDate filter on createdAt (when the Pin was saved to the board) and either may be given alone. A page can hold fewer Pins than limit, or none, while cursor is still returned: keep calling with that cursor until it is absent, and only then report the board as fully listed. boardSectionId matches list_board_sections, and is null for a Pin on the board itself. pinId is the PINTEREST Pin id, which get_pin_analytics and save_pins_to_board take; it is not a Tailwind postId. imageUrl is a link to the image, not the image itself. 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
limitNoPins to read from Pinterest per page, 1 to 250. Defaults to 100.
cursorNoThe cursor from the previous list_board_pins response, to fetch the next page
boardIdYesNumeric Pinterest board ID returned by list_boards, never a board name
endDateNoOnly Pins saved at or before this UTC date-time, e.g. 2026-10-07T23:59:59Z
accountIdYesNumeric Tailwind account ID returned by list_accounts
startDateNoOnly Pins saved at or after this UTC date-time, e.g. 2026-10-01T00:00:00Z

Output Schema

NameRequiredDescriptionDefault
pinsYesPins on this page, in Pinterest's board order
cursorNoPass back as cursor for the next page. Absent once every Pin on the board has been listed.
boardIdYes
accountIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds substantive context beyond them: no credit cost, pagination semantics where a short or empty page may still include a cursor, non-strict newest-first ordering, and ID/link distinctions such as pinId being the Pinterest ID rather than a Tailwind postId.

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

Conciseness5/5

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

The description is front-loaded with purpose and use cases, then moves through return behavior, pagination, parameter semantics, and account handling. Although long, the sentences are information-dense and each addresses a real ambiguity.

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?

With an output schema present, the description still covers pagination termination, date filtering, section IDs, account selection, and ID types. That is enough for an agent to invoke the tool correctly in ambiguous cases.

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 100%, so the baseline is 3. The description adds meaning beyond the schema: startDate and endDate filter on createdAt when the Pin was saved, boardSectionId matches list_board_sections and is null for board-level Pins, and pinId is the Pinterest Pin ID used by get_pin_analytics and save_pins_to_board.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (Pins already saved on a Pinterest board) and scope (secret boards, sections, saved time), and distinguishes it from get_board_keyword_relevance. It does not explicitly differentiate from the sibling list_pins, so a 4 rather than a 5.

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 gives explicit trigger conditions ('when the user wants to see, audit, export or reorganize...') and a when-not case: get_board_keyword_relevance only scores against a keyword and spends a credit. It also handles account ambiguity by instructing to ask the user when multiple accounts exist.

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