DB-MCP provides governed AI access to databases through the Model Context Protocol, enabling AI assistants to safely discover and query your data.
Search the data catalog (catalog.search): Discover available measures, dimensions, and segments by keyword; filter by cube names or member types; control result count up to 50 items
Describe catalog members (catalog.describe): Get detailed definitions, types, and related members for specific data elements (e.g., Orders.count)
Execute governed semantic queries (query.semantic): Run queries with support for measures, dimensions, time dimensions (with granularity and date ranges), filters, segments, sorting, and pagination — all automatically validated against governance policies
Connect supported databases: PostgreSQL, MySQL, BigQuery, Snowflake, Redshift, and ClickHouse
Define semantic models (cubes): Map database tables to queryable measures (count, sum, avg) and dimensions (string, number, time) via YAML definitions
Implement data governance: PII protection, member exposure controls, query/row limits, group-by restrictions, default filters, and segments
Integrate with AI assistants: Expose MCP endpoints to clients like Claude Desktop or Cursor, or use the built-in AI chat (requires Anthropic API key)
Manage via admin UI: Add databases, generate cubes, configure governance, and monitor connections
Provides governed access to ClickHouse databases, allowing AI agents to search data catalogs, describe table schemas, and execute semantic queries.
Provides governed access to MySQL databases, allowing AI agents to search data catalogs, describe table schemas, and execute semantic queries.
Provides governed access to PostgreSQL databases, allowing AI agents to search data catalogs, describe table schemas, and execute semantic queries.
Provides governed access to Snowflake data warehouses, allowing AI agents to search data catalogs, describe table schemas, and execute semantic queries.
Click on "Install 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., "@DB-MCP What was the total revenue by region for the last quarter?"
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.
Give AI assistants governed access to your databases through the Model Context Protocol. Connect any supported database, define governance rules, and let AI query your data safely.
Supported databases: PostgreSQL, MySQL, BigQuery, Snowflake, Redshift, ClickHouse
git clone https://github.com/syam/db-mcp.git
cd db-mcp
docker compose upOpen http://localhost:3000 and click Try with Demo Data
The demo sets up a sample e-commerce database with cubes and governance rules pre-configured
Your MCP endpoint is live at http://localhost:3000/mcp/default
Add to Claude Desktop (Settings > MCP Servers):
{
"mcpServers": {
"db-mcp": {
"url": "http://localhost:3000/mcp/default"
}
}
}git clone https://github.com/syam/db-mcp.git
cd db-mcp
cp .env.example .env # optionally set ANTHROPIC_API_KEY for AI chat
docker compose upOpen http://localhost:3000 and click Add Database
Fill in the connection form and click Test Connection to verify
Generate cubes — go to the Tables page, click Generate All Cubes (or generate per-table). This creates the YAML definitions that tell the semantic layer what's queryable.
Configure governance (optional) — go to the Governance page to mark PII fields, control member exposure, and set query restrictions
Your MCP endpoint is live at http://localhost:3000/mcp/{your-database-id}
Important: Without generating cubes (step 3), MCP tools will return no data. The semantic layer automatically picks up new and changed cube files — no restart needed.
Related MCP server: Metabase MCP Plus
Your Database → Cube Definitions (YAML) → Semantic Layer → Governance Rules → MCP Tools → AI AssistantCube definitions map your database tables into queryable measures and dimensions
Governance rules control which members AI can access (PII blocking, exposure, query limits)
MCP tools expose the governed semantic layer to any MCP-compatible AI assistant
Cubes are YAML files that define what AI can query. Each cube maps a database table to typed measures (aggregations) and dimensions (attributes).
Location: data/databases/{id}/cube/model/cubes/*.yml
How to create: Use the Tables page in the admin UI and click Generate All Cubes. If you have ANTHROPIC_API_KEY set, the generator will add rich descriptions to help AI understand your data. You can also write cube YAML manually.
Example:
cubes:
- name: orders
sql_table: orders
measures:
- name: count
type: count
- name: total_amount
type: sum
sql: "{CUBE}.amount"
dimensions:
- name: status
sql: "{CUBE}.status"
type: string
- name: created_at
sql: "{CUBE}.created_at"
type: timeSupported measure types: count, sum, avg, min, max, count_distinct
Supported dimension types: string, number, time, boolean
The semantic layer automatically detects new and changed cube files — no restart needed.
Governance controls which members AI can access and how. Configure via the Governance page in the admin UI, or edit data/databases/{id}/agent_catalog.yaml directly.
Example:
version: "1.0"
defaults:
exposed: true
pii: false
members:
Users.email:
exposed: false
pii: true
Orders.total_amount:
allowedGroupBy:
- Orders.status
- Orders.created_atFeatures:
PII Protection — Mark sensitive fields to block them from all queries
Member Exposure — Control which measures and dimensions are queryable
Query Limits — Enforce maximum row counts per query
Group-by Restrictions — Limit which dimensions can be used for grouping
Default Filters — Automatically apply security filters (e.g., tenant isolation) to all queries
Default Segments — Apply pre-defined segments to all queries
Each database gets its own MCP endpoint at /mcp/{databaseId}.
Claude Desktop — Add to Settings > MCP Servers:
{
"mcpServers": {
"db-mcp": {
"url": "http://localhost:3000/mcp/default"
}
}
}Cursor / Other MCP Clients — Point to http://localhost:3000/mcp/{databaseId} as an HTTP MCP endpoint.
Built-in AI Chat — Set ANTHROPIC_API_KEY in your .env and use the Chat page in the admin UI to query your data conversationally.
Tool | Description |
| Search for measures, dimensions, and segments with fuzzy matching |
| Get detailed member information including governance status |
| Execute governed queries against the semantic layer |
For Docker, set these in your .env file or shell before running docker compose up:
Variable | Required | Purpose |
| Auto-set | JWT secret shared with Cube.js (default provided in docker-compose.yml) |
| No | Enable AI chat and LLM-enhanced cube generation |
| No | Encrypt stored database credentials with AES-256-GCM (min 32 chars) |
Copy .env.example to .env to see all available variables.
For contributors working on db-mcp itself:
# Start infrastructure with exposed ports
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d postgres cube
# Install dependencies
npm install
# Copy and edit env file
cp .env.example .env
# Start backend (port 3000)
npm run dev
# Start frontend (port 3001, in another terminal)
cd admin/frontend && npm install && npm run devnpm run test # Run tests
npm run lint # Lint
npm run build # Build for production
npx playwright test # E2E testsSee docs/architecture.md for detailed architecture, API reference, and troubleshooting.
localhost:3000 (nginx)
├── /api/* Admin REST API
├── /mcp/:id MCP endpoints (Streamable HTTP + SSE)
├── /health Health check
└── /* Admin UI (React SPA)
│
▼
Express Backend
│
▼
Semantic Layer (Cube.js)
│
▼
Your DatabasesMIT
Get detailed information about a specific member including its definition, type, and related members.
| Name | Required | Description | Default |
|---|---|---|---|
| member | Yes | Full member name (e.g., "Orders.count") |
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 describes a read operation ('Get detailed information'), which implies it is likely non-destructive, but does not address other traits such as authentication requirements, rate limits, error handling, or what happens if the member does not exist. This leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key details without unnecessary words. It is front-loaded with the main action and resource, making it easy to understand quickly. However, it could be slightly more concise by avoiding minor redundancy (e.g., 'detailed information' might imply 'definition, type, and related members').
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 retrieving detailed member information, the description is incomplete. With no annotations and no output schema, it fails to explain critical aspects such as the format of returned information, potential errors, or any limitations. The description alone does not provide enough context for an agent to fully understand how to use the tool effectively.
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 100% description coverage, with the single parameter 'member' documented as 'Full member name (e.g., "Orders.count")'. The description does not add any additional meaning beyond this, such as format constraints or examples beyond the schema. Given the high schema coverage, the baseline score of 3 is appropriate.
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 tool's purpose with a specific verb ('Get detailed information') and resource ('a specific member'), and specifies what information is retrieved ('definition, type, and related members'). However, it does not explicitly differentiate from sibling tools like catalog.search, which might also retrieve member information but with different scope or filtering.
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 implies usage when detailed information about a specific member is needed, but it does not provide explicit guidance on when to use this tool versus alternatives like catalog.search or query.semantic. No exclusions or prerequisites are mentioned, leaving the context somewhat open-ended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the data catalog for available measures, dimensions, and segments. Use this to discover what data is available for querying.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for finding members | |
| types | No | Filter by member types | |
| cubes | No | Filter by cube names | |
| limit | No | Maximum results (default: 10, max: 50) |
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 mentions the tool is for 'searching' and 'discovery,' which suggests a read-only operation, but it doesn't detail behavioral traits such as rate limits, authentication needs, pagination, or what happens on errors. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 concise and front-loaded, consisting of two sentences that directly state the purpose and usage. There's no unnecessary information or redundancy. However, it could be slightly more structured by explicitly separating purpose from guidelines, but it's efficient overall.
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 tool's complexity (a search function with 4 parameters), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and usage but lacks details on behavioral aspects, output format, and sibling tool differentiation. It's adequate as a minimum viable description but has clear gaps in providing full context for effective tool use.
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 100% description coverage, so the schema already documents all parameters (query, types, cubes, limit) with details like default values and enums. The description adds no additional parameter semantics beyond what's in the schema, such as examples or usage tips. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
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 tool's purpose: 'Search the data catalog for available measures, dimensions, and segments.' It specifies the verb ('search') and resource ('data catalog'), and mentions the target objects. However, it doesn't explicitly distinguish this from sibling tools like 'catalog.describe' or 'query.semantic', which prevents a score of 5.
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 some usage context: 'Use this to discover what data is available for querying.' This implies when to use the tool (for discovery), but it doesn't offer explicit guidance on when to choose this over alternatives like 'catalog.describe' or 'query.semantic', nor does it mention exclusions or prerequisites. The guidance is implied rather than comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a governed semantic query against the data warehouse. Queries are validated against governance policies before execution.
| Name | Required | Description | Default |
|---|---|---|---|
| measures | No | Measures to query | |
| dimensions | No | Dimensions for grouping | |
| timeDimensions | No | Time dimensions with optional granularity and date range | |
| filters | No | Filter conditions | |
| segments | No | Segments to apply | |
| order | No | Sort order | |
| limit | Yes | Maximum rows to return (required) | |
| offset | No | Number of rows to skip |
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 governance validation, which hints at potential restrictions or errors, but lacks details on execution behavior (e.g., performance, rate limits, error handling, or output format). For a complex query tool with 8 parameters, 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 two sentences, front-loaded with the core purpose and followed by a key behavioral note (governance validation). Every sentence earns its place by providing essential information without redundancy or fluff, making it highly efficient.
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 tool's complexity (8 parameters, no output schema, and no annotations), the description is incomplete. It lacks details on what the query returns, how results are structured, error conditions, or governance specifics. For a data query tool, this leaves critical gaps for an AI agent to understand and use it effectively.
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 100%, meaning all parameters are documented in the input schema. The description adds no additional meaning beyond the schema, such as examples or usage context for parameters like measures or dimensions. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 governed semantic query') and target ('against the data warehouse'), with the verb 'execute' being specific. However, it doesn't differentiate from sibling tools like catalog.describe or catalog.search, which likely serve different purposes (e.g., metadata exploration vs. data querying).
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 mentions that 'queries are validated against governance policies before execution,' which implies a context of compliance or security. However, it provides no explicit guidance on when to use this tool versus alternatives like catalog.describe or catalog.search, nor does it specify 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0catalog.describecatalog.searchquery.semanticEach tool has a clearly distinct purpose with no overlap: catalog.describe provides detailed metadata about a specific member, catalog.search enables discovery of available data elements, and query.semantic executes governed queries. The descriptions clearly differentiate between metadata lookup, discovery, and query execution functions.
All tools follow a consistent dot-separated naming pattern (catalog.describe, catalog.search, query.semantic) with clear verb-noun combinations. The naming convention is uniform throughout the set, making it easy to understand the tool hierarchy and relationships.
With only 3 tools, the set feels somewhat thin for a database/warehouse MCP server. While the tools cover key functions (metadata, discovery, querying), typical database interfaces would include more operations like data modification, schema management, or connection handling. The count is borderline minimal but functional.
The tools cover discovery (search), metadata inspection (describe), and query execution, but there are notable gaps for a complete database interface. Missing are data modification operations (insert/update/delete), schema management tools, connection/configuration management, and monitoring/debugging capabilities. The surface enables read operations but lacks write capabilities.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/scrappymonkey/db-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
