This server is an MCP interface for Metabase supporting read, write, and AI-augmented operations, with flexible server modes (read, write, or full).
Read Content: List and retrieve dashboards, cards/questions, databases, schemas, and collections; search across all content types.
Execute Queries: Run existing Metabase cards (with optional parameters) or ad-hoc SQL SELECT statements, with injection and DDL/DML guardrails.
Write Operations (write/full mode): Create, update, and delete cards, dashboards, and collections; add/remove cards from dashboards; move content between collections.
Batch Execution: Perform multiple read operations concurrently in a single request.
Workflow Pipelines: Chain sequential operations where outputs from one step feed into subsequent steps.
Natural Language to SQL (requires Anthropic API key): Translate natural language into SQL, and explain, optimize, or validate queries before execution.
AI-Generated Insights (full mode + Anthropic API key): Auto-generate insights, trend analysis, and metric comparisons from query results.
Security & Governance: SQL injection guardrails, tiered rate limiting (read/write/LLM), and detailed audit logging with risk assessment.
Provides tools for interacting with Metabase's API, enabling AI agents to query databases, manage dashboards and cards, execute SQL queries with safety guardrails, and perform natural language to SQL conversion for data analysis.
The headless, AI-augmented MCP server for Metabase — API-key auth that works for agents, CI, and VPN'd self-hosted instances, with AI insights, production security controls, and support for any Metabase version.
Metabase ships an official MCP server (v0.60+), and since v0.61/v0.62 it covers both read and write operations — creating and updating questions, dashboards, and collections, plus raw SQL execution. It's good, and if it fits your setup you should consider it.
This server exists for the setups it doesn't fit:
Headless / agent use. The official server's MCP endpoint is OAuth-only, which requires a browser flow and a reachable HTTPS instance. (Metabase's underlying Agent API does accept API keys — but that capability isn't exposed over MCP.) This server authenticates with a Metabase API key over MCP — it works in CI, in autonomous agents, and on self-hosted instances behind a VPN.
AI inside the server. NLQ-to-SQL, SQL explain/optimize/validate, automated insights, and trend analysis run in the server with your own Anthropic key — independent of which AI client connects.
Operational control. In Metabase's own words, their MCP server "doesn't come with granular control over which tools people can use" (docs) — it's an instance-wide on/off switch. This server has read/write/full modes, per-tool allow/deny lists, SQL injection guardrails, tiered rate limits, and risk-scored audit logging of every operation.
Composition. batch_execute (up to 20 parallel ops) and run_workflow (chained steps with output references) have no official equivalent.
Any Metabase version — including pre-v0.60 instances that can't use the official MCP at all.
Capability | @ai-1luvc0d3/metabase-mcp | Metabase Official (v63) |
Read dashboards / cards / databases | ✅ | ✅ |
Create & update questions, dashboards, collections | ✅ | ✅ (v61+) |
Raw SQL execution | ✅ SELECT-only + guardrails | ✅ (v62+, needs native-query permission) |
Delete cards & dashboards | ✅ | ❌ (archive-only, via update) |
Add / remove cards on a dashboard | ✅ | ❌ |
Batch execution (parallel multi-op in one call) | ✅ | ❌ |
Workflow pipelines (chained steps with output references) | ✅ | ❌ |
NLQ → SQL + explain / optimize / validate (LLM in the server) | ✅ | ❌ (relies on the AI client) |
Automated insights & trend analysis | ✅ | ❌ |
Inline interactive charts rendered in the AI client | ❌ | ✅ (v62+) |
SQL injection guardrails | ✅ | permission-based |
Tiered rate limiting (read / write / LLM) | ✅ | blanket 1,000 req/min per user |
Per-operation audit logging with risk levels | ✅ | partial (Enterprise usage analytics; OAuth event log) |
Server modes / per-tool allow & deny lists | ✅ | ❌ (instance-wide on/off + an |
API-key auth over MCP (headless, CI, agents, VPN'd self-hosted) | ✅ | ❌ (MCP endpoint is OAuth browser flow only) |
OAuth per-user permission scoping | ❌ (API key) | ✅ |
Works on Metabase < v0.60 (no upgrade required) | ✅ | ❌ |
Use this if: you're running agents or CI that can't do an OAuth browser flow, your self-hosted Metabase isn't publicly reachable, you want AI-generated insights server-side, you need audit logs and rate limits, or you're on a Metabase version older than v0.60.
Use Metabase's official MCP if: you're on v62+, your instance is reachable for OAuth, and per-user permission scoping or inline interactive charts matter more to you than the above.
Several community Metabase MCP servers exist, some exposing far more of the raw REST API (90+ tools). This one makes a different trade: a curated tool surface with production controls. As of August 2026, it is the only Metabase MCP server — official or community — with SQL injection guardrails, tiered rate limiting, per-operation audit logging, and per-tool access control enforced inside batch and workflow calls. If you want maximum raw API coverage, one of the broad-CRUD servers may fit better; if an agent is going to touch your BI unattended, safety rails are the feature.
Related MCP server: Metabase MCP Server
30 tools across read, batch, workflow, write, NLQ, and insight categories
Batch execution -- run up to 20 operations in parallel in a single call (reads always; non-destructive writes in write/full mode)
Workflow pipelines -- chain tools sequentially with $stepName.path output references between steps, including write steps (e.g. create a card, then add it to a dashboard, in one call)
Compact responses by default -- all tools return compact JSON (~50% token reduction); opt into pretty-printing with format: "default"
Natural language to SQL -- ask questions, get SQL + results (powered by Claude)
SQL guardrails -- injection detection, DDL/DML blocking, dangerous pattern enforcement
Tiered rate limiting -- configurable per-minute limits for read, write, and LLM operations
Audit logging -- every operation logged with risk assessment
Three server modes -- read (safe default), write, or full (with AI insights)
Schema caching -- fast NLQ context for large databases
Download the latest metabase-mcp-*.mcpb from GitHub Releases
Double-click to install in Claude Desktop
Enter your Metabase URL and API key when prompted — stored securely in the OS keychain
npx @ai-1luvc0d3/metabase-mcpnpm install -g @ai-1luvc0d3/metabase-mcp
metabase-mcpgit clone https://github.com/1luvc0d3/metabase-mcp.git
cd metabase-mcp
npm install
npm run build
npm startSet environment variables or create a .env file (see .env.example):
Variable | Required | Default | Description |
| Yes | - | Your Metabase instance URL |
| Yes | - | Metabase API key |
| No |
| Server mode: |
| No | - | Enables NLQ and insight tools |
| No |
| Request timeout (ms) |
| No |
| Max rows returned per query |
| No |
| Logging: |
| No | - | Comma-separated allowlist — only these tools are exposed |
| No | - | Comma-separated denylist — these tools are never exposed (wins over allow) |
| No |
| Read-tier rate limit |
| No |
| Write-tier rate limit |
| No |
| LLM-tier rate limit |
| No | - | Legacy: sets the read tier when |
Server modes give coarse control (read / write / full); MCP_TOOLS_ALLOW and MCP_TOOLS_DENY refine it per tool. Denied tools are not registered with the MCP client at all, and the same policy is enforced on operations nested inside batch_execute and run_workflow — a denied tool can't be reached through a batch or pipeline. Deny always wins over allow.
# Expose read tools but never raw SQL
MCP_MODE=read
MCP_TOOLS_DENY=execute_queryGo to your Metabase instance
Navigate to Admin > Settings > API Keys
Click Create API Key
Copy the key and set it as METABASE_API_KEY
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"metabase": {
"command": "npx",
"args": ["@ai-1luvc0d3/metabase-mcp"],
"env": {
"METABASE_URL": "https://your-metabase.example.com",
"METABASE_API_KEY": "mb_your_api_key_here",
"MCP_MODE": "read"
}
}
}
}Mode | Tools | Description |
| 12 + NLQ | Read-only access, batch execution, and workflow pipelines |
| 22 + NLQ | Adds create/update/delete for cards, dashboards, collections |
| 30 | All tools including automated insights and trend analysis |
Read (always available)
list_dashboards, get_dashboard, list_cards, get_card, execute_card, list_databases, get_database_schema, execute_query, search_content, get_collections
Batch & Workflow (always available)
batch_execute, run_workflow
In write/full mode, both also accept the non-destructive write tools (create_card, update_card, create_dashboard, update_dashboard, add_card_to_dashboard, create_collection, move_to_collection). Delete/remove operations are never batchable — they must be explicit single tool calls.
Write (write/full modes)
create_card, update_card, delete_card, create_dashboard, update_dashboard, delete_dashboard, add_card_to_dashboard, remove_card_from_dashboard, create_collection, move_to_collection
NLQ (requires ANTHROPIC_API_KEY)
nlq_to_sql, explain_sql, optimize_sql, validate_sql
Insights (full mode + ANTHROPIC_API_KEY)
ask_data, generate_insights, compare_metrics, trend_analysis
You: What dashboards do we have related to customer retention?
Claude uses search_content to find retention-related dashboards, then get_dashboard to summarize the key metrics. You see a ranked list with the most relevant results.
You: Run the "Monthly Active Users" card for the last 90 days
Claude calls list_cards to locate the card, then execute_card with the appropriate time filter. Results come back as a table you can ask follow-up questions about ("what was the biggest dip and when?").
You: Show me the top 10 products by revenue last quarter from the sales database
Claude calls list_databases to find the sales database, get_database_schema to inspect the relevant tables, then generates and runs a SELECT query via execute_query. The query is validated against the SQL guardrails (no DROP/DELETE/UNION, single statement only) before execution. Audit log entry is written with the query and row count.
You: DROP TABLE users
Request is blocked. Claude surfaces: "Blocked SQL pattern detected: DROP — this operation is not allowed." The block is logged as a high-risk audit event.
You: Which support agents closed the most tickets this week, and how does that compare to last week?
Claude uses nlq_to_sql with the database schema as context to generate a comparative SQL query. You can ask it to explain_sql in plain English before running, or optimize_sql to suggest performance improvements — all before hitting your database.
You: Save the MAU trend query we just ran as a card called "MAU — Last 90 Days" in the Growth collection
Claude calls get_collections to find "Growth", then create_card with your validated SQL. The card now lives in your Metabase library and can be re-executed by name in future conversations via execute_card — no LLM tokens spent on re-generating the query.
You: Get me the details for dashboards 1, 3, and 7, plus the schema for the sales database
Claude uses batch_execute to run all four operations in parallel in a single call:
{
"operations": [
{ "tool": "get_dashboard", "args": { "dashboard_id": 1 } },
{ "tool": "get_dashboard", "args": { "dashboard_id": 3 } },
{ "tool": "get_dashboard", "args": { "dashboard_id": 7 } },
{ "tool": "get_database_schema", "args": { "database_id": 2 } }
]
}One tool call instead of four. Results come back with per-operation success/failure, so partial failures don't block the rest.
You: Find dashboards about revenue, get the first one's cards, and run the top card
Claude uses run_workflow to chain the steps with output references:
{
"steps": [
{ "name": "find", "tool": "search_content", "args": { "query": "revenue", "type": "dashboard" } },
{ "name": "dash", "tool": "get_dashboard", "args": { "dashboard_id": "$find.results[0].id" } },
{ "name": "data", "tool": "execute_card", "args": { "card_id": "$dash.dashcards[0].card_id" } }
]
}Each step can reference results from previous steps using $stepName.path[index].field syntax. One round trip instead of three back-and-forth exchanges.
In write/full mode, pipelines can also build content:
You: Save this query as a card and put it on a new "Growth" dashboard
{
"steps": [
{ "name": "card", "tool": "create_card", "args": { "name": "MAU Trend", "database_id": 2, "sql": "SELECT ..." } },
{ "name": "dash", "tool": "create_dashboard", "args": { "name": "Growth" } },
{ "name": "link", "tool": "add_card_to_dashboard", "args": { "dashboard_id": "$dash.id", "card_id": "$card.id" } }
]
}Write steps go through the same guardrails as the standalone write tools: write-tier rate limiting, SQL validation, and per-operation audit logging. Destructive operations (deletes/removes) are not allowed in pipelines.
You: Run last quarter's revenue query and tell me what's interesting
Claude uses execute_query to run the query, then generate_insights which asks the Claude API to identify trends, outliers, and recommendations. You get a structured summary: headline number, 3-5 bullet points, and suggested follow-up questions.
Note on data privacy:
generate_insights,ask_data,compare_metrics, andtrend_analysissend query result rows to the Anthropic API for analysis. See Data Privacy Note for details.
This server is designed for production use with multiple layers of protection:
SQL Guardrails: Only SELECT and WITH queries are allowed by default. DDL/DML statements (DROP, DELETE, INSERT, etc.) are blocked. Injection patterns (UNION, comments, multi-statement, file ops, time-based attacks) are detected and rejected.
Tiered Rate Limiting: Separate limits for read (120/min), write (30/min), and LLM (20/min) operations, configurable via RATE_LIMIT_*_PER_MINUTE.
Per-Tool Access Control: MCP_TOOLS_ALLOW / MCP_TOOLS_DENY restrict which tools are exposed, enforced at registration and inside batch_execute / run_workflow.
Audit Logging: Every operation is logged with risk assessment (low/medium/high). Sensitive fields are automatically redacted. Log files are created with secure permissions (owner-only read/write).
Secret Isolation: API keys are never exposed to tool handlers. Error responses from Metabase are sanitized to prevent credential leakage.
Redirect Protection: API key headers are never forwarded on HTTP redirects.
When using NLQ or insight tools (ask_data, generate_insights, etc.), query result data is sent to the Anthropic API for analysis. If your queries return sensitive data (PII, financial records, etc.), that data will be processed by Claude. Consider this when enabling NLQ features on databases containing sensitive information.
What this extension collects:
Your Metabase API key and URL (stored locally in the OS keychain — never transmitted to us)
Your Anthropic API key, if provided (stored locally in the OS keychain — never transmitted to us)
No telemetry, analytics, or usage data is collected by this extension
What this extension transmits:
All Metabase API calls (queries, dashboards, cards) go directly from your machine to your own Metabase instance
NLQ/insight tool usage sends your natural-language question, database schema context, and query result samples to the Anthropic API for processing (governed by Anthropic's privacy policy)
If you don't provide an Anthropic API key, no data is sent to Anthropic — NLQ and insight tools are simply disabled
Data retention:
This extension does not retain any data. Audit logs (if enabled via AUDIT_LOG_FILE) are written to your local filesystem only, with owner-only permissions (0600)
Third-party privacy policies:
Reporting security issues: See SECURITY.md for responsible disclosure.
Verify METABASE_URL is correct and reachable (test: curl $METABASE_URL/api/health)
Verify METABASE_API_KEY is valid (regenerate in Metabase Admin > Settings > API Keys if needed)
The API key must have permissions for the databases you want to query
Only SELECT and WITH queries are allowed by default
Even inside a SELECT, patterns like UNION SELECT, SQL comments (--, /* */), xp_cmdshell, INTO OUTFILE, etc. are blocked
To execute DML (INSERT, UPDATE, DELETE), you must run in write or full mode AND the SQL must still pass guardrails (it won't — by design)
Default limits: 120 reads/min, 30 writes/min, 20 LLM calls/min
Adjust with RATE_LIMIT_REQUESTS_PER_MINUTE env var
Wait for the retry-after period shown in the error
Requires ANTHROPIC_API_KEY — verify it's set
Check it starts with sk- and has remaining credits
Insight tools additionally require MCP_MODE=full
Fully quit and restart Claude Desktop
Check logs: ~/Library/Logs/Claude/mcp*.log on macOS
Verify node --version is >= 20
This project is young and your input shapes where it goes next — especially now that Metabase has shipped its own official MCP. A minute of your time helps a lot:
Is this useful for your workflow? Start a GitHub Discussion or star the repo — tells me where to invest.
Which tools do you actually use? Let me know in Discussions — helps prioritize what stays, what grows.
Hit a bug? File an issue with your Metabase version, MCP_MODE, and reproduction steps.
Missing a feature? Request it — especially something the official Metabase MCP doesn't cover.
Running in production? I'd genuinely love to hear about it — open a Discussion or drop a note on the repo.
Bug reports / feature requests: GitHub Issues
Questions / general feedback: GitHub Discussions
Security vulnerabilities: Private disclosure — see SECURITY.md
Response time: typically within 5 business days
npm install # Install dependencies
npm run build # Compile TypeScript
npm run dev # Watch mode
npm test # Run all tests
npm run type-check # Type checking
npm run lint # LintingSee CONTRIBUTING.md for more details.
Execute multiple read operations in a single call. Supports up to 20 operations run in parallel. Supported tools: get_dashboard, get_card, execute_card, get_database_schema, execute_query, search_content, list_dashboards, list_databases, list_cards.
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Array of operations to execute in parallel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds that operations run in parallel and supports up to 20 operations, which are useful behavioral insights. No contradictions.
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?
Two concise sentences that are front-loaded with the primary purpose and key constraints (max 20, parallel). No unnecessary words.
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?
The description is adequate given the rich schema and annotations, but it does not mention the return format or potential error behavior. For a batch tool, explaining response structure would enhance completeness.
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% coverage with detailed definitions for each operation's args. The description lists supported tools but adds no deeper semantic meaning beyond what the schema provides.
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 'Execute multiple read operations in a single call', specifying the verb and resource. It also lists all supported tools (get_dashboard, get_card, etc.), which distinguishes it from the individual tool siblings.
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 the limit of 20 operations and parallel execution, but does not explicitly state when to use this tool versus individual calls. However, the implication is clear: use when multiple reads are needed simultaneously.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an existing question/card and get results
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | Card ID to execute | |
| parameters | No | Optional parameters for parameterized queries | |
| fields | No | Column names to include in results (default: all) | |
| format | No | Response format (default: compact). Use "default" for pretty-printed output | |
| limit | No | Max rows to return (default: server maxRows setting) | |
| offset | No | Row offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, aligning with the description. The description adds no further behavioral context (e.g., caching, performance implications), but does not contradict the annotations.
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, but could be slightly improved by including the tool's main function without being verbose.
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 (6 parameters, no output schema), the description lacks crucial context such as return format, pagination behavior, or support for parameterized queries.
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 100%, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides.
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 executes an existing card and returns results, but does not differentiate from sibling tools like batch_execute or execute_query.
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?
No guidance is provided on when to use this tool versus alternatives such as execute_query or batch_execute. This forces the agent to infer usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SQL query (SELECT statements only)
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | Database ID to query | |
| sql | Yes | SQL query (SELECT statements only) | |
| fields | No | Column names to include in results (default: all) | |
| format | No | Response format (default: compact). Use "default" for pretty-printed output | |
| limit | No | Max rows to return (default: server maxRows setting) | |
| offset | No | Row offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true and openWorldHint: true. The description adds value by confirming SELECT-only behavior, but does not disclose other traits like error handling, permission requirements, or how results are returned. Consistent with annotations, so no contradiction.
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, focused sentence with no wasted words. It is front-loaded with the main purpose and efficiently conveys the core constraint (SELECT only).
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 an output schema, the description should clarify what the tool returns (e.g., row structure, format details). It does not explain how fields, limit, or offset affect output. The description relies heavily on the schema, which is insufficient for complete context.
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 coverage is 100%, with all parameters described in the input schema. The description does not add any parameter-specific information beyond what is already in the schema, so baseline 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 verb 'Execute a SQL query' and specifies the restriction to SELECT statements. The title from annotations reinforces this. It distinguishes from sibling tools like batch_execute and execute_card by emphasizing SQL queries.
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 lacks explicit guidance on when to use this tool versus alternatives (e.g., batch_execute, execute_card). It only implies usage for SELECT statements but does not mention when not to use it or provide context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific question/card
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | Card ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, covering safety and idempotency. The description adds no behavioral details beyond 'Get details', which is consistent but not enriching. It does not contradict annotations.
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 sentence, very concise. It efficiently conveys the purpose without waste. However, it could be slightly more structured to include key details like what 'details' entails, but for a simple tool it is acceptable.
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 simplicity (one required param, no output schema), the description is somewhat complete. It states the action and target but does not elaborate on the response structure or additional context. The lack of output schema increases the need for more description, but the annotation flags help.
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?
With only one parameter (card_id) and 100% schema description coverage ('Card ID'), the description adds no additional meaning. The baseline of 3 is appropriate as the schema already covers the parameter adequately.
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 states 'Get details of a specific question/card', which is a clear verb+resource combination. It distinguishes from siblings like 'list_cards' (which lists many) and 'execute_card' (which runs a card), making the tool's purpose unambiguous.
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 needing details of a specific card, which is clear context. However, it does not explicitly mention when not to use it (e.g., for listing all cards) or point to alternatives, though given the tool's simplicity, the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all collections
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read-only behavior. The description adds no further behavioral context beyond what annotations provide, which is adequate but not enriched.
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, front-loaded sentence with no extraneous words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, read-only, list operation), the description is complete enough for an agent to understand its basic function. However, additional context about the kind of collections or output format could be beneficial.
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 tool has zero parameters, so the baseline score is 4. The schema coverage is 100%, and the description does not need to add parameter information since none exist.
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 'List all collections' clearly states the verb and resource, making the purpose immediately understandable. However, it does not differentiate from sibling tools like list_cards or list_databases, which are also listing operations.
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. Siblings include various list and search tools, but no explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dashboard details including its cards
| Name | Required | Description | Default |
|---|---|---|---|
| dashboard_id | Yes | Dashboard ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, making the safe behavior clear. The description adds value by specifying that the response includes cards, which is not in the annotations.
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?
A single concise sentence that communicates the essential purpose without any extraneous words or repetition.
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?
For a simple read-only tool with one parameter and no output schema, the description adequately conveys the returned data (details and cards). It's sufficient for an AI agent to understand the tool's purpose.
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 describes the single parameter (dashboard_id) with a basic description ('Dashboard ID'). Since schema coverage is 100%, the description does not need to add more, but it also does not elaborate on format or constraints.
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 ('Get') and resource ('dashboard details including its cards'), distinguishing it from siblings like list_dashboards (which lists summaries) and get_card (which focuses on a single card).
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?
No explicit guidance on when to use this tool versus alternatives like get_card or list_dashboards. However, the context of siblings and annotations implies it's for retrieving full details of a specific dashboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tables and columns for a database
| Name | Required | Description | Default |
|---|---|---|---|
| database_id | Yes | Database ID | |
| detail | No | Level of detail. "tables_only" returns table names without columns | |
| format | No | Response format (default: compact). Use "default" for pretty-printed output | |
| tables | No | Filter to specific table names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safe, read-only behavior is known. The description adds no additional behavioral context about potential side effects or constraints, which is acceptable given the annotations.
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 concise sentence that communicates the core purpose without any superfluous words. It is front-loaded and 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?
No output schema is provided, so the agent must infer the return format. The description does not clarify whether output includes column details, data types, or other schema properties. However, the input parameters (detail, format, tables) hint at modifiable output structure. Adequate but not comprehensive.
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 coverage is 100% (4 parameters fully described). The description does not add any extra meaning beyond the schema; it merely restates the overall purpose. Baseline 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 'Get tables and columns for a database' uses a specific verb ('Get') and resource ('database schema'), clearly distinguishing this tool from siblings like 'execute_query' or 'list_databases'. The purpose is immediately understandable.
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 such as 'execute_query' or 'get_card'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List questions/cards in Metabase. Returns up to 100 cards. Use search_content for discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | No | Filter by collection ID | |
| limit | No | Max cards to return (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the behavioral burden is light. The description adds useful context about the 100-card limit but does not disclose other traits like rate limits or authorization needs.
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?
Two concise sentences with no unnecessary words. The purpose is front-loaded and immediately clear.
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 no output schema and the presence of rich annotations, the description adequately covers the tool's functionality. Minor gaps: no mention of ordering, access control, or that results are from user-accessible collections.
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 coverage is 100%, so the schema documents both parameters thoroughly. The description adds no new semantic information beyond the schema descriptions, staying at the baseline.
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 it lists cards in Metabase, with a specific verb and resource. It references search_content for discovery, distinguishing from that sibling, but does not explicitly differentiate from get_card or list_dashboards.
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?
Provides clear guidance on return limit (up to 100 cards) and suggests search_content for broader discovery, giving context on when to use which tool. However, no explicit when-not-to-use or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all dashboards in Metabase
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description need not repeat them. However, it adds no additional behavioral context (e.g., pagination, ordering, or that results depend on user permissions). This is adequate but minimal.
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 concise sentence with no extraneous words. It is front-loaded and immediately informative.
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?
For a tool with no parameters or output schema, the description covers the essential purpose. However, it could optionally mention side effects (none) or return format (list of dashboard summaries), but this is not critical.
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?
There are zero parameters, and schema description coverage is 100% trivially. The description does not need to provide parameter details, and it correctly implies no input is required.
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 ('List') and resource ('all dashboards') with specific scope ('in Metabase'). It is unambiguous and distinguishes from siblings like 'get_dashboard' which targets a specific dashboard.
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?
No guidance is provided on when to use this tool versus alternatives such as 'search_content' or 'get_dashboard'. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds 'all connected databases', which is consistent but does not provide additional behavioral context beyond the annotations.
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?
Extremely concise, single sentence with no wasted words. Perfectly front-loaded.
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?
No output schema is provided, and the description does not specify what the returned list contains (e.g., name, id). While simple, it could be more informative for an agent expecting a specific output format.
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 no parameters, so the description has nothing to add. Following the baseline of 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 uses the verb 'list' and clearly specifies the resource 'databases'. It distinguishes well from sibling tools like list_cards and list_dashboards.
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?
No guidance on when to use this tool versus alternatives. The description only states its function without any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a multi-step workflow pipeline in a single call. Steps run sequentially and can reference previous step results using "$stepName.path" syntax. Example: search for dashboards, then get details of the first result, then execute its cards — all in one call. Max 10 steps.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Ordered pipeline steps. Each step can reference results from previous steps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds key behavioral details: steps run sequentially, can reference previous results using '$stepName.path', max 10 steps. Error handling is covered in the schema but not in description, which is acceptable.
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?
Two sentences plus a note, no wasted words. The core purpose and key usage details are front-loaded.
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?
For a tool with a single parameter (steps) and no output schema, the description is sufficiently complete, covering purpose, sequential execution, referencing, and step limits. Could mention error handling or return behavior, but not critical.
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 coverage is 100% with detailed descriptions for all properties. The description adds value by explaining the '$stepName.path' referencing syntax, but does not elaborate on other parameter aspects.
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 it executes a multi-step workflow pipeline in a single call, with sequential steps and referencing previous results. It differentiates from sibling tools like batch_execute which likely handles independent calls.
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 a clear usage context (multi-step pipeline) and an example, but does not explicitly state when not to use or compare with alternatives like batch_execute for independent steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across Metabase content (dashboards, cards, collections)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| type | No | Filter by content type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds the content types but no additional behavioral traits like pagination or result limits. With annotations present, the description provides acceptable but minimal extra context.
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 sentence that is front-loaded and contains no unnecessary words. Every part serves a purpose.
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 low complexity (2 parameters, good annotations, no output schema), the description is sufficient. It covers the purpose and scope, though it could mention the absence of pagination or result format.
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 100%, so the schema already documents both parameters. The description does not add any meaning beyond what the schema provides.
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 'search' and the resources 'Metabase content (dashboards, cards, collections)', distinguishing it from sibling tools like get_card or get_dashboard which retrieve specific items.
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?
No explicit guidance on when to use this tool versus alternatives. The sibling tools are mostly retrieval, so usage is implied, but no when-not or alternative instructions are provided.
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.
v1.3.0batch_executeexecute_card4 fields changedInput schema / properties / fieldsAdded value: +{
+ "description": "Column names to include in results (default: all)",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / formatAdded value: +{
+ "description": "Response format (default: compact). Use \"default\" for pretty-printed output",
+ "enum": [
+ "default",
+ "compact"
+ ],
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Max rows to return (default: server maxRows setting)",
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Row offset for pagination",
+ "minimum": 0,
+ "type": "number"
+}execute_query4 fields changedInput schema / properties / fieldsAdded value: +{
+ "description": "Column names to include in results (default: all)",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / formatAdded value: +{
+ "description": "Response format (default: compact). Use \"default\" for pretty-printed output",
+ "enum": [
+ "default",
+ "compact"
+ ],
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Max rows to return (default: server maxRows setting)",
+ "maximum": 10000,
+ "minimum": 1,
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Row offset for pagination",
+ "minimum": 0,
+ "type": "number"
+}get_database_schema3 fields changedInput schema / properties / detailAdded value: +{
+ "description": "Level of detail. \"tables_only\" returns table names without columns",
+ "enum": [
+ "full",
+ "tables_only"
+ ],
+ "type": "string"
+}Input schema / properties / formatAdded value: +{
+ "description": "Response format (default: compact). Use \"default\" for pretty-printed output",
+ "enum": [
+ "default",
+ "compact"
+ ],
+ "type": "string"
+}Input schema / properties / tablesAdded value: +{
+ "description": "Filter to specific table names",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}run_workflowv1.1.1execute_cardexecute_queryget_cardget_collectionsget_dashboardget_database_schemalist_cardslist_dashboardslist_databasessearch_contentEach tool targets a distinct Metabase resource or action, such as dashboards, cards, databases, queries, or content search. The batch_execute and run_workflow tools have clear specialized roles, avoiding overlap.
All tool names follow snake_case and a consistent verb_noun pattern (e.g., get_dashboard, execute_query, search_content). Even run_workflow fits the pattern with a clear verb.
With 12 tools, the set covers common Metabase operations without being overwhelming or too sparse. Each tool serves a clear purpose, and the count is well-scoped for the domain.
The set covers reading, searching, and executing queries, which addresses most common consumption needs. However, it lacks any create, update, or delete operations, leaving a gap for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Search, read, create and edit your Memol notes from Claude. Team note-taking with AI search.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/1luvc0d3/metabase-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
