dashboards

Original：🇺🇸 English

Translated

Read, build, and fix RevOS dashboards of metric cards through the RevOS MCP server. A card is one metric (a numeric measure), counted over a segment's rows or the card's own conditions, optionally broken down by a dimension. Use this whenever the user wants to see what's on a dashboard ("what's on our sales dashboard", "what does the pipeline card show"), put a metric or KPI on one ("add open pipeline to the board", "add revenue by stage as a donut"), change, reorder, move, or remove a card, create, rename, or delete a dashboard, or asks why a card shows "unavailable" or a number that looks wrong — even if they never say "dashboard" or "card". Read it before the first api_write or api_delete on `dashboards` or `dashboard-cards`.

6installs

Sourcerevosai/skills

Added on2026-10-16

NPX Install

npx skill4agent add revosai/skills dashboards

SKILL.md Content

View Translation Comparison →

Dashboards

Dashboards are shared by the whole organization — there is no private one, so anything you add or change, everyone sees. Each holds ordered cards:

Field	What it is
`measure`	One numeric measure, fully qualified: `crm_deals.amount` .
`segmentId`	A segment whose rows the card counts, or —
`filter`	the card's own conditions (segment filter syntax). Never both.
`joinPaths`	The way to each other cube a condition or the breakdown reads: `{ "crm_companies": "crm_deals.crm_companies" }` .
`breakdown`	Optional dimension: the card shows its top groups instead of one number.
`visualization`	How a breakdown shows: `bars` (default), `columns` , `donut` , `table` .
`title`	Shown instead of the measure's name.
`position`	Order on the dashboard, ascending.

A card stores the question, never the answer. How to pick a metric, scope it, and compute its value is the metrics skill — read it before adding a card or reporting what one shows.

Calling the tools

json

// Dashboards
api_read   { "resource": "dashboards", "params": { "fields": "id,name,description" } }
api_write  { "resource": "dashboards", "data": { "name": "Sales", "description": "…" } }
api_write  { "resource": "dashboards", "id": "<dashboard id>", "data": { "name": "…" } }
api_delete { "resource": "dashboards", "id": "<dashboard id>" }

// Cards — flat, not under the dashboard: list ONE dashboard's with a filter
api_read   { "resource": "dashboard-cards", "params": { "filter": "dashboardId == \"<dashboard id>\"", "pageSize": 200 } }
api_read   { "resource": "dashboard-cards", "id": "<card id>" }
api_write  { "resource": "dashboard-cards", "data": { "dashboardId": "…", "measure": "…" } }
api_write  { "resource": "dashboard-cards", "id": "<card id>", "data": { "title": "…" } }
api_delete { "resource": "dashboard-cards", "id": "<card id>" }

The record always goes under

data

. Dashboards list oldest first — the first is the one people land on; cards come back by

position

.

api_details({ resource: "dashboard-cards", operation: "create" })

is the authority on the body. Reading needs Viewer; any write needs Member — a

means the user's role can't change dashboards.

Reading a dashboard

Find it by name (

filter: "name == \"Sales\""

), list its cards, and for each card the user cares about compute its value as the metrics skill describes — scope from

segmentId

or

filter

, join hints from the segment's paths and then the card's

joinPaths

, breakdown from

breakdown

. Report each card by its

title

(or the measure's title), its value, and what it's counted over.

Adding a card

List the dashboard's cards. If the same measure with the same scope is already there, point to it instead of adding a twin.
Pick the metric and scope with the metrics skill: a numeric measure; a segment rooted at the measure's cube, or conditions, or nothing; a join path per other cube read; no condition on a measure or on a cube the rows have many of.
Write it.
```
dashboardId
```
and
```
measure
```
are required; add
```
segmentId
```
or
```
filter
```
,
```
joinPaths
```
,
```
breakdown
```
,
```
visualization
```
,
```
title
```
as needed. Omit
```
position
```
to append.
The server checks that the dashboard and segment exist, that the measure is a numeric measure, the breakdown a dimension, every condition names a
```
member
```
that exists, and that segment and filter aren't both set — a
```
400
```
lists every problem at once; fix them all, don't resend unchanged. It does not check the segment's root, measure conditions, fan-out, or
```
joinPaths
```
: those save fine and the app shows the card as unavailable.
Read it back and compute its value, so the user sees what the card shows — and a broken card is caught now, not by them.

Changing a card

Send only the fields that change.

null

clears

title

,

segmentId

,

breakdown

,

visualization

;

filter

and

joinPaths

are replaced whole, so start from a fresh read.

Filter → segment:

{ "segmentId": "…", "filter": {} }

. Segment → filter:

{ "segmentId": null, "filter": { … } }

.

Dropping a condition or the breakdown on another cube: drop its
```
joinPaths
```
entry too, unless something else on the card still reads that cube.
Reorder: a
```
position
```
between the new neighbours' (
```
1.5
```
between
```
1
```
and
```
2
```
).
Move: set
```
dashboardId
```
; without
```
position
```
it goes last.

The server checks only what the update names: retitling doesn't re-validate the rest.

Why a card is unavailable or looks wrong

The model and segments change under cards — nothing repairs them, and a segment or cube can be deleted without touching the cards that use it. Read the card (and its segment), then check in the app's order:

Metric gone —
```
measure
```
not in
```
meta
```
.
Segment gone —
```
segmentId
```
doesn't resolve.
Field gone — a condition's member (the card's or a dynamic segment's), the breakdown, or a static segment's
```
segment_…
```
cube isn't in
```
meta
```
.
Condition on a measure — in the card's or a dynamic segment's filter.
Join gone — a hop in
```
joinPaths
```
or the segment's paths the model no longer declares.
Condition on a fan-out — a condition on a cube the rows have many of.

Fix it with an update (repoint to the renamed member, drop the condition, switch scope), or say what has to change in the model. A number that's flagged by nothing but looks wrong: the other join route, a static segment not re-snapshotted, a string value spelled differently from the stored one, a fanned-out breakdown, or stale data (

metadata.lastRefreshTime

).

Creating, renaming, deleting dashboards

Create:
```
name
```
(1–255 chars), optional
```
description
```
. Check for a namesake first and ask if one exists. Everyone sees it — don't create one just to try something.
Rename:
```
name
```
/
```
description
```
only.
Delete a card: name it back (title or measure, scope, dashboard) and get a yes.
Delete a dashboard: it removes every card on it. List them, tell the user how many and which, and that the whole organization loses them, then ask for an explicit yes for this dashboard.

No undo for any delete. A card or dashboard you created yourself in a failed attempt is no exception — say so and ask before deleting it.