DashThis

Turn a dashboard into a PDF and get a link to it, so the user can hand their client the report itself rather than a login. Use when: the user wants the dashboard as a file — to email a client, attach it to a recap, or keep it with their notes. Returns: a temporary link to the rendered PDF, plus the dashboard's title and the period it covers. The PDF always covers the dashboard's own reporting period — there is no way to export a different window, so if the user wants another period they need to change it in DashThis first. Rules: the link expires after an hour, so give it to the user right away and tell them it is temporary rather than saving it for later. Rendering takes around ten seconds, and this call waits for it. If it comes back still rendering, there is no link yet and nothing reported a failure — say it is taking longer than usual and offer to try again; calling again starts a fresh render. Then: give them the labelled link from the response rather than the bare address, say which dashboard and period it covers, then offer to draft the recap or client email it goes out with.

export_dashboard_pdf

Pull a dashboard's current values so you can help the user make sense of them and communicate them to their client. Use when: the user wants the actual numbers on a dashboard — to summarize performance, spot what moved, or draft an update for a client or stakeholder. Returns: per widget, its title, kind and read status. A data widget carries its metric columns and current-period rows (dimension values + one raw value per metric), plus the matching comparison-period rows when compareTo is set. A widget whose content can't be read here comes back status=unsupported or status=failed with a reason — the dashboard may still display it, so don't report it as empty. A text widget carries the text written on it as content, as HTML — often the user's own commentary about the numbers, with contentPeriodEndDate saying which period it was written for. Values are read over the dashboard's own period unless you ask for another one, and the response says which window answered — name that window whenever you report the numbers. Rules: values are raw as the widget returns them, so compute deltas and format for the reader yourself, and never state a metric or number the widget didn't return. A total is one of those numbers: report the widget's own currentTotals and never work one out from the rows. Then: turn the numbers into the story the user needs — what changed and why it matters to their client — and offer to draft the update in whatever tool they use.

get_dashboard_data

Read a dashboard's setup — its widgets, data sources, theme, and reporting-period settings — so you can explain how it's built before working on it further. Use when: the user asks what's on a dashboard, how it's set up, which sources feed it, or wants an overview before pulling its numbers. Returns: the dashboard's info (title, type, culture, reporting period/frequency); each widget's title, position and size; the data sources connected to it (with integration and connection status); the integrations used; and the applied theme. Rules: this is the dashboard's setup, not its numbers — it never returns metric values or widget content. Use get_dashboard_data for what each widget tracks and shows. Then: help the user with what they're actually after — walk them through the setup, explain what a widget covers, or move on to get_dashboard_data for the numbers. Communicating what's there is the default, not flagging what to change. Read-only.

get_dashboard_metadata

Lists the dashboards in the user's account so you can find one or scan across clients. Use when: the user wants an overview of their dashboards, asks "what dashboards do I have", or is about to work on a specific dashboard's report. Returns: a page of dashboards — each with id, title, group, View-mode URL, creator, and creation date (data sources only when includeSources is set) — plus the total count and paging info. No client entity exists — infer client grouping from group and names. Filter server-side to keep results small and targeted: titleContains, integration, hasSourceError. Page with offset/limit. Turn on includeSources only when the user cares about a dashboard's data sources — it makes the response much larger. Then: offer the useful next move in the user's own words — open a dashboard's report, prep a client recap, reconnect a source in error, or share a View URL — one step at a time. Read-only.

list_dashboards

Report back to the DashThis team when these tools can't do what the user needs, or when the user shares something about using them that's worth passing on. Use when: the user wants something no tool here does (creating or editing a dashboard, sending a report, alerts — anything beyond reading); a tool kept failing or was refused; the values you got back clearly weren't what they asked about; getting there took a lot of guessing; or the user tells you something is wrong, missing, confusing, not how they work, or better than they expected. Returns: a reference for the report when it was recorded and none when it wasn't, plus the help center and support ticket links to hand the user. Rules: once per problem, not once per turn. A gap you hit yourself you report on your own; anything the user said is theirs — ask before sending it, and set source to match. Logging a report is not a fix and nobody replies to it; the ticket link is what reaches a person. Then: say it's been logged only when this call hands back a reference, and quote that reference — no reference means no report, whatever you meant to do. Where something couldn't be done, also say plainly what, give them the link that fits, and offer the nearest useful thing you can do instead; where nothing was blocked, none of that applies — the call's own response says which.

provide_feedback

Confirms which DashThis account this session is acting on. Returns the account resolved from the access token, its company name, status, and dashboard count.

whoami