Redash MCP Server
A Redash MCP server that lets AI assistants browse, execute, and manage Redash queries, dashboards, visualizations, widgets, alerts, and snippets.
Queries: list, get, create, update, archive, fork, search by tags, view favorites/my/recent queries, and manage saved query parameters.
Execution: run saved, parameterized, or ad-hoc queries; fetch CSV results (optionally refreshed).
Schema discovery: list data sources and page through a data source's schema.
Snippets: list, get, create, update, and delete reusable SQL snippets.
Dashboards: list, get (by ID or slug), create, update, archive, fork, share/unshare public links, inspect/update parameters, and manage favorites and tags.
Widgets: list, get, create, update, delete, move/resize (single or bulk layouts), and inspect/update parameter mappings.
Visualizations: create, update, patch chart-specific options, and delete.
Alerts: list, get, create, update, delete, mute, and manage subscriptions; list notification destinations.
Allows integration with Redash instances to list queries and dashboards, execute queries, create and manage queries, list data sources, and get dashboard details and visualizations
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 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
Model Context Protocol (MCP) server for integrating Redash with AI assistants like Claude.
Features
Connect to Redash instances via the Redash API
List available queries and dashboards as resources
Execute queries and retrieve results
Execute saved parameterized queries with typed values and saved defaults
Create and manage queries (create, update, archive)
Manage query parameters, dashboard parameters, and widget parameter mappings
Inspect and update dashboard widget layouts and grid positions
List data sources for query creation
Get dashboard details and visualizations
Update chart visualization options with Redash chart-specific settings
Related MCP server: redash-mcp
Prerequisites
Node.js (v22.13 or later)
Corepack (included with Node.js 22; it selects the pnpm version pinned in
package.json)Access to a Redash instance
Redash API key
Environment Variables
The server requires the following environment variables:
REDASH_URL: Your Redash instance URL (e.g., https://redash.example.com)REDASH_API_KEY: Your Redash API key
Optional variables:
REDASH_TIMEOUT: Timeout for API requests in milliseconds (default: 30000)REDASH_MAX_RESULTS: Maximum number of results to return (default: 1000)REDASH_EXTRA_HEADERS: Extra HTTP headers to include with every Redash request. Accepts either a JSON object string or a semicolon/comma-separated list ofkey=valuepairs.REDASH_SOCKS_PROXY: SOCKS proxy URL for routing requests through a proxy (e.g.,socks5h://localhost:1080). Usesocks5h://(withh) to delegate DNS resolution to the proxy, which is required for internal hostnames that don't resolve on the local machine.MCP_TRANSPORT: MCP transport to use. Supported values arestdio,http, andstreamable-http(default:stdio).MCP_HTTP_HOST: Host for Streamable HTTP mode (default:127.0.0.1).MCP_HTTP_PORT: Port for Streamable HTTP mode (default:3000).MCP_HTTP_PATH: Streamable HTTP endpoint path (default:/mcp).MCP_HTTP_ALLOWED_HOSTS: Comma-separated Host header allowlist for Streamable HTTP mode. Values are hostnames without a scheme, port, path, or wildcard.MCP_HTTP_ALLOWED_ORIGINS: Comma-separated browser Origin hostname allowlist. Values use the same hostname-only format and also control CORS responses. Set an empty value to reject every request that includes anOriginheader.OpenTelemetry variables: optional; see OpenTelemetry observability for concrete OTLP and Prometheus configurations.
Examples:
JSON (recommended):
REDASH_EXTRA_HEADERS='{"CF-Access-Client-Id":"<client_id>","CF-Access-Client-Secret":"<client_secret>"}'Key/value list:
REDASH_EXTRA_HEADERS=CF-Access-Client-Id=<client_id>;CF-Access-Client-Secret=<client_secret>Notes:
The
Authorizationheader is managed by the server (Key <REDASH_API_KEY>) and cannot be overridden.All extra headers are added to every request made to Redash.
Installation
Clone this repository:
git clone https://github.com/suthio/redash-mcp.git cd redash-mcpEnable Corepack and install dependencies:
corepack enable pnpm installCreate a
.envfile with your Redash configuration:REDASH_URL=https://your-redash-instance.com REDASH_API_KEY=your_api_key # Optional: Cloudflare Access (or other gateway) headers # REDASH_EXTRA_HEADERS='{"CF-Access-Client-Id":"<client_id>","CF-Access-Client-Secret":"<client_secret>"}'Build the project:
pnpm run buildStart the server:
pnpm startThe default transport is stdio, which is the mode expected by most desktop MCP clients. The stdio entrypoint accepts both 2025-era MCP clients and clients that negotiate the current protocol.
Usage with Claude for Desktop
To use this MCP server with Claude for Desktop, configure it in your Claude for Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the following configuration (edit paths as needed):
{
"mcpServers": {
"redash": {
"command": "npx",
"args": [
"-y",
"@suthio/redash-mcp"
],
"env": {
"REDASH_API_KEY": "your-api-key",
"REDASH_URL": "https://your-redash-instance.com"
}
}
}
}Streamable HTTP Transport
The server can also run as a stateless Streamable HTTP MCP server. The HTTP entrypoint is a Hono application served by @hono/node-server; environment variables configure the listener:
REDASH_URL=https://your-redash-instance.com \
MCP_TRANSPORT=http \
pnpm startThis starts POST http://127.0.0.1:3000/mcp by default. CLI flags override environment variables:
REDASH_URL=https://your-redash-instance.com \
pnpm start --transport http --host 127.0.0.1 --port 3333 --path /mcpNote: REDASH_API_KEY is not needed here - in HTTP mode each MCP client request supplies its own Redash token via its Authorization header (see below). You can still set REDASH_API_KEY as a fallback for requests that don't send one.
For a non-local bind behind an authenticated, TLS-terminating reverse proxy, explicitly configure which request hosts and browser origins may reach the server. The equivalent CLI options are --allowed-hosts and --allowed-origins.
REDASH_URL=https://redash.example.com \
REDASH_API_KEY=your_api_key \
MCP_TRANSPORT=http \
MCP_HTTP_HOST=0.0.0.0 \
MCP_HTTP_ALLOWED_HOSTS=mcp.example.com \
MCP_HTTP_ALLOWED_ORIGINS=app.example.com \
pnpm startWho uses the server | MCP URL | Allowed Host header | Allowed browser Origin |
Local MCP client |
|
|
|
Local Docker client |
|
|
|
Browser app at |
|
|
|
Host and Origin matching is case-insensitive and port-agnostic. For example, allowing app.example.com accepts the browser Origin https://app.example.com:8443. In HTTP mode, binding MCP_HTTP_HOST to a non-local address fails at startup unless both allowlist settings are explicitly present.
Host and Origin allowlists protect against DNS rebinding and unwanted browser origins; they do not authenticate MCP clients. Do not expose the server listener directly to the internet. For https://mcp.example.com/mcp, keep the listener on a private network and require authentication at the reverse proxy or gateway.
HTTP mode is stateless: the server does not issue Mcp-Session-Id, does not provide a standalone GET SSE stream, and handles each POST /mcp with a fresh MCP server instance. Both current MCP clients and 2025-era Streamable HTTP clients use that same URL. GET /mcp and DELETE /mcp return 405 Method Not Allowed.
The default bind is localhost-only (127.0.0.1) with Host and Origin protection. Browser requests from allowed origins receive CORS response headers; other origins are rejected with 403 Forbidden.
GET http://127.0.0.1:3000/healthz returns 200 OK with the body ok for lightweight health checks. It uses the same Host and Origin allowlists as the MCP endpoint and does not contact Redash. If MCP_HTTP_PATH=/healthz, that URL remains the MCP endpoint and the standalone health check is disabled with a startup warning.
The CLI handles SIGINT and SIGTERM gracefully. For example, docker stop sends SIGTERM; the server closes active MCP streams and then waits for the HTTP listener to stop before the process exits.
OpenTelemetry observability
Operators use this integration to follow one MCP operation from the client, through this server, to Redash, and to alert on latency or process health. The CLI initializes OpenTelemetry automatically. With no exporter endpoint or exporter setting, it opens no telemetry network connection; application logs still go to stderr so stdio stdout remains reserved for MCP messages.
Choose the setup that matches the system reading the telemetry:
Who reads it | Set these variables | Where data is available |
An OpenTelemetry Collector receiving all three signals |
| Traces, metrics, and logs at the Collector OTLP/HTTP receiver |
Prometheus scraping an HTTP-mode server |
|
|
Prometheus scraping a stdio server |
|
|
A Collector plus Prometheus |
| OTLP metrics and the Prometheus endpoint |
For example, this HTTP-mode command exports all signals over OTLP/HTTP and also lets Prometheus scrape the same listener:
REDASH_URL=https://redash.example.com \
REDASH_API_KEY=your_api_key \
MCP_TRANSPORT=http \
OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4318 \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_METRICS_EXPORTER=otlp,prometheus \
pnpm start
curl http://127.0.0.1:3000/metricsThe server emits these signals:
Signal | Representative data | What it answers |
Traces | inbound | Which MCP or Redash operation was slow or failed? |
Metrics |
| Is latency, event-loop delay, memory, CPU, or network use changing? |
Logs | structured severity, fields, exception, and active | What happened inside the operation shown by a trace? |
The names and attributes visible in a trace backend are deliberately stable:
What the MCP client does | Span name | Attributes used to filter it |
Calls |
|
|
Reads |
|
|
Sends JSON-RPC error code | The MCP method name |
|
Posts to a custom endpoint |
|
|
mcp.protocol.version records the negotiated revision in both stdio and stateless HTTP operations. mcp.server.session.duration applies to the long-lived stdio connection; HTTP mode is stateless, so its useful lifecycle measurement is mcp.server.operation.duration. Both histograms use the MCP-recommended explicit latency buckets.
SEP-414 traceparent, tracestate, and baggage values in MCP request _meta are accepted. The extracted MCP client context becomes the MCP server span's parent, while the HTTP transport span is linked to it. Logs emitted while the tool runs carry the MCP span's trace_id and span_id.
Application log messages always go to stderr. When OTel Logs is configured, the same message is exported with its structured fields; those fields are not printed to stderr. A compatible stdio MCP client also receives the message through notifications/message for backward compatibility. Stateless HTTP does not send those notifications because each POST uses a fresh server instance; use OTel Logs or stderr there.
Exporter settings
The OTLP exporters support gRPC, HTTP/protobuf, and HTTP/JSON:
Protocol | Variable value | Typical Collector endpoint |
OTLP/gRPC |
|
|
OTLP/HTTP protobuf |
|
|
OTLP/HTTP JSON |
|
|
Set the shared OTEL_EXPORTER_OTLP_PROTOCOL, or override it with OTEL_EXPORTER_OTLP_TRACES_PROTOCOL, OTEL_EXPORTER_OTLP_METRICS_PROTOCOL, and OTEL_EXPORTER_OTLP_LOGS_PROTOCOL. The corresponding standard endpoint, header, certificate, compression, and timeout variables are passed to the OpenTelemetry exporters.
An endpoint enables its signal. You can make the decision explicit with OTEL_TRACES_EXPORTER=otlp, OTEL_METRICS_EXPORTER=otlp, and OTEL_LOGS_EXPORTER=otlp, or disable one with none. For example, this keeps logs on stderr while sending traces and metrics:
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector.internal:4318
OTEL_TRACES_EXPORTER=otlp
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=noneOTEL_SDK_DISABLED=true disables every telemetry signal. Invalid telemetry settings or an unavailable exporter produce a warning on stderr but do not stop MCP or Redash requests. Application configuration errors such as a missing REDASH_API_KEY still fail startup.
Prometheus endpoint and content safety
In HTTP mode, the embedded /metrics route uses the same Host allowlist as /mcp. If MCP_HTTP_PATH=/metrics, the server keeps that URL for MCP, traces it as POST /metrics, and disables the embedded Prometheus route with a warning. Set OTEL_EXPORTER_PROMETHEUS_HOST or OTEL_EXPORTER_PROMETHEUS_PORT to use a separate listener instead. A separate listener is not protected by the MCP Host/Origin checks, so bind it to 127.0.0.1 or protect it at the network layer.
Safe operation metadata is always available. Content that may contain Redash data requires an explicit opt-in:
Data | Default | With |
Tool name, query/data-source IDs, HTTP method/path/status, request header names | Recorded on the applicable span or OTel Log | Same |
Successful tool arguments and results, including SQL, description, options, visualizations, result rows, and CSV text | Omitted | Recorded once on the MCP |
Failed Redash request/response bodies and query job errors | Omitted | Recorded as structured OTel Log fields; stderr and the MCP error response remain content-free |
API keys and request header values | Never recorded | Never recorded |
The option uses the GenAI instrumentation name because the OpenTelemetry MCP conventions model a tool call as a GenAI-compatible execute_tool operation. The Redash server does not perform model inference; it reuses the common gen_ai.tool.call.* attributes so an MCP call can be correlated with the agent that invoked it. Enable the option only when the trace and log backends are approved to retain Redash content.
Embedding the server in another Node.js process
Initialize telemetry before importing the main package so Node HTTP and Axios are patched before Redash requests begin:
import {
initializeTelemetry,
shutdownTelemetry,
} from "@suthio/redash-mcp/telemetry";
await initializeTelemetry({ transport: "stdio" });
const { createRedashMcpServer } = await import("@suthio/redash-mcp");
const server = createRedashMcpServer();
// Connect and use the server, then flush exporters during application shutdown.
await server.close();
await shutdownTelemetry();When the embedding process exposes MCP over HTTP at POST /redash-mcp, pass that exact route during telemetry initialization and identify the application protocol when creating the server:
import {
initializeTelemetry,
shutdownTelemetry,
} from "@suthio/redash-mcp/telemetry";
await initializeTelemetry({ transport: "http", httpPath: "/redash-mcp" });
const { createRedashMcpServer } = await import("@suthio/redash-mcp");
const server = createRedashMcpServer({
networkTransport: "tcp",
networkProtocolName: "http",
recordSession: false,
});
// Connect `server` to the embedding process's POST /redash-mcp transport.
await server.close();
await shutdownTelemetry();Per-request authentication (multi-user HTTP deployments)
Redash's REST API is stateless and already carries its own auth on every call, so a single HTTP MCP process can safely be shared by many users - there is no need to run one process per user.
In HTTP transport mode, the server reads the Redash API token from each incoming MCP request's own Authorization header instead of the process-wide REDASH_API_KEY environment variable. This lets every user authenticate with their own personal Redash access token while REDASH_URL (and the process itself) stays shared and static:
# Client sends its own personal Redash token per request, e.g.:
# Authorization: Bearer <personal-redash-token>
# or
# Authorization: Key <personal-redash-token>Both Bearer <token> and Key <token> prefixes are accepted (the raw token is extracted either way); a bare token with no prefix also works. The token is then forwarded to Redash using Redash's own Key <token> scheme, regardless of how the client sent it.
If a request has no Authorization header, the server falls back to the static REDASH_API_KEY environment variable if one is set. If neither is available, the request fails with a clear error instead of silently using someone else's token.
This is why REDASH_API_KEY is optional (not required) when MCP_TRANSPORT=http. In stdio mode REDASH_API_KEY remains required exactly as before - stdio has no per-request headers, so nothing changes for existing stdio users.
A typical deployment behind nginx: one HTTP MCP process per Redash instance (e.g. one per environment, such as staging and production), with nginx handling TLS/path routing, and each user's MCP client configured to send their own personal Redash token as the Authorization header.
Docker
Container images are published to GitHub Container Registry for both linux/amd64 and linux/arm64.
docker run --rm -p 127.0.0.1:3000:3000 \
-e REDASH_URL=https://your-redash-instance.com \
-e REDASH_API_KEY=your_api_key \
ghcr.io/suthio/redash-mcp:latestThe container runs Streamable HTTP internally on 0.0.0.0:3000, while the example publishes that port on the host's loopback interface only. Its default Host and Origin allowlists accept localhost access. When placing the container behind an authenticated reverse proxy or a private cluster service, set MCP_HTTP_ALLOWED_HOSTS and MCP_HTTP_ALLOWED_ORIGINS to the concrete DNS names used by clients.
Published images are signed with keyless cosign.
Available Tools
Query Management
list_queries: List all available queries in Redashget_query: Get details of a specific querycreate_query: Create a new query in Redashupdate_query: Update an existing query in Redashget_query_parameters: Inspect saved query parameter definitionsupdate_query_parameters: Update saved query parameter definitionsarchive_query: Archive (soft-delete) a querylist_data_sources: List all available data sources
Query Execution
execute_query: Execute a query and return results, with optionalmaxAgeexecute_parameterized_query: Execute a saved parameterized query with type-aware value coercion, saved defaults, and optionalmaxAgeexecute_adhoc_query: Execute an ad-hoc query without saving it to Redashget_query_results_csv: Get query results in CSV format (supports optional refresh for latest data)
Schema Discovery
get_schema: Get the schema of a data source, paginated by table
Use get_schema when an MCP client needs table and column names for writing a
query. A caller can request a small page, inspect hasMore, and follow nextPage
without loading the entire warehouse schema into this MCP server. For BigQuery,
a configured location also allows the server to fetch only the requested tables.
Data source | How one page is read | Why |
BigQuery ( | Read the connection's configured | A configured location lets Redash avoid materializing its complete cached schema for very large BigQuery projects. The fallback keeps |
Query Results ( | Static schema discovery is unavailable. Use | Query Results creates its SQLite tables dynamically from saved query results, so there is no fixed table or column list for |
Other schema-capable data sources | Stream | The MCP server retains only the requested page instead of the complete Redash response. |
Parameters: dataSourceId (required), page (default 1), pageSize (default 25,
max 100), and search (optional case-insensitive substring match on table names;
pagination applies to the filtered set). The response includes hasMore and
nextPage for iterating through large schemas.
For example, to inspect tables in a BigQuery dataset named analytics_public
on data source 7, call get_schema with
{"dataSourceId":7,"pageSize":10,"search":"analytics_public."}. pageSize
limits the number of tables in one response; it does not split the columns or
nested field paths within a table. A wide table such as a GA4 event export is
therefore returned with all of its field paths even when pageSize is 1.
Dashboard Management
list_dashboards: List all available dashboardsget_dashboard: Get dashboard details and visualizationsget_dashboard_layout: Inspect widget positions, sizes, and visibility on a dashboardget_visualization: Get details of a specific visualizationget_dashboard_parameters: Inspect dashboard parameter values and widget mappingsupdate_dashboard_parameters: Update dashboard parameter values and orderupdate_dashboard_layout: Move or resize multiple widgets in one callupdate_widget_layout: Move or resize a single widgetget_widget_parameter_mappings: Inspect a widget's parameter mappingsupdate_widget_parameter_mappings: Update a widget's parameter mappings
Visualization Management
create_visualization: Create a new visualization for a queryupdate_visualization: Update an existing visualizationupdate_chart_visualization: Patch chart-specific options likeglobalSeriesType,columnMapping,seriesOptions,legend, and axis settingsdelete_visualization: Delete a visualization
Development
Run in development mode:
pnpm run devTesting
Unit Tests
pnpm testE2E Tests
pnpm run e2e:testE2E tests use these default values (can be overridden with environment variables):
REDASH_URL: https://demo.redash.ioREDASH_API_KEY: test_api_key
Override example:
REDASH_URL=https://your-instance.com REDASH_API_KEY=your_key pnpm run e2e:testManual Testing
pnpm run inspectorVersion History
v1.1.0: Added query management functionality (create, update, archive)
v1.0.0: Initial release
Maintainers
Available Tools
67 toolsadd_alert_subscriptionB
Subscribe to an alert to receive notifications
Inputs: alertId (required), destination_id.
add_dashboard_favoriteB
Add a dashboard to favorites
Inputs: dashboardId (required).
add_query_favoriteB
Add a query to favorites
Inputs: queryId (required).
archive_dashboardB
Archive (soft-delete) a dashboard in Redash
Inputs: dashboardId (required).
archive_queryA
Archive (soft-delete) a query in Redash
Inputs: queryId (required).
create_alertB
Create a new alert in Redash. Alerts notify you when a query result meets a specified condition.
Inputs: name (required), options (required), query_id (required), rearm.
create_dashboardB
Create a new dashboard in Redash
Inputs: name (required), tags.
create_queryC
Create a new query in Redash
Inputs: name (required), query (required), data_source_id (required), tags, +3 more.
create_query_snippetA
Create a new reusable query snippet
Inputs: snippet (required), trigger (required), description.
create_visualizationB
Create a new visualization for a query
Inputs: name (required), type (required), options (required), query_id (required), +1 more.
create_widgetB
Create a new widget on a dashboard
Inputs: width (required), dashboard_id (required), text, options, +2 more.
delete_alertB
Delete an alert from Redash
Inputs: alertId (required).
delete_query_snippetC
Delete a query snippet
Inputs: snippetId (required).
delete_visualizationB
Delete a visualization
Inputs: visualizationId (required).
delete_widgetB
Delete a widget from a dashboard
Inputs: widgetId (required).
execute_adhoc_queryA
Execute an ad-hoc query without saving it to Redash. Creates a temporary query that is automatically deleted after execution.
Inputs: query (required), dataSourceId (required).
execute_parameterized_queryB
Execute a saved parameterized query using its saved parameter definitions and defaults
Inputs: queryId (required), maxAge, parameters, useSavedDefaults.
execute_queryC
Execute a Redash query and return results
Inputs: queryId (required), maxAge, parameters.
fork_dashboardB
Fork (duplicate) an existing dashboard
Inputs: dashboardId (required).
fork_queryB
Fork (duplicate) an existing query
Inputs: queryId (required).
get_alertB
Get details of a specific alert
Inputs: alertId (required).
get_alert_subscriptionsA
Get all subscriptions for an alert
Inputs: alertId (required).
get_dashboardA
Get details of a specific dashboard
Inputs: dashboardId (required).
get_dashboard_by_slugB
Get details of a specific dashboard by its slug
Inputs: slug (required).
get_dashboard_layoutB
Get the current widget layout for a dashboard
Inputs: dashboardId (required).
get_dashboard_parametersA
Get the current dashboard parameter values and widget mappings
Inputs: dashboardId (required).
get_dashboard_tagsA
Get all tags used in dashboards
Inputs: no named parameters.
get_favorite_dashboardsB
Get dashboards marked as favorite by the current user
Inputs: page, pageSize.
get_favorite_queriesB
Get queries marked as favorite by the current user
Inputs: page, pageSize.
get_my_dashboardsA
Get dashboards created by the current user
Inputs: page, pageSize.
get_my_queriesA
Get queries created by the current user
Inputs: page, pageSize.
get_public_dashboardC
Get a public dashboard by its share token
Inputs: token (required).
get_queryB
Get details of a specific query
Inputs: queryId (required).
get_query_parametersA
Get the saved parameter definitions for a query
Inputs: queryId (required).
get_query_results_csvA
Get query results in CSV format. Returns the last cached results, or optionally refreshes the query first to get the latest data. Note: Does not support parameterized queries.
Inputs: queryId (required), refresh.
get_query_snippetA
Get details of a specific query snippet
Inputs: snippetId (required).
get_query_tagsA
Get all tags used in queries
Inputs: no named parameters.
get_recent_queriesC
Get recently accessed queries
Inputs: page, pageSize.
get_schemaC
Get schema of a specific data source
Inputs: dataSourceId (required).
get_visualizationB
Get details of a specific visualization
Inputs: visualizationId (required).
get_widgetC
Get details of a specific widget
Inputs: widgetId (required).
get_widget_parameter_mappingsB
Get the parameter mappings for a widget
Inputs: widgetId (required).
list_alertsB
List all alerts in Redash
Inputs: no named parameters.
list_dashboardsC
List all available dashboards in Redash
Inputs: page, pageSize.
list_data_sourcesA
List all available data sources in Redash
Inputs: no named parameters.
list_destinationsA
List all alert notification destinations (email, Slack, etc.)
Inputs: no named parameters.
list_queriesC
List all available queries in Redash
Inputs: q, page, pageSize.
list_query_snippetsA
List all reusable query snippets
Inputs: no named parameters.
list_widgetsA
List all widgets
Inputs: no named parameters.
mute_alertB
Mute an alert to temporarily stop notifications
Inputs: alertId (required).
remove_alert_subscriptionC
Unsubscribe from an alert
Inputs: alertId (required), subscriptionId (required).
remove_dashboard_favoriteB
Remove a dashboard from favorites
Inputs: dashboardId (required).
remove_query_favoriteA
Remove a query from favorites
Inputs: queryId (required).
update_alertB
Update an existing alert in Redash
Inputs: alertId (required), name, rearm, options, +1 more.
update_chart_visualizationB
Update chart-specific visualization options and merge them with the current Redash chart config by default
Inputs: visualizationId (required), name, type, sortX, +32 more.
update_dashboardC
Update an existing dashboard in Redash
Inputs: dashboardId (required), name, tags, is_draft, +2 more.
update_dashboard_layoutA
Move or resize multiple widgets on a dashboard in one call and report per-widget outcomes
Inputs: widgets (required), dashboardId (required).
update_dashboard_parametersB
Update dashboard parameter values and ordering
Inputs: dashboardId (required), parameters, globalParamOrder, replaceParameters, +1 more.
update_queryC
Update an existing query in Redash
Inputs: queryId (required), name, tags, query, +6 more.
update_query_parametersB
Update a query's saved parameter definitions
Inputs: queryId (required), parameters, replaceParameters, removeParameterNames.
update_query_snippetC
Update an existing query snippet
Inputs: snippetId (required), snippet, trigger, description.
update_visualizationC
Update an existing visualization
Inputs: visualizationId (required), name, type, options, +1 more.
update_widgetC
Update an existing widget
Inputs: widgetId (required), text, width, options, +2 more.
update_widget_layoutC
Move or resize a single widget by updating its grid position
Inputs: position (required), widgetId (required).
update_widget_parameter_mappingsB
Update a widget's parameter mappings
Inputs: widgetId (required), parameterMappings, removeParameterNames, replaceParameterMappings.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 67 tools
Each tool targets a specific resource and action, with clear distinctions even among similar operations (e.g., execute_query vs execute_adhoc_query). The descriptions further clarify any potential overlap.
All tools follow a consistent verb_noun snake_case pattern (e.g., create_dashboard, get_query, delete_alert). No mixing of conventions or vague names.
67 tools is high but appropriate for a comprehensive BI tool covering alerts, dashboards, queries, visualizations, widgets, snippets, data sources, and destinations. Each entity has a logical set of CRUD and utility tools.
The tool surface covers core workflows for alerts, dashboards, queries, and visualizations. Missing update/delete for data sources and destinations, but these are likely admin-level operations. Otherwise, no significant gaps.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP-compatible server that enables AI assistants to interact with Lightdash analytics data, providing tools to list and retrieve projects, spaces, charts, dashboards, and metrics through a standardized interface.1365 npm27MIT
- AlicenseAqualityDmaintenanceModel Context Protocol (MCP) server for Redash - manage queries, dashboards, and visualizations through AI assistants like Claude.699 PyPIMIT
- AlicenseAqualityBmaintenanceMCP server that connects Redash to Claude AI, enabling natural language data queries, dashboard management, and SQL execution.251,462 npm1MIT
- AlicenseAqualityDmaintenanceA Model Context Protocol (MCP) server for Tableau Server. Enables AI assistants to interact with Tableau workbooks, views, datasources, and metadata.24MIT