Loading ToolBench
A high-performance MCP server for Metabase analytics integration with response optimization and robust error handling
The Metabase MCP server demonstrates strong parameter validation and schema definition across 6 tools. All tools have explicit JSON Schema input definitions with properly typed and described parameters. Naming follows verb_noun convention (search, retrieve, list, execute, export, clear_cache). However, several tools have descriptions that are moderately long but lack concrete guidance on error recovery and multi-step workflows. Output schemas are documented indirectly but not formally included in the visible tool definitions. Tool descriptions average ~180 chars, which is within the 10-1024 range but could be more concise. Parameter descriptions are comprehensive and include constraints (enums, min/max values), which is excellent. Error handling guidance is minimal, most tools lack explicit recovery instructions for common failure modes. The 'search' tool's restrictive parameter combinations (database model cannot mix with others, certain parameters only work with specific model combinations) are well-documented but introduce operational complexity.
Clear the internal cache of Metabase metadata. Use this when you know Metabase content has been updated and you need fresh data. Clears all cached responses including cards, dashboards, tables, databases, and collections.
Execute SQL queries or Metabase cards to get query results with row limit control. Supports two execution modes: (1) Execute a saved card by card_id with optional card_parameters, (2) Execute raw SQL with database_id and native_parameters. Results are returned with metadata and row count.
Export query results or card data to file formats (CSV, JSON, XLSX). Supports two export modes: (1) Export a saved card by card_id with optional card_parameters, (2) Export raw SQL query results with database_id. Files are saved to the export directory and returned with file path and metadata.
List all items of a specific model type with pagination support. Returns compact, optimized summaries of cards, dashboards, tables, databases, or collections. Use offset and limit for pagination when dealing with large datasets that exceed token limits.
Fetch additional details for supported models (Cards, Dashboards, Tables, Databases, Collections, Fields). Supports multiple IDs (max 50 per request) with intelligent concurrent processing and optimized caching. Includes table pagination for large databases exceeding token limits.
Missing output schema documentation in tool definitions. While input schemas are comprehensive, the response structures are not formally documented in the tool registration. LLMs cannot plan downstream operations without knowing what fields to expect (e.g., which fields the 'search' result contains, what pagination metadata 'list' returns).
Error handling lacks recovery guidance. Tool descriptions do not provide actionable next steps when operations fail. For example, 'execute' tool does not explain what the LLM should do if a SQL query times out, returns no results, or fails with a constraint violation. Descriptions should include patterns like 'If query times out, try reducing row_limit or simplifying the WHERE clause.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Search across all Metabase items using native search API. Supports cards, dashboards, tables, collections, databases, and more. Use this first for finding any Metabase content. Returns search metrics, recommendations, and clean results organized by model type.
Parameter interdependencies are documented but create cognitive load. The 'search' tool has 8 parameters with multiple RESTRICTION notes (e.g., database model cannot mix with others, search_native_query only works with card model, ids cannot be used with table/database). While these are explicitly stated, they could be simplified by splitting into separate specialized tools (search_cards, search_databases, search_by_ids) following the single-responsibility principle.
Tool descriptions do not explain when to prefer one tool over another. For example, 'search' vs 'list' vs 'retrieve' all operate on the same models but in different modes. The description for 'search' does not say 'Use this for finding content by keyword; if you need all items, use list() instead.' This forces the LLM to reason about selection rather than having explicit guidance.
The 'execute' and 'export' tools accept mutually exclusive parameters (card_id vs database_id + query) but lack explicit validation errors guiding the user. If an LLM passes both, or neither, the error message should be clear: 'Must provide either card_id OR (database_id + query), not both or neither.'
Export tool filename parameter is optional and accepts custom names, but no validation documented. If a filename contains path traversal (../, /etc/passwd) or illegal characters, the behavior is undefined. Description should state: 'Filename must be 1-255 alphanumeric characters, hyphens, underscores, and dots. Illegal characters and path traversal attempts will be rejected.'