Loading ToolBench
MCP server for the Redash API. Provides tools to manage queries, dashboards, data sources, query results, users, alerts, and visualizations.
28 tools with consistent naming (verb_noun pattern) and complete input schemas. Descriptions present but often generic or overly technical. Parameter descriptions are adequate but lack constraint details (enums, ranges, formats). Output schemas not documented. Error handling minimal, no recovery guidance or actionable error messages. Security: API key properly injected server-side via auth.py. No tool annotations (readOnlyHint/destructiveHint). Composition is sound, tools are single-responsibility and chainable via IDs. Major gaps: descriptions under 100 chars for many tools, no output schema documentation, no enum constraints for string parameters, no pagination guidance in list tools.
Archive (soft-delete) a query.
Test the connection to a data source.
Create a new alert for a query. Args: query_id: ID of the query to monitor. name: Name of the alert. options_json: JSON string with alert options, e.g. '{"column": "count", "op": "greater than", "value": 100}'.
Create a new dashboard.
Create a new query. Args: name: Name of the query. query: The SQL query string. data_source_id: ID of the data source to run the query against. description: Optional description of the query. schedule_json: Optional JSON string with schedule config, e.g. '{"interval": 3600, "until": null}'.
Execute a saved query and return the result. Args: query_id: ID of the saved query to execute. parameters_json: Optional JSON string with query parameters, e.g. '{"date": "2024-01-01"}'.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., what fields does get_query return? Does it include visualization IDs for chaining to list_query_visualizations?).
String parameters lack enum constraints. E.g., create_alert's 'options_json' and update_dashboard's 'tags_json' accept free-form JSON strings without validation hints. LLMs may hallucinate invalid JSON structures.
List tools (list_alerts, list_dashboards, list_queries, list_users) lack pagination guidance in descriptions. No mention of result limits, total counts, or next_cursor patterns. Agents may request thousands of items.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Execute SQL directly against a data source without saving a query. Blocks until results are ready (up to 60 seconds for async jobs). Args: data_source_id: ID of the data source to run the query against. query: SQL query string to execute. max_age: Use cached result if younger than this many seconds (0 = always re-run).
Get a specific alert by its ID.
Get a specific dashboard by its ID or slug.
Get a specific data source by its ID.
Get the schema of a data source (tables and columns). Args: data_source_id: ID of the data source. refresh: If true, refresh the schema from the data source.
Get foreign key relationships defined in the database. Note: Data warehouses like Redshift often have few or no formal FK constraints. Use infer_table_relationships for convention-based discovery. Args: data_source_id: ID of the data source. schema_name: Optional schema to filter. table_name: Optional table name to filter.
Get a specific query by its ID.
Get the latest result for a query.
Get recently executed queries.
Get detailed column information (name, data type, position) for tables. Queries the database catalog directly to get column types, unlike get_data_source_schema which only returns column names. Args: data_source_id: ID of the data source. schema_name: Optional schema to filter (e.g. 'public', 'external'). table_name: Optional table name to filter.
Get a specific user by their ID.
Infer table relationships by matching column naming conventions. Looks for columns ending in '_id' or '_cd' that match existing table names (e.g. customer_id -> customer table). Useful for data warehouses that don't define formal foreign keys. Args: data_source_id: ID of the data source. schema_name: Optional schema to filter source tables.
List all alerts.
List dashboards with optional search and pagination.
List all available data sources.
List saved queries with optional search and pagination.
List all visualizations for a query. Fetches the query and extracts its visualizations array.
List all users with pagination.
Trigger a query execution and return the result.
Search queries by name or description.
Update an existing dashboard. Args: dashboard_id: ID of the dashboard to update. name: New name for the dashboard. is_draft: Whether the dashboard is a draft. tags_json: Optional JSON string with list of tags, e.g. '["tag1", "tag2"]'.
Update an existing query. Args: query_id: ID of the query to update. name: New name for the query. query: New SQL query string. description: New description. schedule_json: Optional JSON string with schedule config.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe reads from destructive writes without parsing descriptions. archive_query and create_* tools should be marked destructive/write.
Error handling minimal. client.py returns generic HTTP error objects without recovery guidance. E.g., 'Redash API error: 404' tells agent nothing about what to try next (search? retry? different ID format?).