Loading ToolBench
MCP server for Metabase - connect Claude to your Metabase instance
metabase-mcp demonstrates solid foundation with consistent naming conventions (verb_noun patterns like list_dashboards, create_dashboard, execute_query) and universally present tool descriptions. However, parameter descriptions are sparse or missing entirely, output schemas are not documented, and error handling lacks recovery guidance. All 18 tools follow the verb-first naming pattern well, but parameter-level documentation is the primary weakness. No tool definitions are inferred; all are explicitly registered in Go code. Schema definitions exist in code but are not explicit JSON Schema structures visible in the tool definitions themselves.
Archive (soft-delete) a saved question (card). The card can be restored from the Metabase trash.
Archive a collection (folder) in Metabase. Archived collections are hidden but can be restored.
Create a new saved question (card) with a native SQL query. You can specify the chart type (display) and card type (question, model, or metric) when creating.
Create a new collection (folder) in Metabase. Can be nested under a parent collection.
Create a new dashboard in Metabase. Optionally place it in a collection.
Permanently delete a dashboard from Metabase.
Parameter descriptions are minimal or entirely absent. Parameters like 'cards' in update_dashboard_cards states 'Array of card layout items with dashcard_id, row, col, size_x, size_y' but does not describe the purpose, valid ranges, or format of each field. The 'query' parameter in execute_query lacks any guidance on query syntax, timeout, or result limits.
Output schemas are not documented. Tools like execute_query and run_question return QueryResult with 'column names and rows', but the actual structure (field names, types, pagination support, row format) is not visible in tool definitions. Without documented output schemas, LLMs cannot reliably extract or chain results.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 12 | - | v1 |
Execute a native SQL query against a Metabase database. Returns column names and rows.
Get a saved question (card) by ID, including its current SQL query and metadata.
Get detailed information about a specific dashboard, including its cards/questions.
List all collections (folders) in this Metabase instance.
List all dashboards in this Metabase instance.
List all databases connected to this Metabase instance.
Move a dashboard to a different collection (folder).
Run a saved Metabase question (card) by its ID and return the results.
Search across questions, dashboards, and collections in Metabase.
Update a saved question (card): change its SQL query, name, description, or type (question, model, metric). Provide only the fields you want to change.
Change the chart/visualization type of a saved question (card). Supported types: table, bar, line, pie, scalar, row, area, combo, pivot, funnel, map, scatter, waterfall, progress, gauge.
Update the layout (position and size) of cards on a dashboard. Use get_dashboard first to see current dashcard IDs and layout.
No error handling guidance. Tools declare risk levels (READ_ONLY, WRITE, DESTRUCTIVE) but provide no recovery instructions. For example, execute_query offers no guidance on query syntax errors, timeout handling, or when to retry. Agents receive errors with no next steps.
Enumeration constraints not declared for constrained parameters. update_card_display accepts a 'display' parameter with 14 valid values (table, bar, line, pie, scalar, row, area, combo, pivot, funnel, map, scatter, waterfall, progress, gauge) but they are listed in the description rather than as an enum in the schema. LLMs may hallucinate invalid display types.
Parameter type dependencies not documented. create_card accepts optional parameters (collection_id, visualization_settings) without indicating which combinations are valid or which are required for specific card types (question vs. model vs. metric). update_card marks 'database_id' as 'Required when updating query' in text but this should be enforced in schema.
Result limits not enforced or documented. list_dashboards, list_collections, and list_databases return all results with no pagination parameters. Large Metabase instances could return hundreds or thousands of items, exhausting the context window. No mention of limits or pagination in tool descriptions.
Destructive operations lack confirmation/dry-run support. delete_dashboard permanently removes a dashboard with no undo or confirmation step. Agents can be tricked into destructive actions via prompt injection. No dry-run mode or confirmation request pattern.
Generic parameter names invite misuse. search accepts a bare 'query' string with no guidance on syntax (regex? phrase? field-specific?). update_dashboard_cards accepts 'cards' array with no type hint or schema for individual card objects.