List connected data sources (id, name, type). Call this first to get data_source_id.

List tables in a data source. Use keyword to filter by name. Verify table names here before writing SQL.

Get the column names and data types for one or more tables in a data source. Accepts a single table or a comma-separated list of tables. Use this to confirm exact column names and types before writing SQL with run_query or smart_query. Returns each table's columns; if a table name is not found, it suggests verifying it with list_tables.

Execute an ad-hoc SQL query against a data source and return the resulting rows. Every query passes through the SQL safety guard, which blocks destructive statements (DROP/TRUNCATE/ALTER, DELETE/UPDATE without WHERE) and flags PII columns and expensive full scans; results are cached in memory. Behavior: returns up to max_rows rows as a markdown table or JSON, with the column list and a truncation note when there are more rows. Usage: confirm table and column names with list_tables and get_table_columns first; for natural-language questions, plan the SQL with smart_query before calling this. To run an already-saved query instead, use get_query_result.

List saved (named) queries in Redash, most recently updated first. Behavior: returns a paginated array where each item has id, name, description, data_source_id, and updated_at. Usage: use this to discover query_ids, then call get_query for a query's full SQL and visualizations, or get_query_result to run it. Supports keyword search and pagination; for ad-hoc SQL that isn't saved, use run_query instead.

Run an existing saved query by its ID and return the latest results. Behavior: executes the query as stored in Redash and returns up to max_rows rows as a markdown table or JSON, with the column list and a truncation note. Usage: find the query_id with list_queries or get_query. Unlike run_query, this executes already-saved SQL rather than ad-hoc SQL, so the safety guard does not apply.

Get the full definition of a saved query. Behavior: returns the query's SQL text, data_source_id, tags, owner, update time, and its visualizations (each with id, name, type). Usage: find the query_id with list_queries. The returned visualization ids can be placed on a dashboard with add_widget; to actually run the query use get_query_result.

Save a new named SQL query to Redash so it can be reused, scheduled, visualized, or added to a dashboard. Behavior: creates the query and returns its new id, name, and created_at. Usage: get the data_source_id from list_data_sources and verify the SQL runs with run_query first; to change an existing query use update_query instead. Note: this only saves the query — use get_query_result to execute it.

Update fields of an existing saved query. Behavior: only the fields you pass are changed (name, SQL, description, or tags); any omitted field is left untouched. Returns the query's id, name, and updated_at. Usage: find the query_id with list_queries or get_query; to create a brand-new query instead, use create_query.

Fork (duplicate) an existing saved query into a new, independently editable copy, leaving the original unchanged. Behavior: creates the copy and returns its new id and name. Usage: find the query_id to fork with list_queries; use this when you want to experiment with or adapt a query without modifying the original.

Archive a saved query, removing it from active query lists. This is Redash's form of deletion and cannot be undone through the API, so confirm with the user before calling it. Behavior: archives the query and returns a confirmation message. Usage: find the query_id with list_queries.

List dashboards in Redash, most recently updated first. Behavior: returns a paginated array where each item has id, name, slug, and created/updated timestamps. Usage: use this to discover a dashboard's id or slug, then call get_dashboard to inspect its widgets and visualizations, or create_dashboard to make a new one. Supports keyword search and pagination.

Get a dashboard's full layout. Behavior: returns the dashboard's id, name, slug, and every widget, each with its linked visualization (id, name, type) and the query behind it (id, name). Usage: find the dashboard id or slug with list_dashboards; use the returned visualization/query ids to understand or extend the dashboard with add_widget.

Create a new, empty dashboard. Behavior: creates the dashboard and returns its id, name, and slug. Usage: after creating it, populate it with charts using add_widget, passing visualization ids obtained from get_query. To list or inspect existing dashboards instead, use list_dashboards / get_dashboard.

Add a saved query's visualization onto a dashboard as a widget. Behavior: places the widget and returns its id and dashboard_id. Usage: get the dashboard_id from list_dashboards or create_dashboard, and the visualization_id from get_query (each saved query exposes its visualizations). This is how you build up a dashboard after creating it.

List all alerts configured in Redash. Behavior: returns an array where each alert has id, name, current state (ok / triggered / unknown), last_triggered_at, its linked query (id, name), and threshold options. Usage: use this to discover alert_ids, then call get_alert for one alert's full detail, or create_alert to add a new one.

Get the full detail of a single alert. Behavior: returns the alert's id, name, current state, last_triggered_at, threshold options (column, operator, value), and the query it monitors (id, name, description, data_source_id). Usage: find the alert_id with list_alerts.

Create an alert that watches a saved query and fires when a chosen result column crosses a threshold (e.g., daily_signups less than 10). Behavior: creates the alert and returns its id and name. Usage: get the query_id from list_queries and confirm the exact column name with get_query / get_query_result first. The alert evaluates the query's latest result on Redash's schedule.

BIRD SQL-based intelligent query tool. Analyzes natural-language questions to (1) extract relevant schema, (2) match similar few-shot examples, (3) assess complexity, (4) request clarification for ambiguous questions. Call this tool before run_query. For a new data source, first inspect the schema with list_tables, then register keyword-to-table mappings via manage_keyword_map to significantly improve accuracy. Note: when ANTHROPIC_API_KEY is set, table-name lists (never query results or row data) may be sent to the Anthropic API as a fallback for table selection.

Manage the few-shot examples that smart_query uses to generate more accurate SQL. Behavior: action 'list' returns all stored examples with their ids; 'add' saves a new example (requires the example object); 'remove' deletes one (requires example_id). Each example pairs a natural-language question with the correct SQL and the tables it uses, teaching the model your schema's domain conventions. Usage: examples are stored locally per data_source_id and are retrieved automatically by smart_query — register a few for recurring question patterns to raise accuracy.

Record whether the SQL produced for a question was correct, so smart_query improves over time. Behavior: stores an up/down rating; when you rate 'down' and supply the correct SQL, the error is classified and, if the same kind of mistake recurs, automatically promoted into a few-shot example. Returns the feedback id and any error type or promotion. Usage: call after reviewing smart_query/run_query output; feedback is stored locally per data_source_id and feeds the learning loop.

Build and run an accuracy test suite for SQL generation on a data source. Behavior: action 'add_test' stores a question paired with ground-truth SQL; 'list_tests' shows them; 'remove_test' deletes one; 'run' scores generated SQL against the test cases; 'results' shows the latest run. Usage: use this to measure whether keyword maps and few-shot examples actually improve smart_query accuracy over time; test cases and runs are stored locally per data_source_id.

Manage keyword-to-table-name mappings. After inspecting the schema with list_tables, register domain-specific mappings to improve smart_query table-matching accuracy. e.g., {"revenue": ["payment"], "creator": ["creator"]}

View BIRD SQL configuration and status.