The Redash MCP Server allows you to interact with a Redash instance via the Redash API to execute queries, manage data sources, and retrieve results.
Capabilities:
Execute SQL queries: Run SQL queries against a data source and wait for results, with optional data source selection and cache expiration (max_age) settings
List data sources: Retrieve all available data sources configured in Redash
Get data source details: Fetch detailed information about a specific data source by ID
Retrieve saved queries: Get a saved query's details (including SQL text) by ID, or search for saved queries by keyword
Access query results: Fetch existing query results by ID without re-executing, or get the latest cached result for a saved query
The server supports multiple deployment modes (stdio, Streamable HTTP, SSE) and flexible configuration via environment variables or Docker.
Provides tools for interacting with the Redash API, enabling the execution of SQL queries, retrieval of query results, and the management of data sources.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Redash MCP Server List all data sources and count the total users from data source 1"
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 APIのMCPサーバーで、クエリの実行、結果の取得などの機能を提供します。
execute_query_and_wait
SQLクエリを実行し、結果が利用可能になるまで待機します
入力パラメータ:
query (文字列): 実行するSQLクエリ
data_source_id (数値, 任意): クエリを実行するデータソースのID
max_age (数値, 任意): キャッシュ有効期限（秒）
戻り値: 利用可能になったクエリ結果
list_data_sources
利用可能なすべてのデータソースを一覧表示します
入力パラメータ: なし
戻り値: データソースの配列
get_data_source
特定のデータソースに関する詳細を取得します
入力パラメータ:
data_source_id (数値): データソースのID
戻り値: データソースの詳細情報
get_query
クエリIDにより保存済みクエリの詳細を取得します（SQLテキスト含む）
入力パラメータ:
query_id (数値): クエリID
戻り値: 保存済みクエリの詳細情報
search_queries
キーワードで保存済みクエリを検索します
入力パラメータ:
q (文字列): 検索キーワード
page (数値, 任意): ページ番号
page_size (数値, 任意): ページサイズ
戻り値: 検索にマッチした保存済みクエリの一覧
get_query_result
クエリ結果IDにより既存のクエリ結果を取得します（再実行なし）
入力パラメータ:
query_result_id (数値): クエリ結果ID
戻り値: クエリ結果
get_saved_query_result
クエリIDにより保存済みクエリの最新キャッシュ結果を取得します
入力パラメータ:
query_id (数値): クエリID
戻り値: 保存済みクエリの最新キャッシュ結果
Related MCP server: Redash MCP Server
Redash APIキーを取得してください。
Redashにログイン
「Edit Profile」をクリック
APIキーをコピーする
以下の環境変数が必要です:
REDASH_API_KEY: RedashのAPIキー
REDASH_BASE_URL: RedashのURL（例: https://redash.example.com）
DATA_SOURCE_ID（任意）: デフォルトのデータソースID（execute_query_and_wait で data_source_id を省略した場合に使用）
PORT（任意）: HTTPサーバーのポート番号（デフォルト: 3000、Streamable HTTP / SSE で使用）
git clone https://github.com/yuki9541134/mcp-redash.git
cd mcp-redash
npm install
npm run build
npm link3つの起動モードに対応しています。
stdio（デフォルト） | Streamable HTTP | SSE（非推奨） | |
起動フラグ | なし |
|
|
通信方式 | 標準入出力 | HTTP | HTTP（Server-Sent Events） |
ポート | 不要 | デフォルト 3000 | デフォルト 3000 |
エンドポイント | - |
|
|
主な用途 | ローカル利用 | リモート・複数クライアント共有 | レガシー互換 |
標準入出力で通信するモードです。MCPクライアントからローカルで利用する場合はこちらを使用します。
npm run build
node dist/index.js開発時は
npm run devでTypeScriptを直接実行できます。
npm link 済みであれば、npxで直接実行できます。
npx mcp-redashClaude Codeの .mcp.json 設定例:
{
"mcpServers": {
"redash": {
"type": "stdio",
"command": "npx",
"args": ["mcp-redash"],
"env": {
"REDASH_API_KEY": "<YOUR_API_KEY>",
"REDASH_BASE_URL": "https://redash.example.com"
}
}
}
}docker build -t yuki9541134/mcp-redash .Claude Codeの .mcp.json 設定例:
{
"mcpServers": {
"redash": {
"type": "stdio",
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "REDASH_API_KEY",
"-e", "REDASH_BASE_URL",
"yuki9541134/mcp-redash"
],
"env": {
"REDASH_API_KEY": "<YOUR_API_KEY>",
"REDASH_BASE_URL": "https://redash.example.com"
}
}
}
}HTTPサーバーとして起動し、Streamable HTTPプロトコルで通信するモードです。Webクライアントやリモート接続に適しています。
.env で PORT REDASH_BASE_URL REDASH_API_KEY を設定してから起動してください。
npm run build
node dist/index.js --streamable-http開発時は
npm run dev -- --streamable-httpでTypeScriptを直接実行できます。
docker compose up -d
.envのPORTでポートを変更できます（デフォルト: 3000）。
エンドポイント:
POST /mcp - リクエストの送信
GET /mcp - SSEストリームの確立（サーバー → クライアント通知用）
DELETE /mcp - セッションの終了
Claude Codeの .mcp.json 設定例:
{
"mcpServers": {
"redash": {
"type": "http",
"url": "http://localhost:3000/mcp"
}
}
}Codexのconfig.toml 設定例
[mcp_servers.redash]
type = "url"
url = "http://localhost:3000/mcp"非推奨: SSEモードはレガシー互換のために残されています。新規利用にはStreamable HTTPモードを推奨します。
HTTPサーバーとして起動し、Server-Sent Events (SSE) で通信するモードです。
npm run build
node dist/index.js --sse開発時は
npm run dev -- --sseでTypeScriptを直接実行できます。
エンドポイント:
GET /sse - SSE接続の確立
POST /messages - メッセージの送信
Claude Codeの .mcp.json 設定例:
{
"mcpServers": {
"redash": {
"type": "sse",
"url": "http://localhost:3000/sse"
}
}
}Execute a SQL query and wait for the results
| Name | Required | Description | Default |
|---|---|---|---|
| data_source_id | No | ||
| query | Yes | ||
| max_age | No |
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 'wait for the results', implying synchronous behavior, but fails to address critical aspects like error handling, timeout behavior (despite a 'max_age' parameter), authentication requirements, or rate limits. For a tool that executes queries, this leaves significant gaps in understanding its operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and efficiently communicates the basic purpose. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (which involves data sources, query syntax, and result handling), the description is incomplete. With no annotations, no output schema, and 0% schema description coverage, it fails to provide necessary context about inputs, outputs, or behavioral expectations. The agent would struggle to use this tool effectively without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (data_source_id, query, max_age) are documented in the schema. The description adds no semantic information about these parameters—it doesn't explain what 'data_source_id' refers to, what format 'query' should be in, or what 'max_age' represents. This forces the agent to guess parameter meanings, which is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('execute a SQL query and wait for the results'), which is specific and unambiguous. It distinguishes itself from sibling tools like 'get_data_source' and 'list_data_sources' by focusing on query execution rather than data source retrieval. However, it doesn't explicitly mention what resource it acts upon beyond 'SQL query', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites like needing a valid data source ID, nor does it differentiate from potential other query execution tools. Without any context on when or why to choose this tool, the agent lacks decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a specific data source
| Name | Required | Description | Default |
|---|---|---|---|
| data_source_id | Yes |
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 tool retrieves details, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'details' include. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with one parameter), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain return values, error cases, or parameter semantics, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds no information about the parameter 'data_source_id'. It doesn't explain what a data source ID is, its format, or where to find it. With one undocumented parameter, the description fails to compensate for the schema's lack of details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details about a specific data source'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_data_sources', which might retrieve multiple data sources rather than a specific one. This prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools like 'list_data_sources' or 'execute_query_and_wait', nor does it specify prerequisites or contexts for usage. This leaves the agent without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available data sources
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 but doesn't describe traits like whether this is a read-only operation, if it requires authentication, rate limits, pagination, or the format of returned data. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, performance, or return format, which are crucial for an agent to use the tool effectively. For a tool with no structured data support, the description should compensate more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned if there are implicit filters or options, though not required. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all available data sources', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_data_source', which might retrieve a single data source, leaving some room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_data_source' or 'execute_query_and_wait'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0execute_query_and_waitget_data_sourcelist_data_sourcesScored across 3 tools
Each tool has a clearly distinct purpose: execute_query_and_wait runs queries, get_data_source retrieves details for a specific source, and list_data_sources enumerates all sources. There is no overlap or ambiguity between these operations.
All tools follow a consistent verb_noun pattern (execute_query_and_wait, get_data_source, list_data_sources) with clear, descriptive names that align well with their functions.
With only 3 tools, the server feels under-scoped for a Redash-like data querying and visualization platform. Key operations like creating/updating queries, managing dashboards, or fetching query results are missing, making the set too thin for typical agent workflows.
The tool surface is severely incomplete for a Redash server. While it covers basic data source listing and query execution, it lacks essential CRUD operations for queries, dashboards, and visualizations, as well as lifecycle management tools, which will likely cause agent failures in complex tasks.
Query BigQuery, Snowflake, Redshift & Azure Synapse with natural language
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
