Region: If more than one squaredup-* server is connected, ask the user which one they mean before running any tools, then use that same server for every SquaredUp tool call in the task.
Reading SquaredUp dashboards
Dashboards are the most discoverable artifact in a tenant. If a user asks about something monitoring-related, there's often already a dashboard for it - and reading it gives you the data stream IDs, scopes, and KPIs you need to answer follow-ups directly, without guessing.
Tool map
| Tool |
What it does |
dashboard_list |
List all dashboards in the tenant with workspace names |
dashboard_get |
Full dashboard including layout and tile content |
dashboard_create |
Create a new dashboard |
dashboard_clone |
Copy a dashboard into a workspace, cloning + remapping its variables/scopes |
dashboard_update |
Full overwrite of an existing dashboard |
dashboard_query |
Fetch once, run all data-stream tiles in parallel, return every tile's rows |
tile_list |
Flat tile inventory (id, title, description, type) |
tile_get |
Full config for a single tile |
tile_create |
Add a new tile; auto-places below existing tiles, generates its id |
tile_update |
Merge config fields onto an existing tile |
tile_query |
Run a single tile's data stream and return its rows |
Drill-down order
workspace_list - pick the workspace by name match against the user's question (e.g. "production" → the "Production" workspace).dashboard_list - the response includes workspaceDisplayName for fast filtering. Match by displayName.dashboard_get - full dashboard, including layout and tile content. Use this when you need everything.tile_list - flat list of tiles on a dashboard with id, title, description, and _type. Cheaper than dashboard_get if you only need the inventory.tile_get - full tile config: data stream, scope, timeframe, monitor rules, KPI, viz config.
What a tile gives you
A tile's config typically contains:
dataStream.id and dataStream.name - feed straight into data_stream_query (together with the dashboard's workspaceId, which data_stream_query requires) or use tile_query to skip the assembly.scope - feed into scope_resolve to materialize the current matching entities.pluginConfigId / activePluginConfigIds - which data source(s) the tile queries.timeframe - the tile's default time window.- Monitor / KPI / viz config - shape varies with the tile's
_type. For KPI tiles, the config references a top-level KPI by ID; see the kpis skill to inspect the underlying KPI.
Pattern: "what is this dashboard telling me right now?"
Use dashboard_query - one call fetches the dashboard and fans out all data-stream tile queries in parallel. Non-data-stream tiles (text, image) are skipped automatically. Each tile comes back with its title and rows (or an error if that tile failed).
Only drop down to tile_list + parallel tile_query if you need to filter to specific tiles first (e.g. only tiles matching a keyword in the title).
Don't fan out 20 parallel data_stream_query calls without thinking - dashboard_query already does this safely. Use it.
Pattern: "show me the data for this tile / KPI"
tile_query(dashboardId, tileId) - reads the tile's config and fires the stream in one step. Optionally pass timeframe to override the tile's stored window. The dashboardId and tileId are returned by tile_list and kpi_list.
Pattern: "duplicate / build me a dashboard like X"
- Faithful copy (same or different workspace):
dashboard_clone({ dashboardId, sourceWorkspaceId, targetWorkspaceId }). It clones the dashboard's variables and scopes into the target workspace and remaps tile references, so the copy is self-contained. Prefer this over dashboard_get + dashboard_create, which only copies content and leaves tiles pointing at the source workspace's variables/scopes.
- Copy then tweak ("like X but for Y"):
dashboard_clone first, then dashboard_get the clone, adjust, and dashboard_update - so the tweaks sit on top of the already-remapped variables/scopes.
- For small additions, adjust individual tiles with
tile_create / tile_update rather than hand-crafting the full content blob.
Pattern: "add a tile to dashboard X"
tile_get on a similar existing tile to understand the config shape.tile_create(dashboardId, config, w?, h?) - auto-places the tile below the existing layout. Returns tileId.
Pattern: "edit dashboard X"
- Tile-level changes (config, title, data stream, scope):
tile_update(dashboardId, tileId, config) - merges onto the existing config, no full-read required.
- Dashboard-level changes (displayName, layout, timeframe):
dashboard_get first (it's a full overwrite), then dashboard_update with { dashboardId, body }.
When to skip this skill
- The user explicitly wants ad-hoc graph traversal - go to
graph_query.
- The user is building from scratch and existing dashboards don't match the intent -
data_source_list + graph_query are the right starting points.
- The user already gave you a tile or stream ID - call the tool directly.
- The user wants to share a dashboard via a public link →
sharing.
- The user wants to control who can view or edit a dashboard →
permissions.
1---2name: dashboards3description: Use when you need to understand what an existing SquaredUp dashboard contains - its tiles, what data each tile pulls, scope, KPIs. The fastest path from a vague monitoring question to concrete data stream IDs and scopes.4---56> **Region:** If more than one `squaredup-*` server is connected, ask the user which one they mean before running any tools, then use that same server for every SquaredUp tool call in the task.78# Reading SquaredUp dashboards910Dashboards are the most discoverable artifact in a tenant. If a user asks about something monitoring-related, there's often already a dashboard for it - and reading it gives you the data stream IDs, scopes, and KPIs you need to answer follow-ups directly, without guessing.1112## Tool map1314| Tool | What it does |15| ------------------ | --------------------------------------------------------------------------- |16| `dashboard_list` | List all dashboards in the tenant with workspace names |17| `dashboard_get` | Full dashboard including layout and tile content |18| `dashboard_create` | Create a new dashboard |19| `dashboard_clone` | Copy a dashboard into a workspace, cloning + remapping its variables/scopes |20| `dashboard_update` | Full overwrite of an existing dashboard |21| `dashboard_query` | Fetch once, run all data-stream tiles in parallel, return every tile's rows |22| `tile_list` | Flat tile inventory (id, title, description, type) |23| `tile_get` | Full config for a single tile |24| `tile_create` | Add a new tile; auto-places below existing tiles, generates its id |25| `tile_update` | Merge config fields onto an existing tile |26| `tile_query` | Run a single tile's data stream and return its rows |2728## Drill-down order29301. **`workspace_list`** - pick the workspace by name match against the user's question (e.g. "production" → the "Production" workspace).312. **`dashboard_list`** - the response includes `workspaceDisplayName` for fast filtering. Match by `displayName`.323. **`dashboard_get`** - full dashboard, including layout and tile content. Use this when you need everything.334. **`tile_list`** - flat list of tiles on a dashboard with id, title, description, and `_type`. Cheaper than `dashboard_get` if you only need the inventory.345. **`tile_get`** - full tile config: data stream, scope, timeframe, monitor rules, KPI, viz config.3536## What a tile gives you3738A tile's `config` typically contains:3940- `dataStream.id` and `dataStream.name` - feed straight into `data_stream_query` (together with the dashboard's `workspaceId`, which `data_stream_query` requires) or use `tile_query` to skip the assembly.41- `scope` - feed into `scope_resolve` to materialize the current matching entities.42- `pluginConfigId` / `activePluginConfigIds` - which data source(s) the tile queries.43- `timeframe` - the tile's default time window.44- Monitor / KPI / viz config - shape varies with the tile's `_type`. For KPI tiles, the config references a top-level KPI by ID; see the `kpis` skill to inspect the underlying KPI.4546## Pattern: "what is this dashboard telling me right now?"4748Use **`dashboard_query`** - one call fetches the dashboard and fans out all data-stream tile queries in parallel. Non-data-stream tiles (text, image) are skipped automatically. Each tile comes back with its title and rows (or an error if that tile failed).4950Only drop down to `tile_list` + parallel `tile_query` if you need to filter to specific tiles first (e.g. only tiles matching a keyword in the title).5152Don't fan out 20 parallel `data_stream_query` calls without thinking - `dashboard_query` already does this safely. Use it.5354## Pattern: "show me the data for this tile / KPI"5556`tile_query(dashboardId, tileId)` - reads the tile's config and fires the stream in one step. Optionally pass `timeframe` to override the tile's stored window. The `dashboardId` and `tileId` are returned by `tile_list` and `kpi_list`.5758## Pattern: "duplicate / build me a dashboard like X"5960- **Faithful copy (same or different workspace):** `dashboard_clone({ dashboardId, sourceWorkspaceId, targetWorkspaceId })`. It clones the dashboard's variables and scopes into the target workspace and remaps tile references, so the copy is self-contained. Prefer this over `dashboard_get` + `dashboard_create`, which only copies `content` and leaves tiles pointing at the source workspace's variables/scopes.61- **Copy then tweak ("like X but for Y"):** `dashboard_clone` first, then `dashboard_get` the clone, adjust, and `dashboard_update` - so the tweaks sit on top of the already-remapped variables/scopes.62- For small additions, adjust individual tiles with `tile_create` / `tile_update` rather than hand-crafting the full content blob.6364## Pattern: "add a tile to dashboard X"65661. `tile_get` on a similar existing tile to understand the config shape.672. `tile_create(dashboardId, config, w?, h?)` - auto-places the tile below the existing layout. Returns `tileId`.6869## Pattern: "edit dashboard X"7071- **Tile-level changes** (config, title, data stream, scope): `tile_update(dashboardId, tileId, config)` - merges onto the existing config, no full-read required.72- **Dashboard-level changes** (displayName, layout, timeframe): `dashboard_get` first (it's a full overwrite), then `dashboard_update` with `{ dashboardId, body }`.7374## When to skip this skill7576- The user explicitly wants ad-hoc graph traversal - go to `graph_query`.77- The user is building from scratch and existing dashboards don't match the intent - `data_source_list` + `graph_query` are the right starting points.78- The user already gave you a tile or stream ID - call the tool directly.79- The user wants to share a dashboard via a public link → `sharing`.80- The user wants to control who can view or edit a dashboard → `permissions`.
squaredup