Skip to main content
Glama
voducdan

metabase-mcp

by voducdan

update_card_display

Update a saved Metabase question or card's display type by specifying the card ID and a new display mode (e.g., table, bar, pie). Optionally include visualization settings for precise control.

Instructions

Update the display type of a saved question/card in Metabase.

Args: card_id: The ID of the card to update. display: The display type (e.g. "table", "bar", "line", "pie", "scalar", "row", "area", "combo", "pivot", "smartscalar", "funnel", "waterfall", "map"). visualization_settings: Optional visualization settings to apply with the display change.

Returns: The updated card object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
card_idYes
displayYes
visualization_settingsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Handler function for the 'update_card_display' tool. Updates a card's display type and optionally visualization settings via a PUT request to Metabase's /api/card/{card_id} endpoint.
    @mcp.tool
    async def update_card_display(
        card_id: int,
        display: str,
        ctx: Context,
        visualization_settings: dict[str, Any] | None = None,
    ) -> dict[str, Any]:
        """
        Update the display type of a saved question/card in Metabase.
    
        Args:
            card_id: The ID of the card to update.
            display: The display type (e.g. "table", "bar", "line", "pie", "scalar", "row", "area", "combo", "pivot", "smartscalar", "funnel", "waterfall", "map").
            visualization_settings: Optional visualization settings to apply with the display change.
    
        Returns:
            The updated card object.
        """
        try:
            await ctx.info(f"Updating card {card_id} display to '{display}'")
    
            payload: dict[str, Any] = {"display": display}
    
            if visualization_settings is not None:
                payload["visualization_settings"] = visualization_settings
                await ctx.debug(f"Applying visualization settings: {visualization_settings}")
    
            result = await metabase_client.request("PUT", f"/card/{card_id}", json=payload)
            await ctx.info(f"Successfully updated card {card_id} display to '{display}'")
    
            return result
        except Exception as e:
            error_msg = f"Error updating card {card_id} display: {e}"
            await ctx.error(error_msg)
            raise ToolError(error_msg) from e
  • server.py:843-843 (registration)
    Registration of 'update_card_display' as a FastMCP tool using the @mcp.tool decorator. This registers the tool name and makes it available to MCP clients.
    @mcp.tool
Behavior2/5

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

With no annotations, the description fails to disclose important behavioral traits such as required permissions, side effects, or reversibility. It only states the update and return value, leaving the agent uninformed about potential impacts.

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

Conciseness5/5

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

The description is a well-structured docstring with Args and Returns sections. It is concise, with every sentence adding value and no extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose and parameters adequately. It lacks error handling or prerequisite information, but given the simple nature of the tool and presence of an output schema, it is mostly complete.

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

Parameters4/5

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

Given 0% schema coverage, the description compensates well by explaining card_id as the card ID, display with a list of examples, and visualization_settings as optional settings. It adds meaning beyond the bare schema, though the format of visualization_settings remains vague.

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 that it updates the display type of a saved question/card, which is a specific verb+resource. It lists example display types, distinguishing it from sibling tools like update_card that handle broader modifications.

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

Usage Guidelines3/5

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

The description implies when to use (changing display type) but does not explicitly differentiate from update_card or mention when not to use. The presence of a sibling tool with overlapping purpose would benefit from clearer usage cues.

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/voducdan/matebase-mcp'

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