Which integrations are available for this server?

Provides tools for executing SQL queries, managing data sources, listing queries, and retrieving query results from a Redash instance through API key-based authentication.

How do I use Redash MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Redash MCP Server show me the top 10 customers by revenue this month" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Redash MCP Server

by jasonsmithj

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Redash MCP Server

Docker Hub Docker Pulls License: MIT

A Model Context Protocol (MCP) server for Redash that provides query execution, data source management, and more through a standardized interface.

✨ Features

🔍 Query Execution: Execute SQL queries and retrieve results
📊 Data Source Management: List and inspect data sources
🔐 Secure: API key-based authentication
🐳 Docker Support: Easy deployment with Docker
✅ Fully Tested: Comprehensive test coverage with TDD approach
🚀 Modern Stack: Built with TypeScript, Vite, and latest tooling

Related MCP server: Redshift MCP Server

📋 Requirements

Node.js: >= 26.0.0 (26.7.0 recommended)
pnpm: >= 11.0.0 (11.22.0 recommended)
Redash Instance: With API access
Docker (optional): For containerized deployment

🚀 Quick Start

Local Installation

Clone the repository:

git clone https://github.com/jasonsmithj/redash-mcp.git
cd redash-mcp

Install dependencies:

pnpm install

Build the project:

pnpm build

Link globally:

pnpm link

Configure your MCP client (Claude Desktop, Cursor, etc.):

{
  "mcpServers": {
    "redash": {
      "command": "redash-mcp",
      "env": {
        "REDASH_API_KEY": "your_api_key_here",
        "REDASH_BASE_URL": "https://redash.example.com"
      }
    }
  }
}

Using Docker Hub (Recommended)

Pull the latest image from Docker Hub:

docker pull jasonsmithj/redash-mcp:latest

Run with Docker:

docker run -i --rm \
  -e REDASH_API_KEY=your_api_key \
  -e REDASH_BASE_URL=https://redash.example.com \
  jasonsmithj/redash-mcp:latest

Or use Docker Compose:

# Create .env file
cp .env.example .env
# Edit .env with your credentials

# Start the service
docker compose up

Configure your MCP client:

{
  "mcpServers": {
    "redash": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "REDASH_API_KEY",
        "-e",
        "REDASH_BASE_URL",
        "jasonsmithj/redash-mcp:latest"
      ],
      "env": {
        "REDASH_API_KEY": "your_api_key_here",
        "REDASH_BASE_URL": "https://redash.example.com"
      }
    }
  }
}

Building from Source

If you prefer to build from source:

docker build -t redash-mcp:local .

🔧 Configuration

Environment Variables

Variable	Required	Default	Description
`REDASH_API_KEY`	✅	-	Your Redash API key
`REDASH_BASE_URL`	✅	-	Redash instance URL
`REDASH_API_TIMEOUT`	❌	30000	API request timeout (milliseconds)

Getting Your Redash API Key

Log in to your Redash instance
Click on your profile icon → "Edit Profile"
Copy your API key from the "API Key" section

🛠 Available Tools

1. `list_data_sources`

List all available data sources in Redash.

Parameters: None

Example:

List all data sources

2. `get_data_source`

Get details about a specific data source.

Parameters:

data_source_id (number): The ID of the data source

Example:

Get details for data source 1

3. `execute_query_and_wait`

Execute a SQL query and wait for the result.

Parameters:

query (string): The SQL query to execute
data_source_id (number): The ID of the data source
max_age (number, optional): Maximum age of cached results in seconds

Example:

Execute query "SELECT * FROM users LIMIT 10" on data source 1

4. `list_queries`

List all queries in Redash.

Parameters:

page (number, optional): Page number (default: 1)
page_size (number, optional): Results per page (default: 25)

Example:

List all queries

🧪 Development

Setup

# Install dependencies
pnpm install

# Run tests
pnpm test

# Run tests with UI
pnpm test:ui

# Run tests with coverage
pnpm test:coverage

# Type check
pnpm typecheck

# Lint
pnpm lint

# Format code
pnpm format

# Run all checks (CI equivalent)
pnpm ci

Testing with act

Test GitHub Actions locally using act:

# List available workflows
act -l

# Run CI workflow
act push --workflows .github/workflows/ci.yml

# Run specific job
act push --workflows .github/workflows/ci.yml --job quality

Project Structure

redash-mcp/
├── src/
│   ├── index.ts              # MCP server entry point
│   ├── redash-client.ts      # Redash API client
│   ├── types.ts              # Type definitions
│   └── tools/                # MCP tools
│       ├── datasource.ts     # Data source tools
│       └── query.ts          # Query execution tools
├── tests/                    # Test files
├── scripts/                  # Build scripts
├── .github/
│   └── workflows/            # GitHub Actions CI/CD
├── Dockerfile                # Docker configuration
├── compose.yaml              # Docker Compose configuration
├── pnpm-workspace.yaml       # pnpm build-script policy
├── tsconfig.build.json       # Production TypeScript build configuration
└── package.json

📦 Scripts

pnpm dev: Watch mode for development
pnpm build: Build for production
pnpm test: Run tests
pnpm test:ui: Run tests with the Vitest UI
pnpm test:coverage: Run tests with coverage report
pnpm typecheck: Type-check source and tests
pnpm lint: Lint code
pnpm lint:fix: Fix lint issues where possible
pnpm format: Format code
pnpm format:check: Check formatting without modifying files
pnpm ci: Run all quality checks

🏗 Tech Stack

Runtime: Node.js 26.7 with ES Modules and an ES2025 target
Language: TypeScript 6.0 (strict mode)
Build Tool: Vite 8.x
Package Manager: pnpm 11.x
Testing: Vitest 4.x with V8 coverage
Linting: ESLint 10.x (Flat Config)
Formatting: Prettier 3.x
MCP SDK: @modelcontextprotocol/sdk 1.x

📦 Docker Images

Pre-built Docker images are available on Docker Hub:

Latest stable: jasonsmithj/redash-mcp:latest
Specific version: jasonsmithj/redash-mcp:v1.0.0
Major version: jasonsmithj/redash-mcp:1

Supported Platforms

Multi-architecture images are automatically built for both platforms:

linux/amd64 (x86_64) - Intel/AMD CPUs
- Windows PCs
- Intel-based Macs
- Traditional Linux servers
linux/arm64 (ARM64) - ARM CPUs
- Apple Silicon Macs (M1/M2/M3/M4)
- ARM-based Linux servers
- Raspberry Pi 4+ (64-bit)

Docker will automatically pull the correct image for your platform!

🚀 Releasing

To release a new version:

Update version in package.json
Commit changes: git commit -am "chore: bump version to vX.Y.Z"
Create and push tag: git tag vX.Y.Z && git push origin vX.Y.Z
GitHub Actions will automatically build and push to Docker Hub

🤝 Contributing

Contributions are welcome! Please follow these steps:

Fork the repository
Create a feature branch: git checkout -b feature/amazing-feature
Make your changes and add tests
Run quality checks: pnpm ci
Commit your changes: git commit -m 'Add amazing feature'
Push to the branch: git push origin feature/amazing-feature
Open a Pull Request

Development Guidelines

Follow TDD (Test-Driven Development) approach
Write tests before implementation
Maintain test coverage above 85%
Use conventional commits
Add JSDoc comments for public APIs
All code comments should be in English

Setting up GitHub Secrets for CD

To enable automated Docker Hub publishing, add the following secrets to your GitHub repository:

Go to Settings → Secrets and variables → Actions
Add the following secrets:
- DOCKER_USERNAME: Your Docker Hub username
- DOCKER_PASSWORD: Your Docker Hub password or access token

For enhanced security, use a Docker Hub access token instead of your password:

Log in to Docker Hub
Go to Account Settings → Security → New Access Token
Generate a token with "Read, Write, Delete" permissions
Use this token as DOCKER_PASSWORD

📝 License

This project is licensed under the MIT License - see the LICENSE file for details.

📮 Support

Issues: GitHub Issues
Discussions: GitHub Discussions

Made with ❤️ by the Redash MCP community

Available Tools

4 tools

execute_query_and_waitC

Execute a SQL query and wait for the result

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The SQL query to execute
`data_source_id`	Yes	The ID of the data source to query
`max_age`	No	Maximum age of cached results in seconds

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions waiting for the result, which implies synchronous behavior, but fails to cover critical aspects like permissions needed, rate limits, error handling, or whether the query can be destructive (e.g., UPDATE/DELETE). This leaves significant gaps for a tool that executes SQL queries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of executing SQL queries, the lack of annotations, and no output schema, the description is incomplete. It does not address behavioral traits like safety, performance, or result format, leaving the agent with insufficient context for reliable tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters (query, data_source_id, max_age) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as query syntax examples or data source context, meeting the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('execute') and resource ('SQL query'), specifying that it waits for the result, which distinguishes it from potential async variants. However, it does not explicitly differentiate from sibling tools like list_queries, which might also involve queries but for listing rather than execution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as whether to use it for read-only queries or if there are async options. The description lacks context on prerequisites, exclusions, or comparisons to siblings like get_data_source or list_data_sources.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_data_sourceC

Get details about a specific data source

ParametersJSON Schema

Name	Required	Description	Default
`data_source_id`	Yes	The ID of the data source

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states it 'gets details', implying a read operation. It lacks behavioral context such as authentication needs, rate limits, error handling, or what 'details' include (e.g., metadata, status). This is inadequate for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' are returned, error conditions, or how it fits with sibling tools. For a tool with minimal structured data, more context is needed to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents the single parameter 'data_source_id'. The description adds no additional meaning beyond implying it retrieves details for a specific source, aligning with the schema but not enhancing it. Baseline 3 is appropriate as the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'details about a specific data source', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_data_sources' beyond the singular vs. plural distinction, missing explicit contrast in scope or function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites like needing a data source ID, contrast with 'list_data_sources' for multiple sources, or relate to other siblings like 'execute_query_and_wait' for querying data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_data_sourcesB

List all available data sources in Redash

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List all available data sources') but doesn't describe behavioral traits such as whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination, format), or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resource, making it highly efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It states what the tool does, but without annotations or output schema, it lacks details on behavior and return values. For a list operation, more context on result format or constraints would be helpful, but it meets the basic threshold for such a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied for tools with no parameters, as there's nothing to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('all available data sources in Redash'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_data_source' (which likely retrieves a single data source) or 'list_queries' (which lists queries rather than data sources), missing full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like needing a list versus a single data source (vs. 'get_data_source') or when to use this versus 'list_queries', nor does it specify any prerequisites or exclusions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_queriesC

List all queries in Redash

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number (default: 1)
`page_size`	No	Number of results per page (default: 25)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. 'List all queries' implies a read-only operation, but it doesn't mention pagination behavior, rate limits, authentication requirements, or what 'all queries' encompasses (e.g., visibility permissions). The description is minimal and lacks important operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple list operation and gets straight to the point without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the output contains (query metadata, IDs, names), how pagination works in practice, or any limitations. The agent would need to guess about the return format and operational behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents both parameters (page and page_size) with defaults and constraints. The description adds no parameter information beyond what's in the schema, meeting the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and target resource ('all queries in Redash'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'list_data_sources', but the verb+resource combination is specific enough for basic understanding.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives like 'execute_query_and_wait' or 'get_data_source'. The description doesn't mention any prerequisites, context, or exclusions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Jan 4, 2026
- Changedexecute_query_and_wait1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedget_data_source1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedlist_data_sources1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedlist_queries1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
4 tool updatesNov 7, 2025
- First observedexecute_query_and_wait
- First observedget_data_source
- First observedlist_data_sources
- First observedlist_queries

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-04-18 08:05 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: execute_query_and_wait runs queries, get_data_source retrieves details of a single data source, list_data_sources enumerates all data sources, and list_queries lists all queries. The descriptions make it easy to differentiate between query execution and metadata retrieval functions.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case naming: execute_query_and_wait, get_data_source, list_data_sources, and list_queries. The verbs (execute, get, list) are appropriate and predictable for their respective actions.

Tool Count3/5

With only 4 tools, the set feels thin for a Redash server, which typically involves more operations like creating/updating queries, managing dashboards, or handling query results. While the tools cover basic query execution and listing, the scope seems limited compared to what might be expected for full Redash integration.

Completeness2/5

There are significant gaps in the tool surface for Redash functionality. The tools only support query execution and listing of data sources/queries, missing essential CRUD operations for queries (create, update, delete), dashboard management, user administration, and result visualization. This incomplete coverage will likely cause agent failures when trying to perform common Redash tasks beyond basic queries.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

Dot - AI Data AnalystOAuth
io.github.zurferr
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Search Databases Data Visualization
2
mcp-server AOAuth
io.quanti
Query BigQuery, Snowflake, Redshift & Azure Synapse with natural language
Databases Search Data Platforms
2
Databricks B
io.github.mcp-dir
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
Data Platforms Databases
171
Dataassist-IOOAuth
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2

Related MCP Servers

Metabase MCP Server
Databases Data Platforms
CPR43
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Metabase analytics platform, allowing users to query databases, manage dashboards and cards, execute SQL queries, and access analytics data through natural language.
Updated a year ago (2025-04-19 14:42 UTC)
29 npm
1
MIT
Redshift MCP Server
Databases RAG Systems Search
DeepaRajareddy
F
license
B
quality
D
maintenance
Enables AI agents to interact with Amazon Redshift databases using natural language to execute queries, list tables, describe schemas, and retrieve sample data.
Updated 9 months ago (2025-12-30 02:00 UTC)
5
-
Redshift MCP Server
Databases Search RAG Systems
santosh07401
F
license
A
quality
D
maintenance
Enables AI agents to interact with Amazon Redshift databases using natural language to execute queries, explore schemas, and retrieve sample data.
Updated 9 months ago (2025-12-30 01:03 UTC)
5
-
Redash MCP Server
Databases Search Data Platforms
yuki9541134
F
license
B
quality
D
maintenance
Enables interaction with Redash through its API to execute SQL queries, retrieve results, and manage data sources. It allows users to query data and explore data sources directly through natural language interfaces.
Updated 6 months ago (2026-03-25 07:24 UTC)
3
4
-

Redash MCP Server

✨ Features

📋 Requirements

🚀 Quick Start

Local Installation

Using Docker Hub (Recommended)

Building from Source

🔧 Configuration

Environment Variables

Getting Your Redash API Key

🛠 Available Tools

1. list_data_sources

2. get_data_source

3. execute_query_and_wait

4. list_queries

🧪 Development

Setup

Testing with act

Project Structure

📦 Scripts

🏗 Tech Stack

📦 Docker Images

Supported Platforms

🚀 Releasing

🤝 Contributing

Development Guidelines

Setting up GitHub Secrets for CD

📝 License

📮 Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `list_data_sources`

2. `get_data_source`

3. `execute_query_and_wait`

4. `list_queries`