Metabase
The Metabase MCP server provides AI-powered access to Metabase analytics platforms through a high-performance Model Context Protocol interface, enabling comprehensive data discovery, query execution, and export capabilities.
Search and Discovery: Search across all Metabase content (cards, dashboards, tables, databases, collections, datasets, segments, actions, indexed-entities, and metrics) using keywords or IDs, with filtering by model type, database ID, archived/verified status, and options to search within native SQL query content or include dashboard questions.
Data Retrieval: Fetch detailed information for specific items (cards, dashboards, tables, databases, collections, fields) by ID with batch support for up to 50 IDs per request and concurrent processing. List all resources with optimized responses showing only essential fields and pagination support for large datasets.
Query Execution: Execute custom SQL queries with template variables or run saved cards against Metabase databases with parameter filtering for dynamic results. Configurable row limits (default: 100, max: 500 rows) with read-only mode by default restricting execution to SELECT queries only.
Data Export: Export large datasets up to 1M rows in CSV, JSON, or XLSX formats from either SQL queries or saved cards, with support for parameter filtering and custom filenames.
Cache Management: Clear internal cache with granular control over individual model caches, list caches, or bulk operations (all, all-lists, all-individual).
Performance Features: Multi-layer caching with configurable TTL, up to 90% token reduction through response optimization, and robust error handling with structured responses.
Security Controls: Read-only mode enabled by default prevents destructive operations (INSERT, UPDATE, DELETE, DROP) to ensure data integrity. Dual authentication options support both API key (recommended) and email/password credentials, with configurable request timeouts.
Flexible Deployment: Supports multiple installation methods including Claude Desktop, npx manual configuration, Docker containers, and local development setups.
Provides tools for integrating with Metabase analytics platforms, including listing and retrieving cards, dashboards, tables, databases, and collections; searching across Metabase items; executing SQL queries and saved cards; and exporting large datasets up to 1M rows in multiple formats.
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., "@Metabaseshow me last month's sales dashboard"
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.
Metabase MCP
A high-performance Model Context Protocol server for AI integration with Metabase analytics platforms. Features response optimization, robust error handling, and comprehensive data access tools.
Key Features
Response Optimization: Up to 90% token reduction for efficient AI context usage
Robust Error Handling: Comprehensive error handling with structured, actionable responses
Smart Caching: Multi-layer caching with configurable TTL for improved performance
Modern MCP Support: MCP
2026-07-28discovery and cache hints with legacy client compatibilityUnified Commands:
list,retrieve,search,execute, andexporttoolsDual Authentication: API key or email/password authentication
Large Data Export: Export up to 1M rows in CSV, JSON, and XLSX formats
Read-Only Mode: Enabled by default to restrict execute to SELECT queries only
Related MCP server: FastAPI MCP Server
Installation
Option 1: Claude Desktop
Install directly from the Claude Desktop Directory, or:
Download
metabase-mcp.mcpbfrom ReleasesOpen the
.mcpbfile with Claude Desktop to installConfigure your Metabase credentials in Claude Desktop's extension settings
Option 2: Manual Configuration
Add the following to your MCP client configuration:
{
"mcpServers": {
"metabase-mcp": {
"command": "npx",
"args": ["-y", "@jerichosequitin/metabase-mcp"],
"env": {
// Required
"METABASE_URL": "https://your-metabase-instance.com",
// Authentication (choose one)
"METABASE_API_KEY": "your_api_key_here", // API key (recommended)
"METABASE_USER_EMAIL": "", // OR email/password
"METABASE_PASSWORD": "",
// Optional (defaults shown)
"EXPORT_DIRECTORY": "~/Downloads/Metabase", // Export location
"METABASE_PROXY_AUTHORIZATION": "", // Optional Proxy-Authorization value for IAP, e.g. "Bearer <token>"
"METABASE_READ_ONLY_MODE": "true", // Restrict to SELECT queries
"LOG_LEVEL": "info", // debug, info, warn, error, fatal (debug enables pretty JSON)
"CACHE_TTL_MS": "600000", // 10 minutes
"REQUEST_TIMEOUT_MS": "600000" // 10 minutes
}
}
}
}Option 3: Docker
For containerized deployments without installing Node.js. Add to your MCP client configuration:
{
"mcpServers": {
"metabase-mcp": {
"command": "docker",
"args": [
"run", "-i", "--rm", "--init",
"-e", "METABASE_URL=https://your-metabase-instance.com",
"-e", "METABASE_API_KEY=your_api_key",
// Optional: mount volume for exports
// "-v", "~/Downloads/Metabase:/home/node/exports",
"ghcr.io/jerichosequitin/metabase-mcp:latest"
]
}
}
}Or build locally: docker build -t metabase-mcp . and use metabase-mcp as the image name.
Required flags: -i (interactive, for MCP stdio), --rm (cleanup), --init (signal handling)
Environment variables: Pass via -e flags. See Manual Configuration for all options. Docker defaults: LOG_LEVEL=info, METABASE_READ_ONLY_MODE=true, EXPORT_DIRECTORY=/home/node/exports.
Available Tools
list
Fetch all records for a resource type with optimized responses returning only essential fields.
Models:
cards,dashboards,tables,databases,collectionsPagination:
offset/limitparameters for large datasets
retrieve
Get detailed information for specific items by ID with concurrent processing.
Models:
card,dashboard,table,database,collection,fieldBatch Support: Up to 50 IDs per request
Pagination:
table_offset/table_limitfor databases with many tables
search
Search across all Metabase items using the native search API.
Filtering: By model type, database ID, or content
Options: Search native SQL queries, include dashboard questions
execute
Execute SQL queries or run saved cards with configurable row limits (default: 100, max: 500).
SQL Mode: Custom queries with
database_idandqueryCard Mode: Saved cards with
card_idand optionalcard_parametersfor filteringSecurity: Respects Read-Only Mode (blocks INSERT, UPDATE, DELETE, DROP, etc.)
export
Export large datasets up to 1M rows to the configured export directory.
Formats: CSV, JSON, XLSX
SQL Mode: Export custom query results
Card Mode: Export saved card results with optional filtering
Note: When using hosted remote deployments (e.g., Glama), exported files are saved inside the container and are inaccessible. Use
executefor query results directly, or run locally via npx/Docker for full export functionality.
clear_cache
Clear internal cache with granular control.
Targets: Individual model caches, list caches, or bulk operations (
all,all-lists,all-individual)
For Developers
Prerequisites
Node.js 20.0.0 or higher
Active Metabase instance
Setup
git clone https://github.com/jerichosequitin/metabase-mcp.git
cd metabase-mcp
npm install
npm run buildThen configure your MCP client to use the local build:
{
"mcpServers": {
"metabase-mcp": {
"command": "node",
"args": ["/path/to/metabase-mcp/build/src/index.js"],
"env": { /* see Manual Configuration for options */ }
}
}
}Debugging
Use the MCP Inspector for development:
npm run inspectorTesting
npm test # Run tests
npm run test:coverage # Coverage reportBuilding MCPB Package
npm run mcpb:buildCreates metabase-mcp-{version}.mcpb ready for GitHub Releases.
Security
Read-Only Mode is enabled by default (METABASE_READ_ONLY_MODE=true), restricting the execute tool to SELECT queries only. Write operations (INSERT, UPDATE, DELETE, DROP, etc.) are blocked. Set to false to allow write operations.
Authentication: API key authentication is recommended over email/password for production use.
Proxy Authentication: Set METABASE_PROXY_AUTHORIZATION when Metabase is behind a proxy that requires a Proxy-Authorization header, such as Google IAP. The value is passed through exactly as provided, for example Bearer <token>.
License
This project is licensed under the MIT License.
Available Tools
5 toolsclear_cacheAIdempotent
Clear the internal cache for stored data. Useful for debugging or when you know the data has changed. Supports granular cache clearing for both individual items and list caches.
| Name | Required | Description | Default |
|---|---|---|---|
| cache_type | No | Type of cache to clear: "all" (default - clears all cache types), individual item caches ("cards", "dashboards", "tables", "databases", "collections", "fields"), list caches ("cards-list", "dashboards-list", "tables-list", "databases-list", "collections-list"), or bulk operations ("all-lists", "all-individual") | all |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains that clearing is 'granular' for both individual items and list caches, which helps the agent understand the tool's capabilities. While annotations cover idempotency and non-destructive nature, the description provides practical usage context that complements them without 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 perfectly concise with three sentences that each add distinct value: stating the core purpose, providing usage context, and explaining granular capabilities. No wasted words, and information is front-loaded with the primary function stated first.
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 single-parameter tool with comprehensive annotations and full schema coverage, the description provides adequate context about purpose, usage scenarios, and behavioral characteristics. The main gap is the lack of output schema information, but given the tool's relative simplicity and good annotation coverage, the description is mostly complete.
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 100% schema description coverage, the input schema already fully documents the single parameter's purpose, enum values, and default. The description mentions 'granular cache clearing for both individual items and list caches' which aligns with but doesn't significantly expand upon the schema's detailed enum descriptions.
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 specific action ('Clear') and target resource ('internal cache for stored data'), distinguishing it from sibling tools like list, retrieve, or search. It provides additional context about what the cache contains (stored data) and the granularity of clearing 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 explicit guidance on when to use the tool ('Useful for debugging or when you know the data has changed'), giving clear context for its application. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
executeADestructive
Unified command to execute SQL queries or run saved cards against Metabase databases. Use Card mode when existing cards have the needed filters. Use SQL mode for custom queries or when cards lack required filters. Returns up to 500 rows per request - for larger datasets, use the export tool instead. SECURITY WARNING: SQL mode can execute ANY valid SQL including destructive operations (DELETE, UPDATE, DROP, TRUNCATE, ALTER). Use with caution and ensure appropriate database permissions are configured in Metabase. Note: When Read-Only Mode is enabled, write operations will be rejected with an error.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | SQL query to execute (SQL mode only) | |
| card_id | No | ID of saved card to execute (card mode only) | |
| row_limit | No | Maximum number of rows to return (default: 100, max: 500). For larger datasets, use the export tool. | |
| database_id | No | Database ID to execute query against (SQL mode only) | |
| card_parameters | No | Parameters for filtering card results (card mode only). Each parameter must follow Metabase format: {id: "uuid", slug: "param_name", target: ["dimension", ["template-tag", "param_name"]], type: "param_type", value: ["param_value"]}. For dimension targets, value should be an array; scalar values are accepted and auto-wrapped. | |
| native_parameters | No | Parameters for SQL template variables like {{variable_name}} (SQL mode only) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds explicit security warnings about destructive SQL operations, mentions read-only mode rejection, and clarifies behavior for both modes. This goes beyond annotations to provide essential safety 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?
Description is concise (~150 words), front-loaded with primary purpose, then logically organizes modes, limitations, warnings, and exceptions. Every sentence serves a purpose—no filler.
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 complexity (dual modes, security concerns, no output schema), description covers all critical aspects: modes, parameters, row limits (and export alternative), security warning, and read-only mode handling. Leaves no major gaps for safe usage.
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 all parameters. Description adds context by explaining the card_parameters format in detail and clarifying mode-specific parameters (e.g., database_id for SQL only). Slightly redundant on row_limit since schema already has bounds, but overall adds value.
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?
Description states it is a 'Unified command to execute SQL queries or run saved cards', specifying verb (execute) and resources (SQL queries, saved cards). Distinguishes two clear modes and sets expectations for row limits, making it highly specific and actionable.
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 guidance on when to use Card vs SQL mode based on filter needs, and mentions export tool for larger datasets. However, it does not compare to sibling tools (clear_cache, search, retrieve, list) or state when not to use this tool, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
listARead-onlyIdempotent
Fetch all records for a single Metabase resource type with highly optimized responses for overview purposes. Retrieves complete lists of cards, dashboards, tables, databases, or collections. Returns only essential identifier fields for efficient browsing and includes intelligent caching for performance. Supports pagination for large datasets exceeding token limits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of items to return per page. Maximum 1000 items per page. Use with offset for pagination. | |
| model | Yes | Model type to list ALL records for. Supported models: cards (all questions/queries), dashboards (all dashboards), tables (all database tables), databases (all connected databases), collections (all folders/collections). Only one model type allowed per request for optimal performance. | |
| offset | No | Starting offset for pagination. Use with limit for paginating through large datasets that exceed token limits. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, idempotent, and open-world properties. The description adds valuable behavioral context beyond annotations: 'intelligent caching for performance', 'pagination for large datasets exceeding token limits', and 'returns only essential identifier fields for efficient browsing'. No contradiction with 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 front-loaded with core purpose in the first sentence, followed by supporting details. Every sentence adds value: scope of models, return format, performance features, and pagination support. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (list operation with pagination), rich annotations, and 100% schema coverage, the description is largely complete. It explains the tool's optimization approach and caching behavior. The main gap is lack of output schema, but the description partially compensates by stating 'returns only essential identifier fields'.
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%, providing full parameter documentation. The description adds minimal extra semantics, mentioning 'highly optimized responses' and 'intelligent caching' which relate to overall tool behavior rather than parameter specifics. Baseline 3 is appropriate as the schema carries the burden.
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 ('fetch all records') and resource ('single Metabase resource type'), specifying the exact models supported (cards, dashboards, tables, databases, collections). It distinguishes from siblings like 'search' by emphasizing 'complete lists' for 'overview purposes' rather than filtered results.
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 clear context for when to use this tool ('for overview purposes', 'efficient browsing', 'highly optimized responses'), but does not explicitly state when not to use it or name alternatives like 'search' or 'retrieve' from the sibling list. It implies usage for bulk retrieval vs. specific lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retrieveARead-onlyIdempotent
Fetch additional details for supported models (Cards, Dashboards, Tables, Databases, Collections, Fields). Supports multiple IDs (max 50 per request) with intelligent concurrent processing and optimized caching. Includes table pagination for large databases exceeding token limits.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Array of IDs to retrieve (1-50 IDs per request). All IDs must be positive integers. For larger datasets, make multiple requests. | |
| model | Yes | Type of model to retrieve. Only one model type allowed per request. | |
| table_limit | No | Maximum number of tables to return per page (database model only). Maximum 100 tables per page. Use with table_offset for pagination. | |
| table_offset | No | Starting offset for table pagination (database model only). Use with table_limit for paginating through large databases that exceed token limits. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: 'intelligent concurrent processing', 'optimized caching', and 'table pagination for large databases exceeding token limits'. While annotations cover safety (readOnlyHint, destructiveHint) and idempotency, the description provides practical implementation details that help the agent understand performance characteristics and limitations.
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 efficiently structured in three sentences: purpose statement, key capabilities/limitations, and special handling for edge cases. Every sentence adds value without redundancy, and the most important information (what it does) comes first.
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 rich annotations (readOnlyHint, openWorldHint, idempotentHint) and comprehensive schema coverage, the description provides good contextual information about capabilities and limitations. The main gap is the absence of an output schema, but the description compensates somewhat by indicating what kind of details will be fetched. For a read-only retrieval tool, this is reasonably complete.
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 100% schema description coverage, the schema already documents all parameters thoroughly. The description mentions 'multiple IDs (max 50 per request)' and 'table pagination for large databases' which aligns with but doesn't significantly expand upon the schema's parameter descriptions. Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Fetch') and resource ('additional details for supported models') with specific model types listed. It distinguishes from siblings like 'list', 'search', and 'export' by focusing on retrieving details for specific IDs rather than listing, searching, or exporting data.
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 clear context for when to use this tool (fetching details for specific models with IDs) and mentions limitations (max 50 IDs, pagination for large databases). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotent
Search across all Metabase items using native search API. Supports cards, dashboards, tables, collections, databases, and more. Use this first for finding any Metabase content. Returns search metrics, recommendations, and clean results organized by model type.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Search for specific IDs. RESTRICTIONS: Only works with single model type, cannot be used with "table" or "database" models. | |
| query | No | Search across names, descriptions, and metadata. | |
| models | No | Model types to search (default: ["card", "dashboard"]). RESTRICTION: "database" model cannot be mixed with others and must be used exclusively. | |
| archived | No | Search archived items only (default: false) | |
| verified | No | Search verified items only (requires premium features) | |
| database_id | No | Search items from specific database ID. RESTRICTION: Cannot be used when searching for databases (models=["database"]). | |
| max_results | No | Maximum number of results to return (default: 20, max: 50) | |
| search_native_query | No | Search within SQL query content of cards (default: false). RESTRICTION: Only works when models=["card"] exclusively. | |
| include_dashboard_questions | No | Include questions within dashboards in results (default: false). RESTRICTION: Only works when "dashboard" is included in models. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies what types of content are searched (cards, dashboards, tables, etc.), mentions the return format includes 'search metrics, recommendations, and clean results organized by model type,' and indicates this is a comprehensive search tool. Annotations already cover safety (readOnly, non-destructive, idempotent) and openness, so the description appropriately focuses on operational 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 efficiently structured in three sentences: first states the core functionality and scope, second provides usage guidance, third describes the return format. Every sentence adds value with zero waste, making it front-loaded and appropriately sized for the tool's complexity.
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 comprehensive annotations (readOnly, openWorld, idempotent, non-destructive) and 100% schema coverage, the description provides good contextual completeness. It explains the tool's purpose, when to use it, and what it returns. The main gap is the lack of output schema, but the description partially compensates by mentioning return content organization.
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 100% schema description coverage, the input schema already thoroughly documents all 9 parameters including their purposes, defaults, and restrictions. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 searches across all Metabase items using the native search API, listing specific resource types (cards, dashboards, tables, collections, databases, and more). It distinguishes from siblings by specifying this is the primary search tool ('Use this first for finding any Metabase content'), unlike list or retrieve tools that might fetch 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?
The description explicitly provides usage guidance: 'Use this first for finding any Metabase content.' This tells the agent when to prefer this tool over alternatives like list or retrieve. It establishes this as the primary search mechanism for broad content discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Most tools have distinct purposes, but 'list' and 'search' could cause some confusion as both are used for finding content, though their descriptions clarify that 'list' is for complete resource overviews while 'search' is for targeted queries. The other tools (clear_cache, execute, export, retrieve) are clearly differentiated in their functions.
All tool names follow a consistent verb-based pattern (clear_cache, execute, export, list, retrieve, search) without mixing conventions like camelCase or snake_case. This uniformity makes the tool set predictable and easy to navigate for an agent.
With 6 tools, this server is well-scoped for its purpose of interacting with Metabase, covering core operations like querying, exporting, listing, retrieving details, searching, and cache management. Each tool serves a specific function without unnecessary bloat or gaps.
The tool set covers essential CRUD-like operations for Metabase, including data retrieval (execute, list, retrieve, search), export, and cache management. Minor gaps exist, such as no explicit tools for creating or updating Metabase resources (e.g., cards or dashboards), but agents can likely work around this using existing tools like 'execute' for SQL operations.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Model Context Protocol server for Studex tools, notifications, and profile integrations
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceHigh-performance server enabling AI assistants to access web scraping, crawling, and deep research capabilities through Model Context Protocol.29MIT
- AlicenseNot gradedqualityDmaintenanceA high-performance Model Context Protocol (MCP) server designed for large language models, enabling real-time communication between AI models and applications with support for session management and intelligent tool registration.2MIT
- AlicenseAqualityDmaintenanceA Model Context Protocol server that enables natural language interaction with Snowflake databases through AI guidance, supporting core database operations, warehouse management, and AI-powered data analysis features.132MIT
- FlicenseNot gradedqualityDmaintenanceA Python-based Model Context Protocol server that integrates local AI models for managing data with features like CRUD operations, similarity search, and text analysis.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jerichosequitin/metabase-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server