pinbridge

Get dashboard summary

get_dashboard_summary

Read-onlyIdempotent

Summarize publishing activity over a period: how many pins went out and how it went.

    Use to answer "how did publishing go this week / today / last month":
    pin outcomes, success rate, the change against the previous period,
    and what is still queued or scheduled. Ranges up to 48 hours come back
    hourly, longer ones daily, up to 366 days. For Pinterest engagement
    (impressions, saves, clicks) use get_account_analytics; to see the
    individual failed pins use list_pins with status=failed.

    Returns start, end, timezone, granularity (hour | day), pins (total,
    submitted, by_status, success_rate from 0 to 1), previous_pins (same
    figures for the preceding period of equal length), series (created / published /
    failed per bucket), published_by_account, queue (queued, deferred,
    publishing right now), schedules (by_status in the range, upcoming) and
    import_jobs (null when filtered by account). Outcomes count by when
    they happened: published by publish time, failed by failure time (for
    pins still failed); pins.total is the sum of by_status, and
    pins.submitted and series.created count pins submitted in the range
    (API 1.38+; older APIs report submissions in pins.total and omit
    pins.submitted). Fails with invalid_date_range (start not before end, or
    more than 366 days), invalid_timezone, or account_not_permitted for an
    account outside the key's allow-list.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`tz`	No	IANA time zone for the day/hour buckets, e.g. "Europe/Paris". Default "UTC".	UTC
`end`	No	Range end, exclusive, ISO 8601. Default: now.
`start`	No	Range start, inclusive, ISO 8601. Without an offset it is read in tz, e.g. "2026-09-01" is local midnight. Default: 30 days before end.
`account_id`	No	UUID of a connected Pinterest account, from list_pinterest_accounts.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral detail beyond that: hourly vs. daily granularity by range length, the 366-day limit, full return-field semantics, how outcomes are counted, API version differences, and specific error names. This goes far beyond what the annotations provide.

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 a one-sentence purpose, then alternatives, then behavior and return details in a logical order. Despite its length, every sentence carries meaningful information and there is no filler or repetition of schema text.

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?

There is no output schema, so the description correctly compensates by enumerating the full return shape, including nested fields like series, queue, schedules, and import_jobs. It also covers error conditions and edge cases such as old API versions, making it complete enough for an agent to invoke the tool confidently.

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 description coverage is 100%, so the schema already documents tz, start, end, and account_id well. The description adds complementary semantics about range length affecting granularity, the meaning of start/end inclusivity, and the invalid_date_range failure condition, which improves parameter understanding beyond the schema alone.

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?

The description opens with a specific verb and resource: 'Summarize publishing activity over a period: how many pins went out and how it went.' It clearly distinguishes this tool from siblings by naming get_account_analytics for engagement metrics and list_pins for failed-pin details, so an agent can identify the right tool immediately.

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?

The description explicitly states when to use the tool ('how did publishing go this week / today / last month') and gives concrete alternatives with conditions: use get_account_analytics for Pinterest engagement and list_pins with status=failed for individual failed pins. This is exactly the kind of when-to-use-versus-siblings guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All pinbridge 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?