Loading ToolBench
A Model Context Protocol server for Metabase that enables querying dashboards, cards, databases, and executing SQL queries against Metabase instances
Server has 6 tools with basic naming and descriptions, but significant gaps in schema completeness, parameter documentation, and error handling. All tools are READ_ONLY and return JSON strings rather than structured objects. Descriptions are present but generic (avg ~50 chars, below 194-char baseline). No parameter descriptions visible in schemas, execute_card and execute_query accept complex inputs (Dict, List) with minimal guidance. Output schemas are undocumented; tools return raw JSON.dumps() output. No error recovery guidance, no input validation hints, no pagination support despite list_* tools. Composition is reasonable (single responsibility per tool), but parameter naming lacks type suffixes (e.g., 'parameters' vs 'parameters_dict'). Security: credentials injected via env vars (good), but no rate limiting, audit logging, or permission gates.
Execute a Metabase question/card and get results
Execute a SQL query against a Metabase database
Get all cards in a dashboard
List all questions/cards in Metabase
List all dashboards in Metabase
List all databases in Metabase
Parameter descriptions missing from schemas. execute_card accepts 'parameters' (Dict) and execute_query accepts 'native_parameters' (List[Dict]) with no guidance on structure, format, or valid keys. LLMs cannot infer what to pass.
Output schemas undocumented. All tools return raw JSON strings via json.dumps(). LLMs cannot parse expected fields, chain results to downstream tools, or extract relevant data. No structured output schema defined.
No pagination support. list_* tools return all results without limit, offset, or cursor. Large Metabase instances will blow context windows. No total_count or next_cursor in responses.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Error handling returns generic exception messages ('Failed to execute card') with no recovery guidance. LLMs cannot determine if error is retryable, user-fixable, or fatal. No actionable error classification.
Parameter naming lacks type suffixes. 'parameters' and 'native_parameters' are ambiguous, should be 'card_parameters_dict' or 'query_parameters_array' to signal expected structure. Increases LLM confusion.