Loading ToolBench
The Redash MCP server defines 17 tools with basic structure but significant quality gaps. All tools have names following verb_noun convention (get_query, create_query, etc.) and descriptions are present but generic (e.g., 'Get a specific query by ID'). Input schemas are defined using Zod with type information visible in the source code (src/index.ts). However, parameter descriptions are minimal (often just 'ID of X' or 'Name of X'), lacking guidance on format, constraints, or dependencies. Output schemas are not documented, callers don't know the structure of responses. Error handling returns basic error text but lacks recovery guidance (no 'try X next' hints). Several parameters use 'any' type (options, schedule) which bypasses validation. The server uses STDIO transport, which is a hard limitation. Overall, the tools are functional but fall short of production quality, descriptions lack LLM optimization, schemas are incomplete, and error responses don't guide recovery.
Archive a query in Redash
Create a new dashboard in Redash
Create a new query in Redash
Create a new visualization for a query
Create a new widget in a dashboard
Execute a Redash query and return the results
Execute a raw SQL query and return the results
Output schemas not documented. No specification of response structure for any tool. LLMs cannot predict downstream field names or plan chained operations (e.g., after create_dashboard, what field contains the dashboard_id for create_widget?).
Parameter descriptions are generic and lack format/constraint guidance. E.g., 'ID of the query' does not explain if ID is an integer, string, or UUID. 'SQL query text' doesn't specify dialect or size limits. 'Query options (optional)' uses 'any' type with no guidance on valid keys.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | <=2025-11-25 | v2 |
Get a specific dashboard by ID
Get a specific query by ID
Get a specific visualization by ID
List all available dashboards in Redash
List all available data sources in Redash
List all available queries in Redash
Update an existing query in Redash
Update the type of a query parameter
Update an existing visualization
Update an existing widget in a dashboard
Error handling provides no recovery guidance. E.g., 'Error getting query: <message>' tells LLM nothing about whether to retry, try a different tool, or ask the user. No error categorization (retryable vs. fatal).
'any' type parameters bypass validation and confuse LLMs. E.g., 'options', 'schedule', 'enumOptions' are declared as 'any' instead of structured schemas. LLMs cannot introspect valid keys or guess proper structure.
No pagination result size guidance. list_dashboards and list_queries accept page/pageSize but no documentation states default limits, max page size, or total count structure. LLMs may request unreasonable page sizes or exhaust context fetching large result sets.
Destructive operations lack confirmation/dry-run pattern. archive_query and delete operations (inferred) have no pre-execution confirmation step, increasing risk of accidental data loss.
STDIO transport is not remotely accessible. This server cannot be used by hosted MCP clients (Claude Web, etc.) and is limited to local CLI usage. No HTTP endpoint available.
Tool compositions require ID fields but no explicit contract on field names in responses. E.g., if create_dashboard returns {'id': 123, 'uuid': '...'}, LLM must guess which field create_widget expects as dashboard_id.