Skip to main content
Glama

superset_dashboard_update

Update an existing Apache Superset dashboard by changing its title, slug, publication status, metadata, CSS, layout, owners, or roles. Role changes automatically sync data source access.

Instructions

Update an existing dashboard. Pass only the fields to change.

IMPORTANT: after the update, datasource_access is automatically synced — each role from dashboard.roles will get access to all dashboard datasets.

Args: dashboard_id: ID of the dashboard to update. dashboard_title: New title. slug: New URL slug (must be unique). published: Change publication status (true — published, false — draft). json_metadata: Dashboard JSON metadata (string or object, fully replaced). css: New custom CSS for the dashboard. Injected as a tag on the dashboard page. Does NOT affect Explore view (chart editor) — only the dashboard.

    Common CSS fixes:

      1) KPI big_number_total — digit size and scroll:
      KPI container has a fixed height (~60px at 2 cells).
      Default font is small. To enlarge via CSS:
        div[class*="big_number"] .header-line {
          font-size: 3.3rem !important;  /* digits */
          font-weight: 700 !important;
          line-height: 1.1 !important;
          margin-bottom: 0 !important;  /* REQUIRED! otherwise scroll */
        }
        div[class*="big_number"] .subheader-line {
          font-size: 1rem !important;  /* label */
          font-weight: 400 !important;
          opacity: 0.7;
        }
      IMPORTANT: margin-bottom on .header-line defaults to 8px — together with
      line-height causes overflow and scroll. Verification formula:
      font_size_px * 1.1 + margin_bottom <= 60px.
      3.3rem = 52.8px -> 52.8 * 1.1 = 58px + 0 = 58px < 60px OK

      2) Country Map tooltip clipped by container — culprit is
      DIV.dashboard-chart (styled-component with overflow:hidden).
      Tooltip = DIV.hover-popup (NOT .datamaps-hoverover!). Fix:
        .dashboard-chart-id-{N} .dashboard-chart {
          overflow: visible !important;
        }
        .hover-popup { z-index: 99999 !important; }

      To analyze CSS issues: open the dashboard in Playwright,
      find the chart element, walk up parentElement,
      check getComputedStyle(el).overflow at each level.

position_json: Widget positioning on the dashboard (string or object).
    Defines the layout of charts, headers, dividers in the grid.
    IMPORTANT: fully replaced — first get current layout via
    dashboard_get, modify needed elements and pass the entire JSON.
owners: List of owner user IDs (REPLACES all current owners).
roles: List of role IDs for dashboard access (REPLACES current ones).
    On change, datasource_access is automatically synced.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cssNo
slugNo
rolesNo
ownersNo
publishedNo
dashboard_idYes
json_metadataNo
position_jsonNo
dashboard_titleNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description fully discloses important behaviors: roles/owners are replaced, position_json and json_metadata are fully replaced, datasource_access is auto-synced, CSS is injected as a <style> tag and does not affect Explore view. It even includes detailed side-effect reasoning (overflow formula) and debugging tips, leaving little hidden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but given 9 parameters and complex side effects, it is well-structured with clear per-parameter sections. The extensive CSS examples could be trimmed without severe loss, but they add concrete value for the agent. The main purpose is front-loaded, and later content is logically organized.

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?

Complexity is high with 9 params, no annotations, and 0% schema coverage. The description fully covers each parameter, side effects, and usage caveats. Although return values aren't described, an output schema exists, so that's not required. The description is complete enough for an agent to invoke the tool correctly and anticipate all important behaviors.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description compensates admirably. Every parameter (dashboard_id, dashboard_title, slug, published, json_metadata, css, position_json, owners, roles) is explained with meaning, constraints (slug must be unique), and behavioral consequences (replacement semantics, sync behavior). It even provides example CSS fixes for the css parameter.

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 'Update an existing dashboard. Pass only the fields to change', clearly identifying the verb (update), resource (dashboard), and scope (existing). It distinguishes itself from siblings like superset_dashboard_create, superset_dashboard_delete, and superset_dashboard_publish by focusing on modifying existing dashboards.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when to use the tool (updating any dashboard attribute) and provides practical guidance: 'Pass only the fields to change', tells users to call dashboard_get before changing position_json, and explains the automatic datasource_access sync when roles change. However, it doesn't explicitly name alternative tools like superset_dashboard_publish for published field changes, but the field-level explanations are sufficient.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bintocher/mcp-superset'

If you have feedback or need assistance with the MCP directory API, please join our Discord server