Tailwind App

get_pin_analytics

Read-onlyIdempotent

Use this when the user asks how a specific Pin performed: returns that Pin's totals over a window, a per-day series, and lifetime totals that ignore the window. This is the only analytics tool that reports comments (totalComments) and reactions (totalReactions), in lifetimeMetrics; get_account_analytics and list_top_pins do not. Figures are organic-only: Pinterest's per-Pin analytics exclude paid (promoted) distribution, so a promoted Pin reads far lower here than in list_top_pins or get_account_analytics — that gap is expected, not an error.

Only a Pin this account OWNS can be read; anything else returns 404, including a Pin on a group board this account merely collaborates on. Pinterest itself would report on those, but this endpoint does not — do not retry a shared-board Pin, and do not tell the user the id was wrong. A 403 means Pinterest permanently forbids analytics for that Pin — it will never report, so do not retry it. Reading analytics is free and consumes no credits. pinId is the PINTEREST Pin id, NOT the Tailwind postId that list_posts and get_post return as id; a published post carries the Pinterest id in its own pinId field, so pass that. list_pins and list_top_pins return it too. Passing a Tailwind postId returns a 404. Omit startDate and endDate for the last 30 days; supply BOTH to choose a window (supplying one is an error). Dates are UTC YYYY-MM-DD. Pinterest reports at most 90 days back and at most a 90-day span. The range actually used comes back as startDate/endDate — report those, do not assume the period. 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
`pinId`	Yes	The PINTEREST Pin id (a numeric string): the `pinId` field on a published post from list_posts or get_post, or a pinId from list_pins or list_top_pins. NOT the Tailwind postId (the post's `id`).
`endDate`	No	Last day of the window (inclusive), UTC YYYY-MM-DD. Requires startDate.
`accountId`	Yes	Numeric Tailwind account ID returned by list_accounts
`startDate`	No	First day of the window, UTC YYYY-MM-DD. Requires endDate. Omit both for 30 days.

Output Schema

Name	Required	Description
`pinId`	Yes
`boardId`	No	The Pinterest board the Pin is saved to — the same id list_boards returns
`endDate`	Yes
`accountId`	Yes
`startDate`	Yes
`dailyMetrics`	Yes	Per-day metrics across the window, earliest first
`summaryMetrics`	Yes	Pinterest metrics, camelCased. A null value means Pinterest has not finished computing that metric for that day; an absent one means it does not report it for this subject. Per-Pin fields include impression, save, saveRate, pinClick, outboundClick, profileVisit, userFollow, and video metrics on video Pins. Comment and reaction counts are not windowed: read them from lifetimeMetrics.
`lifetimeMetrics`	No	Totals since the Pin was created, ignoring the requested window. The only place Pinterest reports totalComments (the comment count) and totalReactions; absent when Pinterest reports none.

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?

Far exceeds what the annotations cover. Annotations only say read-only, idempotent, open-world; the description adds that figures are organic-only, that a promoted Pin reads low here versus siblings and that gap is expected, that non-owned Pins return 404 (including shared boards) and must not be retried or blamed on a bad id, that 403 is permanent, and that calls consume no credits. These are exactly the traits an agent needs to interpret and recover from responses.

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 core purpose and the differentiator, then ordered by operational importance (data caveats, error semantics, parameter gotchas, account disambiguation). It is dense with no filler, but the postId/404 warning is restated in both the pinId paragraph and the error paragraph, which costs a little.

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?

Complete for a four-parameter read tool with a rich output schema: purpose, window semantics, data-scope caveats, error taxonomy, id-type confusion, and account disambiguation are all addressed. Since an output schema exists, the description is not obliged to enumerate return fields, and it isn't a gap that it doesn't.

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, but the description adds constraints the schema does not carry: at most 90 days back and at most a 90-day span, both dates required together, dates are UTC, and the effective range is echoed back as startDate/endDate and should be reported rather than assumed. The pinId-vs-postId warning largely duplicates the schema text.

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 and resource ('returns that Pin's totals over a window, a per-day series, and lifetime totals') and immediately differentiates itself: 'This is the only analytics tool that reports comments (totalComments) and reactions (totalReactions)... get_account_analytics and list_top_pins do not.' An agent can distinguish this from every analytics 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?

Explicit about when to use it (user asks how a specific Pin performed), which alternatives to use instead (get_account_analytics, list_top_pins), and what to do with a multi-account situation ('ask the user which account to use before calling this — do not choose for them'). It also gives negative guidance on retries and on how to phrase failures to the user.

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?