Skip to main content
Glama
CW-Codewalnut

Metabase MCP Server

update_metabase_dashboard

Modify an existing Metabase dashboard by updating its name, layout, filters, or settings while preserving unchanged elements automatically.

Instructions

Update an existing dashboard in Metabase using structured inputs and auto-fallback behavior.

This function allows partial updates to a dashboard. If you don't pass optional fields like dashcards or tabs, the current values from the existing dashboard will be fetched and reused.

Args: dashboard_id (int): The ID of the dashboard to update.

name (str, optional):
    New name for the dashboard. If not provided, the current name will be retained.

description (str, optional):
    Updated description for the dashboard.

collection_id (int, optional):
    ID of the collection (folder) to move the dashboard into.
    If not provided, the existing collection is kept. However,
    if a new collection has been created,
    it is mandatory to pass the collection ID.
    Failure to do so will result in the dashboard being moved to the default collection,
    where the chart details may not exist.

parameters (List[dict], optional):
    List of dashboard-level filters (used for interactive filtering).
    If omitted, existing parameters will be preserved.

tabs (List[DashboardTab], optional):
    List of tabs to set on the dashboard.
    If not passed, the current tab configuration is reused.
    Each tab includes:
        - `id`: Tab ID (optional if new)
        - `name`: Display name of the tab

dashcards (List[DashboardCard], optional):
    List of cards to place in the dashboard layout.
    If omitted, the existing card layout is retained.
    Each card requires:
        - `id`: Use negative numbers to auto generate the ids 
            or use any unique value but,
            it must be unique within the dashboard
        - `card_id`: ID of the saved chart
        - `row`, `col`: Grid position (top-left = 0,0)
        - `size_x`, `size_y`: Width/height in grid cells
        - `parameter_mappings`: List of filter mappings

points_of_interest (str, optional):
    Free-text notes that appear in the dashboard as "Points of Interest".

caveats (str, optional):
    Free-text notes that appear in the dashboard as "Caveats".

enable_embedding (bool, optional):
    Whether to enable embedding for this dashboard.
    If omitted, the existing setting is reused.

embedding_params (EmbeddingParams, optional):
    Optional embedding configuration. Includes:
        - `url`: Optional embed URL override
        - `custom_css`: Optional custom styling

archived (bool, optional):
    Whether to archive the dashboard. Defaults to existing value if omitted.

position (int, optional):
    Optional global ordering value (affects dashboard listing).

collection_position (int, optional):
    Sort order inside its collection folder.

cache_ttl (int, optional):
    Result caching time in seconds (e.g., 3600 = 1 hour). 0 disables caching.

width (str, optional):
    Dashboard layout mode: "fixed" (grid) or "full" (fluid width).
    Defaults to existing setting if omitted.

show_in_getting_started (bool, optional):
    Whether to show this dashboard in Metabase’s “Getting Started” view.

Returns: Dict[str, Any]: JSON object containing updated dashboard metadata from Metabase. Includes fields like: - id, name, description - dashcards, tabs, parameters - updated_at, created_at, etc.

Behavior: - If dashcards is omitted, the existing layout will be preserved. - If dashcards are passed without an id, id = -1 will be set automatically. - If tabs are omitted, current dashboard tabs are reused. - All unspecified fields fall back to the dashboard's current value.

Example: >>> await update_metabase_dashboard( dashboard_id=1, name="Updated Flight Dashboard", dashcards=[ DashboardCard(card_id=123, row=0, col=0, size_x=4, size_y=3), DashboardCard(card_id=124, row=0, col=4, size_x=4, size_y=3) ], tabs=[DashboardTab(name="Overview")], width="fixed" )

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dashboard_idYes
nameNo
descriptionNo
collection_idNo
parametersNo
tabsNo
dashcardsNo
points_of_interestNo
caveatsNo
enable_embeddingNo
embedding_paramsNo
archivedNo
positionNo
collection_positionNo
cache_ttlNo
widthNo
show_in_getting_startedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing key behaviors: partial update capability, auto-fallback to existing values when fields are omitted, specific handling of dashcards without IDs (auto-assigns -1), and collection_id edge cases. It also includes a comprehensive 'Behavior' section detailing how unspecified fields are handled.

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

Conciseness3/5

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

The description is well-structured with clear sections (Args, Returns, Behavior, Example) but is quite lengthy due to the high parameter count. While most content is valuable, some redundancy exists (e.g., 'If omitted, existing values will be preserved' is repeated for multiple parameters). It could be more front-loaded with the most critical information.

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?

For a complex mutation tool with 17 parameters, 0% schema description coverage, and no annotations, the description is remarkably complete. It covers purpose, usage, detailed parameter semantics, behavioral patterns, return values (though an output schema exists), and includes a practical example. The only minor gap is lack of authentication/authorization requirements.

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?

Given 0% schema description coverage, the description fully compensates by providing detailed semantic information for all 17 parameters. Each parameter includes: purpose explanation, optionality handling, default behaviors, and for complex parameters like dashcards and tabs, it details sub-fields and constraints (e.g., 'id must be unique within the dashboard'). This goes far beyond what the bare schema provides.

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 clearly states the tool's purpose: 'Update an existing dashboard in Metabase using structured inputs and auto-fallback behavior.' It specifies the verb ('update'), resource ('dashboard in Metabase'), and distinguishes it from siblings like 'create_metabase_dashboard' by focusing on modifying existing resources rather than creating new ones.

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?

The description provides clear context for when to use this tool: for updating existing dashboards with partial updates. It mentions the auto-fallback behavior for unspecified fields. However, it doesn't explicitly state when NOT to use it (e.g., vs. create_metabase_dashboard for new dashboards) or mention prerequisites like authentication requirements.

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/CW-Codewalnut/metabase-mcp-server'

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