Connect Redash to ChatGPT: Manage Dashboards & Run SQL Queries

If you need to connect Redash to ChatGPT to automate data analysis, run custom SQL queries, or manage visualization dashboards, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and Redash's API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting Redash to Claude or explore our broader architectural overview on connecting Redash to AI Agents.

Giving a Large Language Model (LLM) read and write access to a BI and query execution platform like Redash is a massive engineering challenge. You have to handle complex asynchronous job polling, differentiate between cached and live query executions, and safely map database schemas to LLM context windows. Every time a developer adds a new data source or modifies a query parameter in Redash, your custom server code must be updated, redeployed, and tested.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Redash, connect it natively to ChatGPT, and execute complex data workflows using natural language.

The Engineering Reality of the Redash API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, implementing it against Redash's highly specific API is exceptionally painful.

If you decide to build a custom MCP server for Redash, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with Redash:

Cached Results vs. Fresh Execution

Redash strictly separates the concept of a query (the SQL string and metadata) from a query result (the actual data payload). When an LLM asks "Run the daily revenue query," standard API mapping assumes a synchronous GET request. In Redash, if you just fetch the query record, you get the SQL text, not the data. To get data, your MCP tool must call the query_results_resource endpoint. Furthermore, the API requires you to specify a max_age parameter. If omitted, Redash might return cached data from three days ago. If set to 0, it forces a fresh execution, which introduces the next major hurdle: asynchronous polling.

Asynchronous Query Job Polling

Redash does not always return query results immediately. If an LLM executes a heavy query against a Databricks or Snowflake cluster, Redash returns a Job ID. Your MCP server cannot just pass this Job ID back to the LLM - the LLM will hallucinate the result. Instead, your integration layer must explicitly poll the jobs endpoint until the status reaches 3 (Success) or 4 (Failure), extract the subsequent query_result_id, and then fetch the actual data.

Archiving Over Deletion

When an LLM attempts to clean up unused dashboards or queries by calling a delete tool, Redash does not actually remove the record from the database. Instead, it sets an is_archived=true flag. If your LLM subsequently tries to list all queries, the deleted queries will still appear in the payload unless explicitly filtered. This causes frequent hallucination loops where the LLM believes its delete action failed and attempts it repeatedly.

Redash to ChatGPT Quickstart Guide

If you just want the fastest path from a fresh Truto account to ChatGPT calling the Redash API, follow these five steps.

What you need:

• A Truto account with API access.
• A Redash User API Key (found in the Redash user profile settings).
• A ChatGPT Pro, Plus, Business, Enterprise, or Education seat with Developer mode available.

Step 1: Connect Redash as an Integrated Account

First, you need to authenticate your Redash instance. In the Truto dashboard, navigate to Integrated Accounts -> New Integrated Account, select Redash, and provide your Redash base URL and User API Key. Truto securely encrypts and stores this credential.

Step 2: Grab your Integrated Account ID

You can copy the integrated_account_id from the account detail page in the Truto UI, or list it via the API:

curl https://api.truto.one/integrated-account \
  -H "Authorization: Bearer $TRUTO_API_TOKEN"

Step 3: Generate a Redash MCP Server

Truto derives MCP tools dynamically from the underlying API documentation. You can generate an MCP server mapped specifically to your Redash account using either the Truto UI or the API.

Method A: Via the Truto UI

1. Navigate to the integrated account page for your Redash connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., allow only read methods, filter by specific tags like queries or dashboards).
5. Copy the generated MCP server URL.

Method B: Via the API Send a single POST request to generate the server URL programmatically:

curl -X POST https://api.truto.one/integrated-account/$INTEGRATED_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer $TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Redash Data Assistant",
    "config": {
      "methods": ["read", "write"],
      "tags": ["queries", "dashboards", "alerts"]
    }
  }'

The response contains a url field structured as https://api.truto.one/mcp/<token>. This single URL handles all reverse-proxy routing and authentication.

Step 4: Connect the MCP Server to ChatGPT

Now that you have your secure MCP URL, you can connect it directly to your LLM workspace.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode.
3. Under MCP servers / Custom connectors, click Add a new server.
4. Set a name (e.g., "Redash Analytics") and paste your Truto MCP URL into the Server URL field.
5. Click Save. ChatGPT will instantly connect and list all available Redash tools.

Method B: Via Manual Config File (for local dev/Claude Desktop) If you are using Claude Desktop or a local agent framework (like Cursor), you can configure the server using a JSON config file and the official SSE transport package:

{
  "mcpServers": {
    "redash_truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_SECURE_TOKEN"
      ]
    }
  }
}

Step 5: Handling Rate Limits

When giving an AI agent access to an analytics platform, rate limits are a critical concern. Truto does not retry, throttle, or apply backoff on rate limit errors automatically. When the upstream Redash API returns an HTTP 429 Too Many Requests error, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. Your AI agent or local framework is responsible for reading these headers and executing its own backoff strategy.

Hero Tools for Redash AI Agents

Truto automatically generates dozens of tools for Redash based on the integration's resource definitions. Exposing all of them to an LLM at once can overwhelm the context window. Here are the highest-leverage "hero tools" to expose to your AI agents.

1. list_all_redash_dashboards

Retrieves a list of all dashboards available in the Redash instance. This tool returns core metadata, including dashboard IDs, slugs, layout structures, and embedded widget configurations.

Usage note: Because dashboards can contain dozens of widgets, the payload can be large. LLMs should use this primarily to map human-readable dashboard names to their specific integer IDs for deeper inspection.

"List all of our Redash dashboards and find the ID for the 'Q3 Revenue Metrics' board."

2. list_all_redash_queries

Searches and lists saved queries. This tool accepts q (search query) and order parameters to filter through hundreds of historical SQL scripts. It returns the query text, associated data source IDs, and execution schedules.

Usage note: LLMs can use this tool to audit existing SQL logic or find reference queries before attempting to write their own custom SQL.

"Search our saved Redash queries for any scripts referencing the 'mrr_historical' table."

3. create_a_redash_query

Authors a new saved query in Redash. The LLM must provide the data_source_id and the actual query text. This effectively allows the LLM to write and deploy SQL directly to your analytics environment.

Usage note: Always ensure the LLM has first queried the data source schema (or has been provided the schema in its prompt) before calling this tool, otherwise the resulting SQL will likely fail upon execution.

"Create a new Redash query on data source ID 4 that selects the top 10 customers by lifetime value from the public.users table."

4. create_a_redash_query_results_resource

Executes a saved query and retrieves its result set. This is the primary execution tool. It accepts a query_id and optionally a max_age parameter to dictate caching behavior.

Usage note: If max_age is set to -1 or omitted, Redash will return the last cached run. Instruct your LLM to explicitly pass max_age: 0 if fresh, real-time data is required.

"Run query ID 142 to get the latest signups from today. Force a fresh execution so I get real-time data."

5. list_all_redash_alerts

Lists configured alerts that trigger when query results exceed defined thresholds. Returns the alert configurations, status, and associated query bindings.

Usage note: Useful for DevOps agents that need to cross-reference triggered notifications in Slack or PagerDuty with the underlying Redash thresholds.

"List all active Redash alerts and check if the 'High CPU Load' alert is currently in a triggered state."

6. list_all_redash_databricks_tables

Lists the tables available within a specific Databricks data source connected to Redash. Returns the schema structure.

Usage note: Because this specifically targets Databricks sources (returning a 400 error for non-Databricks sources), use it when building agents specialized in Lakehouse data exploration.

"Check the Databricks data source ID 7 and list all tables available in the 'production_analytics' schema."

To view the complete schema details and the rest of the available operations, visit the Redash integration page.

Workflows in Action

AI agents excel when combining these tools to orchestrate multi-step data engineering and analysis tasks. Here are two practical examples of how an agent uses Redash tools via Truto.

Workflow 1: Ad-hoc Data Analysis & Query Generation

A data analyst needs an immediate answer about specific user cohorts but does not have the exact SQL saved. They ask the agent to investigate.

"Find the data source ID for our primary PostgreSQL replica, write a query to count active users by subscription tier for the last 30 days, save it, and run it to give me the results."

1. list_all_redash_data_sources: The agent fetches all sources and identifies the PostgreSQL replica (ID: 5).
2. create_a_redash_query: The agent drafts the SQL, passes data_source_id: 5, and saves the query. Redash returns the new query_id (e.g., 902).
3. create_a_redash_query_results_resource: The agent executes query ID 902 with max_age: 0 to ensure fresh data.
4. Outcome: The user receives a natural language breakdown of active users by tier, powered by a brand new query that is now saved in Redash for future use.

sequenceDiagram
  participant User as "User"
  participant Agent as "ChatGPT"
  participant MCP as "Truto MCP Server"
  participant Redash as "Redash API"
  User->>Agent: "Write and run a query for active users..."
  Agent->>MCP: Call list_all_redash_data_sources
  MCP->>Redash: GET /api/data_sources
  Redash-->>MCP: Returns Data Sources
  MCP-->>Agent: Data Sources (Identifies ID: 5)
  Agent->>MCP: Call create_a_redash_query (SQL Payload)
  MCP->>Redash: POST /api/queries
  Redash-->>MCP: Returns new query_id: 902
  MCP-->>Agent: Query Saved (ID: 902)
  Agent->>MCP: Call create_a_redash_query_results_resource (query_id: 902)
  MCP->>Redash: POST /api/queries/902/results
  Redash-->>MCP: Returns Result Set
  MCP-->>Agent: Rows and Columns
  Agent-->>User: Summarizes cohort data

Workflow 2: Alert Triage & Muting

A DevOps engineer sees an anomaly in a Slack channel and wants the agent to investigate the underlying Redash alert and temporarily silence it while they deploy a hotfix.

"Check the status of the 'Spike in 500 Errors' alert in Redash. If it's triggered, mute it for now while I push a patch."

1. list_all_redash_alerts: The agent lists alerts and filters the payload to find the specific error alert (ID: 45).
2. get_single_redash_alert_by_id: The agent checks the detailed state of alert ID 45 and confirms its status is 'TRIGGERED'.
3. create_a_redash_alert_mute: The agent executes the mute action on alert_id: 45.
4. Outcome: The user receives confirmation that the alert is silenced, preventing further notification spam during the incident.

Security and Access Control

Giving an AI model execution rights to your analytics database requires strict governance. Truto's MCP servers provide several layers of access control configured at the token level:

• Method Filtering: Restrict the MCP server to specific HTTP methods. By setting methods: ["read"], the LLM can list dashboards and fetch query results, but cannot create, update, or delete queries.
• Tag Filtering: Limit the surface area by resource context. Configuring tags: ["dashboards"] ensures the LLM only sees tools related to dashboards, hiding sensitive data source credential endpoints.
• Expiration (expires_at): Generate ephemeral servers for short-lived debugging sessions. You can set an ISO timestamp, and Truto will automatically revoke the underlying KV token and schedule database cleanup when the time expires.
• Double Authentication (require_api_token_auth): By default, the MCP token URL is sufficient for access. If require_api_token_auth is set to true, the caller must also provide a valid Truto API token in the Authorization header, preventing usage if the URL is accidentally leaked in logs.

The Safest Way to Build AI Analytics Assistants

Connecting Redash to ChatGPT empowers your team to interact with their data warehouse using natural language, but building that integration from scratch means absorbing deep technical debt. You have to write custom polling loops for async jobs, manage schema parsing, and constantly update tool definitions as the Redash API evolves.

Truto abstracts this entire layer. By deriving MCP tools directly from API documentation and managing the OAuth and protocol negotiation at the edge, you can provision secure, curated AI toolsets in minutes instead of months.