Skip to main content
Glama
Sign In

Tailwind App

by ai.tailwind
OverviewDiscussionsAdmin

get_post

Read-onlyIdempotent

Use this when the user asks about one specific Pinterest Pin and a postId is already known (from create_post, schedule_post, or list_posts): returns that single Pin's current status, media, title, description, destination url, board, and scheduled or published time. Reading one Pin by ID is the precise way to confirm what a Pin looks like now — paging list_posts to hunt for it is not. It is also how the user sees a Pin's image: clients that show Tailwind's Pin card render this result with the image, which exists only in Tailwind and is not found by a web or image search. A deleted Pin stays readable with status "deleted" for at least 28 days, after which it becomes eligible for automatic purge; once purged, and for a postId that never existed on this account, the call returns a not-found error. 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
postIdYesPost ID of the Pin to read, from create_post or list_posts
accountIdYesNumeric Tailwind account ID returned by list_accounts

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
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context beyond them: deleted Pins remain readable with status "deleted" for ~28 days before purge eligibility, purged or never-existent IDs return a not-found error, and the image is a Tailwind-only asset invisible to web/image search. That is exactly the kind of consequence-and-edge-case disclosure annotations cannot carry.

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-loaded with the trigger condition and the returned fields, then layered with edge cases in rough priority order. It runs five sentences and includes a slightly rhetorical aside ('paging list_posts to hunt for it is not'), but every clause carries operational information.

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, yet the description still names the concrete fields and covers the failure modes (deleted-but-readable window, purge, not-found), the image-rendering caveat, and the account-selection prerequisite. For a simple 2-parameter read, nothing an agent needs to call it correctly is missing.

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% and both parameter descriptions already state postId comes from create_post/list_posts and accountId comes from list_accounts, so the description is largely restating structured data. Its only added meaning is the multi-account disambiguation rule, which is usage guidance rather than parameter semantics. Baseline 3 applies.

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+resource (read one Pinterest Pin by postId) and enumerates exactly what comes back: status, media, title, description, destination url, board, and scheduled/published time. It also explicitly contrasts itself with list_posts, so an agent can distinguish it from the paging sibling 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?

Gives a concrete trigger (user asks about one Pin and a postId is already known) and names the provenance of that ID (create_post, schedule_post, list_posts). It also states an explicit anti-pattern ('paging list_posts to hunt for it is not' the precise way) and a prerequisite fork: if multiple accounts exist 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