Data Studio dashboards

The Data Studio feature lets Claude build charts and dashboards in RUCKUS One’s Data Studio — the Apache Superset console over Druid — without you touching the UI. A published dashboard is a first-class deliverable: you ask for it in conversation, and a human opens it in Data Studio afterwards.

This is an Early Access feature: unlock Early Access, then enable it under Features in the dashboard.

No extra credential is involved. The tools drive Data Studio with the same RUCKUS bearer token R1-MCP already mints from your connection.

The build order that works

Doing these out of order is the main way a dashboard comes out empty or broken:

Discover the dataset — ds_list_datasets, then ds_dataset_fields. Dataset ids are per-tenant integers and must always be discovered, never assumed.
Validate the query — ds_query runs a Superset query without saving anything, so you can see real venue data and refine metrics, filters, and scope before committing.
Create the dashboard shell — ds_build_dashboard.
Create each chart attached to it — ds_build_chart with dashboards: [<dashboard id>].
Lay it out and publish — ds_update_dashboard with positionJson, and published: true.
Check it renders — ds_diagnose_charts.

New dashboards are drafts

A newly created dashboard defaults to draft, and a draft is visible only to its owner — which is the API client, not you. If you look in Data Studio and the dashboard isn’t there, this is almost always why.

Pass published: true — on ds_build_dashboard at creation, or on ds_update_dashboard afterwards — to make it visible to everyone in the tenant.

Charts and dashboards created this way are API-managed: the API client owns them, and they show as “Modified by Application …” in the UI. You can still add them to your own dashboards there. Only API-owned dashboards can be updated through these tools; anything else returns 403 or 404, passed through for you to inspect.

The 16 tools

Group	Tools
Discovery	`ds_list_datasets`, `ds_dataset_fields`
Ad-hoc query	`ds_query`
Authoring	`ds_build_chart`, `ds_build_dashboard`
Diagnosis	`ds_diagnose_charts`
Learned notes	`ds_save_note`, `ds_list_notes`
Chart lifecycle	`ds_list_charts`, `ds_get_chart`, `ds_update_chart`, `ds_delete_chart`
Dashboard lifecycle	`ds_list_dashboards`, `ds_get_dashboard`, `ds_update_dashboard`, `ds_delete_dashboard`

ds_dataset_fields returns each column and named metric with its format — the d3-format or unit string such as BPS, BYTES, or ,.2%. That’s what resolves axis units and the fraction-versus-percent question, so it’s worth asking for when a chart’s numbers look wrong by a factor of 100.

When a chart saves but won’t render

A chart can save successfully, and its bare query can pass ds_query, and it still throws “Unexpected Error” in the Data Studio UI. That happens when a render-time field is invalid — the classic case being an annotation_layers entry missing the required showMarkers, which is only validated once the render injects the layers into the query.

ds_diagnose_charts reproduces the real render: it replays each chart’s query context with its annotation layers injected, and reports Superset’s own error verbatim plus a recognition hint for known classes. It is read-only.

Point it at a specific dashboardId after building a dashboard — that checks exactly that dashboard’s member charts, with no tenant-wide noise.

Failed ds_query calls surface the same way: the response carries a top-level queryErrors array holding Superset’s own error text, which usually names the offending column or metric.

Notes that survive the conversation

ds_save_note records a quirk you or Claude worked out — a viz type that needs a particular field, a post-processing shape Superset insists on — under a free-form topic. Notes are private to your account and resurface automatically on ds_list_notes and on the data-studio reference doc, so a hard-won discovery isn’t re-learned next session.