What can you do with this server?

This server is a read-only MCP wrapper for the Redash REST API (with the exception of saved query execution). Its capabilities include: * List & Search Queries (list_queries): Browse or full-text search saved queries with pagination support. * Get Query Details (get_query): Retrieve detailed information about a specific query by ID (API keys are automatically redacted for security). * Execute Saved Queries (execute_query): Run a saved query by ID, optionally passing parameters and controlling cache behavior via max_age; returns row data up to a configurable limit. * List Data Sources (list_data_sources): Retrieve all available Redash data sources. * Inspect Data Source Schema (get_data_source_schema): Fetch the schema (tables and columns) for a specific data source by ID. * List & Search Dashboards (list_dashboards): Browse or search dashboards with pagination support. * Get Dashboard Details (get_dashboard): Retrieve full details of a dashboard — including its widget configuration — using either its numeric ID or slug.

Which integrations are available for this server?

Provides read-only access to Redash REST API, including listing and searching queries, retrieving query details, executing saved queries with parameters, listing data sources and their schemas, and listing/retrieving dashboards.

How do I use redash-mcp?

1. Click on "Install 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 list my queries" 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

by oceandepthz

Overview Schema Related Servers Score Discussions

Python

Remote

redash-mcp

Redash REST API を読み取り専用でラップする MCP サーバ。唯一の例外として保存済みクエリの実行（POST /api/queries/{id}/results）のみ許可する。

ツール

list_queries(q?, page, page_size) — クエリ一覧・検索
get_query(query_id) — クエリ詳細（api_key は秘匿）
execute_query(query_id, parameters?, max_age) — クエリ実行 → 行データ
list_data_sources() — データソース一覧
get_data_source_schema(data_source_id) — スキーマ
list_dashboards(q?, page, page_size) — ダッシュボード一覧・検索
get_dashboard(identifier) — ダッシュボード詳細（id または slug）

Related MCP server: redash-mcp

設定（環境変数）

変数	必須	既定(プロセス)	用途
`REDASH_URL`	✅	—	例 `http://redash`。常にサーバサイド。
`REDASH_API_KEY`	stdioで必須	—	既定APIキー。HTTPは`X-REDASH-API-KEY`で上書き可。
`REDASH_MCP_TRANSPORT`		`stdio`	`stdio` / `streamable-http`。CLI `--transport`。
`REDASH_MCP_HOST`		`127.0.0.1`	http バインドホスト。CLI `--host`。
`REDASH_MCP_PORT`		`8000`	http ポート。CLI `--port`。
`REDASH_MCP_ALLOWED_HOSTS`		（なし）	許可 `Host`（カンマ区切り）。ポートは含めない（例 `redash-mcp,localhost`）。照合時にポートは無視される。
`REDASH_TIMEOUT`		`30`	HTTP タイムアウト秒
`REDASH_POLL_TIMEOUT`		`60`	ジョブ待機の上限秒
`REDASH_MAX_ROWS`		`1000`	返却行数の上限

実行

ローカル（uv）:

uv run redash-mcp                                             # stdio
uv run redash-mcp --transport streamable-http --host 127.0.0.1 --port 8000

Docker（既定で streamable-http / 0.0.0.0:8000）:

docker run --rm -p 8000:8000 \
  -e REDASH_URL=http://redash -e REDASH_API_KEY=xxxx redash-mcp

streamable-http でネットワーク公開する場合は DNS リバインディング対策として REDASH_MCP_ALLOWED_HOSTS を設定することを推奨。

LibreChat 連携

各ユーザーが自分の Redash API キーを持てる（X-REDASH-API-KEY ヘッダ）。 REDASH_URL はサーバ側で固定し、REDASH_API_KEY（サーバ既定キー）は設定しない。各リクエストの X-REDASH-API-KEY ヘッダを実効キーとする。

1. LibreChat の mcpServers 設定

redash:
  type: "streamable-http"
  url: "http://redash-mcp:8000/mcp"
  headers:
    X-REDASH-API-KEY: "{{REDASH_API_KEY}}"
  customUserVars:
    REDASH_API_KEY:
      title: "Redash API Key"
      description: "Redash の [ユーザー設定] から発行した API キー"

2. docker-compose（LibreChat と同一ネットワークに接続）

コンテナは LibreChat と同じ Docker ネットワークに置き、REDASH_MCP_ALLOWED_HOSTS で許可 Host を絞る。ホストへのポート公開は不要（LibreChat から内部ネットワーク経由で http://redash-mcp:8000/mcp に接続する）。

services:
  redash-mcp:
    image: redash-mcp
    build: .
    environment:
      REDASH_URL: http://redash
      REDASH_MCP_ALLOWED_HOSTS: "redash-mcp"
      # REDASH_API_KEY は設定しない（各ユーザーが X-REDASH-API-KEY ヘッダで供給）
    networks:
      - librechat_default

networks:
  librechat_default:
    external: true

スタンドアロン（LibreChat を使わない）構成は docker-compose.example.yml を参照。

開発

uv sync
uv run pytest

Available Tools

7 tools

execute_queryB

保存済みクエリを実行し行データを返す。max_age=0でキャッシュ回避。

ParametersJSON Schema

Name	Required	Description	Default
`max_age`	No
`query_id`	Yes
`parameters`	No

TDQS

B3.4/5.0

Behavior3/5

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

Without annotations, the description partially covers behavior: it returns row data and describes cache avoidance. However, it does not disclose potential side effects (e.g., if queries modify data), authentication needs, or error handling.

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

Conciseness4/5

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

The description is very concise, consisting of a single sentence that conveys the core action and a key parameter usage. No unnecessary words, but could be expanded slightly for clarity.

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 lack of output schema and three parameters, the description is incomplete. It mentions returning row data but no format, and only addresses max_age. Missing details on query_id, parameters usage, error conditions, and permissions.

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

Parameters2/5

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

With 0% schema description coverage, the description only adds meaning for the max_age parameter (cache avoidance). The required query_id and optional parameters are not explained, leaving the agent to infer from names alone.

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

Purpose5/5

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

The description clearly states the tool executes a saved query and returns row data, with explicit mention of cache avoidance via max_age=0. This distinguishes it from sibling tools which focus on listing or retrieving metadata.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives is provided. The cache avoidance hint offers some context, but there is no mention of prerequisites or when not to use it.

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

get_dashboardC

ダッシュボード1件（id または slug）。ウィジェット構成を含む。

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions returns widget configuration, but lacks information on permissions, error cases, or response format.

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

Conciseness3/5

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

Single sentence, concise but minimal. No structure like bullet points or separate sections. Adequate for a simple tool.

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 one required param, no output schema, and no annotations, the description is marginally complete. It explains what the tool returns but lacks details on response format and potential errors.

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 has 0% coverage for identifier parameter. Description adds that identifier can be id or slug, which is essential meaning beyond the schema. Could still add format examples.

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 it retrieves a single dashboard by identifier, optionally including widget configuration. It implicitly distinguishes from list_dashboards (list) and get_query (different resource).

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 on when to use this tool vs alternatives like execute_query or list_dashboards. Sibling tools exist but no explicit when-to-use or when-not-to-use.

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

get_data_source_schemaC

データソースのスキーマ（テーブル・カラム）。

ParametersJSON Schema

Name	Required	Description	Default
`data_source_id`	Yes

TDQS

C2.4/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 traits. It only states the tool 'gets' schema, but does not disclose whether it is read-only, how to interpret results, or any side effects. Minimal disclosure.

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

Conciseness3/5

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

The description is very short (one sentence) with no wasted words. However, it is under-specified for the tool's purpose. Conciseness should not sacrifice completeness; here it veers toward insufficient information.

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

Completeness1/5

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

Given the tool has one required parameter, no output schema, and no annotations, the description fails to provide necessary context such as return format, expected input, or usage notes. It is severely incomplete.

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

Parameters1/5

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

Schema description coverage is 0%, so description must add meaning. It does not explain what 'data_source_id' refers to, how to find it, or its format. The description adds no value beyond the parameter name.

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 that it gets the schema (tables, columns) of a data source. The verb 'get' and resource 'data_source_schema' are specific. While it distinguishes from siblings like 'get_dashboard' or 'list_data_sources', it does not explicitly differentiate from similar schema-related tools.

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 on when to use this tool versus alternatives. There is no description of context, prerequisites, or exclusions. The agent is given no help in selecting this tool over siblings.

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

get_queryC

指定IDのクエリ詳細（api_keyは秘匿済み）。

ParametersJSON Schema

Name	Required	Description	Default
`query_id`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It only reveals that api_key is hidden in the output, but lacks details on read-only nature, authentication requirements, or rate limits.

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

Conciseness3/5

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

The description is a single sentence with no wasted words, but it is too brief to be fully effective for an agent. It lacks structure like separation of concerns.

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 one parameter and no output schema, the description is incomplete: it omits parameter details, output format example, and use cases. The agent lacks sufficient context to invoke correctly.

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

Parameters2/5

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

Schema description coverage is 0%, yet the description does not explain the query_id parameter (e.g., how to obtain it or its semantics). It only mentions output redaction, not parameter meaning.

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 tool retrieves query details for a specified ID, with a note that the API key is hidden. This is a specific verb and resource, and it implicitly distinguishes from siblings like execute_query which runs queries.

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 (e.g., execute_query, list_queries). No prerequisites or context for invocation are given.

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

list_dashboardsC

ダッシュボード一覧・検索。

ParametersJSON Schema

Name	Required	Description	Default
`q`	No
`page`	No
`page_size`	No

TDQS

C2/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits like pagination, rate limits, or destructive actions. The input schema implies pagination via page/page_size, but the description does not confirm this.

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

Conciseness2/5

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

The description is extremely short (one sentence), but it is under-specified and fails to provide necessary information. Conciseness should not sacrifice completeness.

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

Completeness1/5

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

For a tool with 3 parameters and no output schema or annotations, the description is grossly incomplete. It does not explain how to use the search parameter, pagination, or what the output contains.

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

Parameters1/5

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

Schema coverage is 0% with no parameter descriptions. The description does not add any meaning to the parameters (q, page, page_size), leaving the agent to infer from parameter names alone.

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

Purpose3/5

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

The description states 'Dashboard list/search', which is a specific verb+resource, but it is vague and does not distinguish from sibling tools like get_dashboard or list_data_sources. It lacks detail about the scope of listing or search behavior.

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 on when to use this tool vs alternatives such as get_dashboard. The description does not mention prerequisites or context for usage.

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

list_data_sourcesC

データソース一覧。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided and description only says 'list,' which implies a read operation. No disclosure of pagination, filtering, or potential limitations. For a simple list tool, more transparency on scope or ordering would help.

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?

Single sentence, extremely concise. All information is front-loaded, no filler.

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?

With no output schema, no annotations, and a minimal description, the tool is contextually incomplete. It doesn't explain what properties of data sources are returned or how to interpret the list.

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?

No parameters exist, so schema coverage is 100% but trivial. Description adds no meaning beyond the name; baseline is 4 but since no value is added, 3 is appropriate.

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?

Description 'Data source list.' clearly indicates the tool lists data sources. It distinguishes from siblings like get_data_source_schema which operates on a single source. However, it essentially restates the name without adding nuance.

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 on when to use this tool versus alternatives like list_dashboards or get_data_source_schema. The description provides no context for selection.

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

list_queriesB

クエリ一覧・検索。qで全文検索、page/page_sizeでページング。

ParametersJSON Schema

Name	Required	Description	Default
`q`	No
`page`	No
`page_size`	No

TDQS

B3.2/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 discloses search and paging behavior. It omits details like authentication requirements, read-only nature, response format, or any side effects.

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, well-structured Japanese sentence that immediately states the core purpose and parameter roles, with no wasted words.

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, no output schema, and minimal schema descriptions, the description is too brief. It lacks information on return values, error handling, pagination details, or any prerequisites for using the tool.

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 parameter coverage is 0%. The description adds basic meaning: 'q' is full-text search, 'page' and 'page_size' for paging. However, it lacks details like matching rules, default values, or format constraints, so compensation is partial.

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

Purpose5/5

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

The description clearly states 'クエリ一覧・検索' (query list/search) and specifies full-text search and paging, effectively distinguishing from sibling tools like execute_query, get_query, list_dashboards, etc., by resource and action.

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 explicit guidance on when to use this tool versus alternatives (e.g., get_query for a single query, execute_query for running). Usage is only implied by the name and parameter hints.

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. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 14, 2026
- First observedexecute_query
- First observedget_dashboard
- First observedget_data_source_schema
- First observedget_query
- First observedlist_dashboards
- First observedlist_data_sources
- First observedlist_queries

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: queries (execute vs. get details vs. list), dashboards (get vs. list), and data sources (list vs. get schema). No overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., execute_query, get_dashboard, list_queries), with uniform use of snake_case.

Tool Count5/5

Seven tools is appropriate for a Redash MCP server, covering essential read and list operations without unnecessary bloat.

Completeness2/5

The tool set lacks any create, update, or delete operations for queries, dashboards, or data sources, leaving significant gaps in lifecycle management. An agent cannot create or modify resources.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292
apis-io B
io.apis
Read-only MCP server over the APIs.io catalog — discover APIs, providers, tags & artifacts.
Search Developer Tools Documentation Access
1332

Related MCP Servers

Redash MCP Server
Databases Search Developer Tools
suthio
A
license
B
quality
A
maintenance
Model Context Protocol (MCP) server that integrates Redash with AI assistants like Claude, allowing them to query data, manage visualizations, and interact with dashboards through natural language.
Updated 2 days ago (2026-09-04 14:03 UTC)
67
2,857
101
MIT
redash-mcp
Data Visualization Data Platforms
wise-toddler
A
license
A
quality
B
maintenance
Model Context Protocol (MCP) server for Redash - manage queries, dashboards, and visualizations through AI assistants like Claude.
Updated 2 months ago (2026-07-14 11:00 UTC)
6
MIT
sql-explorer-mcp
Databases Search
govern-agents
A
license
Not graded
quality
F
maintenance
Read-only MCP server for SQL databases (SQL Server, Postgres, SQLite) with multi-server support and three-layer safety using AST validation and linting.
Updated a month ago (2026-07-29 13:07 UTC)
MIT
mcp-for-redash
Data Platforms Databases Developer Tools
Ashuqwe
A
license
Not graded
quality
D
maintenance
MCP server that connects AI assistants to Redash, enabling listing of assets, read-only query execution, dashboard inspection, and alert management through the Redash API.
Updated 5 months ago (2026-03-23 10:06 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/oceandepthz/redash-api-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server