Metabase MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap among query execution tools (execute_card_query, execute_native_query, execute_query_builder_card) and metadata retrieval tools (get_database_metadata, get_table_metadata, get_field, get_field_values), which could cause confusion. Descriptions help differentiate them, but the boundaries are not entirely clear.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear prefixes like 'execute_', 'get_', and 'list_'. There are no deviations in naming conventions, making the set predictable and easy to navigate.
Tool Count3/5
With 23 tools, the count feels heavy for a Metabase interface, as many tools are read-only metadata retrievals that could potentially be consolidated. While it covers many aspects, it borders on being overly granular for the domain.
Completeness4/5
The tool set provides comprehensive read-only coverage for querying, metadata, and listing resources in Metabase, with no major gaps for data retrieval. However, it lacks write operations (e.g., creating or updating cards, dashboards, or collections), which limits full lifecycle management.
Average 4.2/5 across 23 of 23 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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 effectively adds context beyond the input schema by highlighting the 'MODERATE RISK' and explaining that queries 'may be slow or resource-intensive.' This warns about performance impacts, which is crucial for a tool with potential resource usage. It doesn't cover other aspects like permissions or response format, but the risk disclosure is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a risk emoji and key action. Both sentences earn their place: the first states the purpose, and the second elaborates on usage and risk. It avoids redundancy and is efficiently structured, though the risk note could be integrated more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, nested objects, no output schema, and no annotations), the description is moderately complete. It covers purpose and risk but lacks details on output format, error handling, or specific behavioral traits like rate limits. The risk warning is helpful, but for a tool with potential resource impacts, more context on performance or limitations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents both parameters ('cardId' and 'parameters'). The description adds marginal value by mentioning 'custom filters and aggregations,' which aligns with the 'parameters' object but doesn't provide additional syntax or format details beyond what the schema implies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a query-builder card with specific parameters' and 'run query builder cards with custom filters and aggregations.' This specifies the verb (execute/run), resource (query-builder card), and scope (with parameters). However, it doesn't explicitly distinguish it from sibling tools like 'execute_card_query' or 'execute_native_query,' which likely have similar functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'custom filters and aggregations,' suggesting this tool is for parameterized queries. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'execute_card_query' or 'execute_native_query,' nor does it specify prerequisites or exclusions. The risk warning hints at cautious use but lacks concrete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively adds context beyond what's in the schema: it explicitly states '[SAFE]' and 'Risk: None - read-only operation,' clarifying safety and read-only nature. It also hints at the tool's scope ('recent activity feed') and purpose ('see what users are doing or what content is popular'), though it lacks details on rate limits, pagination, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with an emoji and key safety info. It uses three sentences that each add value: stating the purpose, usage context, and risk assessment. There's minimal waste, though the emoji and bracketed '[SAFE]' could be seen as slightly informal, but they contribute to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers purpose, usage, and safety well, but lacks details on output format (e.g., what the activity feed returns), pagination beyond the 'limit' parameter, or how 'recent' is defined. Without an output schema, more explanation of return values would be helpful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage, providing details on 'limit' including type, range, and default. The description doesn't add any parameter-specific information beyond what the schema already covers. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get recent activity feed showing views, edits, and other actions in Metabase.' It specifies the verb ('Get') and resource ('activity feed'), and mentions the types of actions included. However, it doesn't explicitly differentiate from sibling tools like 'get_current_user' or other 'get_' tools that might also retrieve user-related data, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'Use this to see what users are doing or what content is popular.' This implies when to use the tool (for monitoring activity or popularity), but it doesn't offer explicit guidance on when to choose this over alternatives like 'get_current_user' for user-specific data or other 'list_' tools for broader content. No exclusions or clear alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 adds valuable context: 'Risk: Moderate - executes queries to generate SQL.' This warns that the tool may trigger query execution (potentially resource-intensive) and clarifies the moderate risk level. However, it doesn't detail response format, error handling, or rate limits, which would enhance transparency further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the purpose clearly, and the second adds risk context. Both sentences earn their place by providing essential information. However, the emoji and bracketed risk label add slight clutter without adding critical value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers purpose and risk, but lacks details on return values (e.g., SQL string format), error cases, or performance implications. For a tool with moderate risk and two parameters, this leaves gaps that could hinder agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (cardId and parameters). The description adds minimal param semantics beyond the schema, only implying that parameters affect SQL generation. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with additional details like parameter format examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the generated SQL for a query-builder card with parameters.' It specifies the verb ('Get'), resource ('generated SQL'), and context ('query-builder card with parameters'). However, it doesn't explicitly differentiate from siblings like execute_card_query or execute_query_builder_card, which likely execute queries rather than just retrieving SQL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: 'Use this to see the actual SQL that Metabase generates from query builder parameters.' This suggests it's for inspection/debugging rather than execution. However, it doesn't explicitly state when to use this vs. alternatives (e.g., execute_card_query for running queries) or any prerequisites/exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key traits: the operation is read-only ('does not modify data'), may have performance implications ('may take time for complex queries'), and carries moderate risk due to resource intensity. However, it lacks details on error handling or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and risk information in three concise sentences. Each sentence earns its place by adding distinct value: action, context, and behavioral transparency without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (moderate risk, potential slowness) and lack of annotations or output schema, the description is reasonably complete. It covers purpose, usage, and key behavioral traits, but could improve by detailing the return format or error conditions to fully compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('cardId' and 'parameters'). The description adds minimal value beyond the schema by mentioning 'query parameters (e.g., date filters, IDs)' in context, but does not provide additional syntax or usage details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('execute a saved card query') and resource ('card'), distinguishing it from siblings like 'get_card' (which likely retrieves metadata) or 'execute_native_query' (which might run raw SQL). It specifies the outcome ('return results') and clarifies the tool's role in data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('to get actual data from a card'), but does not explicitly state when not to use it or name alternatives. It implies usage for executing saved queries rather than creating or modifying them, which helps differentiate from other tools in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively adds context beyond basic functionality: it explicitly states 'Risk: None - read-only operation' and marks it as '[SAFE]', clarifying safety and permissions. However, it does not detail rate limits, error handling, or output format, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information (action, resource, safety) in three concise sentences. Each sentence earns its place: the first states the purpose, the second provides usage context, and the third clarifies risk. There is no wasted text, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and safety adequately. However, it lacks details on the return value (e.g., what 'card ID and parameters' look like) and any prerequisites (e.g., URL format requirements), which could be helpful for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'url' parameter documented as 'The full Metabase dashboard URL with encoded parameters'. The description adds marginal value by reinforcing the parameter's purpose ('from dashboard URL' and 'Metabase dashboard URLs with filters'), but does not provide additional syntax, format examples, or constraints beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a card with applied parameters') and resource ('from dashboard URL'), distinguishing it from siblings like 'get_card' (which likely retrieves card metadata without parameters) and 'execute_card_query' (which executes queries). The mention of extracting 'card ID and parameters from Metabase dashboard URLs with filters' adds precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('Use this to extract card ID and parameters from Metabase dashboard URLs with filters'), but does not explicitly state when not to use it or name alternatives among siblings (e.g., 'get_card' for unfiltered cards or 'execute_card_query' for running queries). The guidance is helpful but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it explicitly states 'Risk: None - read-only operation' and includes a safety emoji '[SAFE]', which informs the agent about the operation's nature and safety. However, it lacks details on rate limits, pagination, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the core purpose, includes usage guidance and risk information in a single, efficient sentence. Every part adds value without waste, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (read-only, 2 parameters), no annotations, and no output schema, the description is mostly complete: it covers purpose, usage, and safety. However, it lacks details on output format or error handling, which could be helpful for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the 'models' filter usage or 'collectionId' nuances. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'all items (cards, dashboards, models) in a specific collection', specifying the scope. It distinguishes from siblings like list_cards, list_dashboards, etc., by focusing on collection-specific content rather than general listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Use this to see what content is organized in a folder.' It implies when to use this tool (for collection-based exploration) but does not explicitly state when not to use it or name alternatives among siblings, such as list_cards for broader listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a 'read-only operation' with 'Risk: None', and specifies the type of information returned ('engine type and connection details'), which is valuable context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with three concise sentences that each add value: stating the purpose, providing usage context, and disclosing behavioral traits. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 is largely complete. It covers purpose, usage, and safety, though it could slightly enhance completeness by hinting at the return format (e.g., structured data vs. raw details) given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents the 'databaseId' parameter thoroughly. The description does not add any additional meaning or context about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get database information') and resources ('by ID including engine type and connection details'), and distinguishes it from siblings like 'list_databases' by focusing on individual database retrieval rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('Use this to understand which database a card connects to'), but does not explicitly mention when not to use it or name specific alternatives among the many sibling tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states the operation is 'read-only' and 'Risk: None', which clearly communicates safety and non-destructive behavior. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and what information is retrieved, the second provides usage guidance and risk assessment. Every element adds value with no wasted words, and it's appropriately front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description does well by explaining the purpose, usage context, and safety. However, it doesn't describe the return format (e.g., what 'detailed information' includes structurally) or potential error cases, which would help an agent handle responses better. The safety disclosure partially compensates for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter 'fieldId' is fully described in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples of field IDs or how to obtain them, but doesn't need to compensate for gaps either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific field/column', specifying what information is retrieved (type, description, metadata) and why (to understand what a column contains). It distinguishes from siblings like get_field_values (which retrieves data values) and get_table_metadata (which focuses on table-level info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('to understand what a column contains'), but does not explicitly state when not to use it or name specific alternatives. It implies usage for metadata retrieval rather than data retrieval, which helps differentiate from some siblings, but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: the operation is read-only and safe ('[SAFE]', 'Risk: None - read-only'), potential performance considerations ('may return large results'), and a specific use case for high-cardinality fields. It does not cover aspects like rate limits or authentication needs, but provides sufficient context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage context and risk information in three concise sentences. Every sentence adds value: the first states the action, the second provides usage guidance, and the third addresses safety and performance. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is largely complete. It covers purpose, usage, safety, and performance considerations. However, it lacks details on output format (e.g., structure of returned values) and any pagination or limits, which would be helpful given the mention of 'large results'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with fieldId documented as 'The ID of the field'. The description adds no additional parameter semantics beyond implying the field relates to a 'column', which is redundant with the schema. Baseline score of 3 is appropriate as the schema fully covers parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get distinct values for a field') and resource ('a field'), distinguishing it from siblings like get_field (which retrieves field metadata) or execute_query_builder_card (which runs queries). It explicitly mentions the purpose is 'useful for understanding what values exist in a column,' providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('useful for understanding what values exist in a column') and mentions a specific scenario ('May return many values for high-cardinality fields'). However, it does not explicitly state when not to use it or name alternatives among the sibling tools, such as execute_native_query for more complex filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively communicates the safety profile ('[SAFE]', 'Risk: None - read-only operation'), which is crucial for a metadata tool. It also hints at the comprehensive nature of the output ('detailed metadata', 'including all columns, data types, and foreign key relationships'), though it doesn't specify format, pagination, or error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose, usage context, and risk disclosure. Each sentence adds distinct value without redundancy. The use of emoji and bracketed labels ('[SAFE]') enhances readability while maintaining brevity. There's no wasted verbiage or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only metadata tool with no output schema, the description provides strong contextual completeness. It covers purpose, usage guidance, safety, and output scope. The main gap is the lack of output format details (e.g., JSON structure, nested objects), which would be helpful given the absence of an output schema. However, the description compensates well with clear behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'tableId' clearly documented as 'The ID of the table' with a minimum value constraint. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, such as explaining where to find table IDs or how they relate to other tools. The baseline score of 3 is appropriate given the schema's comprehensive coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get detailed metadata'), target resource ('for a specific table'), and scope ('including all columns, data types, and foreign key relationships'). It distinguishes from sibling tools like 'get_database_metadata' by focusing on table-level rather than database-level metadata, and from query execution tools by emphasizing structural understanding rather than data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('to understand table structure before writing queries'), which helps differentiate it from query execution siblings. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for related purposes, such as 'get_database_metadata' for broader context or 'list_database_tables' for table enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively adds context by explicitly stating it's a 'read-only operation' and 'Risk: None', which informs the agent about safety and permissions. However, it doesn't describe potential limitations like pagination, rate limits, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose, context, and risk. Each sentence adds value without redundancy, and it's front-loaded with the core functionality. The use of emoji and bracketed labels ('[SAFE]') enhances readability without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, usage context, and safety, but lacks details on output format or behavioral constraints like response size. For a simple read operation, this is adequate though not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single optional parameter 'namespace'. The description does not add any parameter-specific information beyond what the schema provides, such as examples of namespaces or when filtering is useful. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all collections'), identifies the resource ('collections (folders) in Metabase'), and explains their purpose ('organize cards and dashboards'). It distinguishes from siblings by focusing on collections rather than cards, dashboards, or other resources listed in sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('to understand the organizational structure'), but does not explicitly mention when not to use it or name specific alternatives. It implies usage for browsing collections rather than querying or managing items, which helps differentiate from tools like get_collection_items or list_cards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: explicitly declares safety ('[SAFE]', 'read-only'), performance characteristics ('may be slow with many cards', 'Can return large results'), and scope ('15k+ cards'). It doesn't mention pagination, rate limits, or authentication needs, but covers core behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then usage context, then behavioral notes. Every sentence adds value: safety labeling, use cases, performance warning. Slightly verbose with emoji and parentheticals, but information-dense and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no annotations but full schema coverage, the description provides good context: safety, performance, use cases. Missing output format details (no output schema), but covers most essential aspects given the tool's complexity. Could mention pagination or result structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description adds minimal value beyond schema ('with optional filtering'), not explaining parameter relationships or usage patterns. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('Metabase cards/questions') with specific scope ('with optional filtering'). It distinguishes from siblings like 'get_card' (single card) and 'execute_card_query' (run card) by emphasizing discovery and listing functions. The purpose is specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('to discover available cards, find cards by type, or see all questions in the system') and provides clear risk/performance context ('may be slow with many cards'). It differentiates from execution-focused siblings by positioning this as a discovery tool, though doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing safety ('[SAFE]', 'read-only operation') and risk ('Risk: None'), though it lacks details on pagination, sorting, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with key info (emoji, safety, purpose) in a single, efficient sentence with zero waste, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description covers safety and purpose adequately but could benefit from mentioning return format or limitations, given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter details are needed. The description appropriately does not add param info, earning a baseline 4 for matching the schema's simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('List') and resource ('all dashboards in Metabase'), and distinguishes it from siblings by specifying it's for discovery or finding by name, unlike get_dashboard which likely retrieves 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use ('to discover available dashboards or find dashboards by name'), but does not explicitly mention when not to use or name alternatives like get_dashboard, which could be inferred but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behavioral traits: moderate risk due to arbitrary SQL execution, read-only nature (implied by 'SELECT statements only recommended'), potential performance impacts ('can be slow or resource-intensive'), and security considerations ('Always validate SQL before executing'). However, it doesn't detail response format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences that each earn their place: risk warning, purpose and usage context, and behavioral guidance. It's front-loaded with the most critical information (risk level) and avoids unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and no output schema, the description provides good contextual completeness. It covers purpose, usage guidelines, risk factors, and behavioral constraints. The main gap is the lack of information about return values or error responses, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by reinforcing the query parameter's purpose ('SQL query to execute') and adding the recommendation for SELECT statements, but doesn't provide significant additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('execute') and resource ('ad-hoc native SQL query directly against a database'), and distinguishes it from sibling tools by mentioning 'when you need to run custom SQL that doesn't exist as a saved card' (differentiating from execute_card_query and execute_query_builder_card).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 this tool ('when you need to run custom SQL that doesn't exist as a saved card') and when not to use it ('Always validate SQL before executing'), with clear alternatives implied by referencing saved cards and sibling tools like execute_card_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explicitly stating 'read-only operation' and 'Risk: None'. It also discloses that it returns the SQL query, which is valuable behavioral context. It doesn't mention potential errors (e.g., invalid ID), rate limits, or authentication needs, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and risk disclosure. Every sentence earns its place: first states what it does, second when to use it, third safety profile. No wasted words, emoji adds visual cue without distraction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description provides good context: purpose, usage, safety. It could mention what exactly is returned (beyond 'including its SQL query') or error cases, but given the simplicity and lack of output schema, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'cardId' parameter. The description doesn't add any additional parameter semantics beyond what's in the schema (e.g., format examples, ID sourcing). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a Metabase card/question by ID'), resource ('card/question'), and scope ('including its SQL query'). It distinguishes this tool from siblings like 'list_cards' (which lists multiple cards) and 'execute_card_query' (which runs the query rather than retrieving metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when you need to see the SQL behind a specific question or analyze how a card is built'). It also distinguishes it from alternatives by specifying it's for retrieving a single card by ID (unlike 'list_cards' for multiple cards) and for getting metadata/SQL (unlike 'execute_card_query' for running queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explicitly stating 'read-only operation' and 'Risk: None', which informs the agent about safety. It also mentions what gets returned ('cards, layout, and parameters'), though it could provide more detail on response format or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose, usage context, and risk disclosure. Each sentence adds value without redundancy, and it's appropriately front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description provides good context about what's returned and safety. However, it could be more complete by mentioning potential error cases or response structure, though the absence of an output schema doesn't severely penalize it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single parameter (dashboardId). The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a dashboard by ID') and resource ('including all its cards, layout, and parameters'), distinguishing it from siblings like list_dashboards (which lists multiple dashboards) and get_card (which retrieves individual cards). The mention of 'all its cards' provides clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('to understand dashboard structure or see all questions in a dashboard at once'), providing clear context for its application. It distinguishes from siblings by focusing on comprehensive dashboard retrieval rather than listing or partial views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it declares the operation as 'read-only' and 'Risk: None', and specifies it lists 'all available databases'. This covers safety and scope, though it lacks details on output format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information (emoji, safety note, purpose) in a single, efficient sentence. Every part adds value: the emoji sets context, '[SAFE]' highlights safety, and the rest explains usage and risk with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema), the description is mostly complete: it covers purpose, safety, and usage. However, it lacks details on output format (e.g., list structure) and does not mention if it requires authentication, leaving minor gaps for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so the baseline is high. The description adds no parameter-specific info, which is fine for a parameterless tool, but it does not explicitly state 'no parameters needed', so it slightly underperforms a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available databases'), specifying it shows 'what data sources are connected to Metabase'. It distinguishes from siblings like 'get_database' (singular) and 'list_database_tables' (tables within a database).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: 'Use this to see what data sources are connected to Metabase', which implicitly guides when to use it. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'get_database' for a specific database.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: it's read-only (stated explicitly) and has no risk. However, it lacks details on output format, pagination, or error handling, which would be needed for a perfect score in this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and risk information in just two sentences. Every element (emoji, safety tag, risk note) adds value without waste, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is nearly complete: it covers purpose, usage, and safety. It lacks details on return values (e.g., table structure or format), but for a simple list tool, this is a minor gap, not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents the single parameter (databaseId). The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain databaseId further), resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all tables') and resource ('in a specific database'), distinguishing it from sibling tools like list_databases (which lists databases) or list_cards (which lists cards). The inclusion of the emoji and '[SAFE]' tag enhances clarity without being redundant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('to see what tables are available before querying'), providing clear context for its purpose. This helps differentiate it from query-execution siblings like execute_card_query or execute_native_query, guiding the agent on preparatory vs. operational use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by explicitly stating 'Risk: None - read-only operation' and marking it as '[SAFE]'. It discloses the behavioral trait of being read-only, which is crucial for a tool with no parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information (purpose and safety), uses emojis and formatting effectively, and every sentence adds value without waste. It is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough by explaining what metrics are and the read-only nature. However, it lacks details on return format or pagination, which could be helpful but is not critical for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description adds no parameter details, which is appropriate here. Baseline is 4 for 0 parameters, as it doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all metrics (saved aggregations) in Metabase'), with specific examples ('Total Revenue', 'Average Order Value') that help distinguish it from sibling tools like list_cards or list_dashboards. It precisely defines what metrics are in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 ('List all metrics') and implies usage for retrieving reusable calculations. However, it does not explicitly state when not to use it or name alternatives among siblings (e.g., list_cards for other saved items), though the specificity helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states 'Risk: None - read-only operation', which clearly indicates safety and non-destructive behavior. It also adds context by describing segments as 'saved filters', though it lacks details on output format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information (purpose, safety, examples) in three concise sentences with zero waste. Each sentence earns its place: the first states the action, the second explains segments, and the third addresses risk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is mostly complete by covering purpose, examples, and safety. However, it lacks details on the return format (e.g., list structure or fields), which could be helpful for an agent despite the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. A baseline of 4 is given as it compensates adequately for the lack of parameters by focusing on the tool's purpose and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('List all') and resource ('segments (saved filters) in Metabase'), with examples ('Active Users', 'Premium Customers') that concretely illustrate what segments are. It distinguishes itself from sibling tools like list_cards or list_dashboards by specifying the exact resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that segments are 'reusable filters' and listing examples, which helps an agent understand when this tool is appropriate. However, it does not explicitly state when not to use it or name alternatives (e.g., for non-saved filters or other list operations), missing full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels by explicitly stating the safety profile ('[SAFE]', 'Risk: None - read-only operation'). This clearly communicates the tool's non-destructive, permission-required nature, going beyond what the input schema alone would indicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose first, followed by critical safety information. Every sentence earns its place - the emoji adds visual distinction, the safety declaration is essential given no annotations, and the risk statement provides valuable context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description provides excellent coverage of purpose and safety. The main gap is not describing the return format or what user information is included, but given the tool's simplicity and clear safety declaration, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get information') and target resource ('currently authenticated user'), with the parenthetical '(you)' adding helpful clarification. It distinguishes this from sibling tools like 'list_users' by focusing on the current user rather than listing all users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Get information about the currently authenticated user'), but doesn't explicitly mention when not to use it or name specific alternatives. It implies usage for retrieving self-information rather than querying other users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden and does well by disclosing: permission requirements ('Requires admin permissions'), safety profile ('SAFE - REQUIRES ADMIN', 'Risk: None - read-only'), and failure conditions ('may fail if not admin'). It doesn't mention pagination, sorting, or return format details, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with key information (purpose, safety, permissions) in a single, efficient sentence. Every phrase adds value: the emoji reinforces purpose, bracketed tags highlight critical info, and the risk statement clarifies behavior. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter read-only tool with no output schema, the description is nearly complete: covers purpose, usage, permissions, and safety. It lacks details on return format (e.g., list structure, fields included) which would be helpful for an agent, but given the simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter-specific information (as there are none), which is appropriate. It could theoretically score 5 if it explicitly noted 'no parameters needed', but the current text is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all Metabase users') and resource ('Metabase users'), distinguishing it from sibling tools like get_current_user (single user) or other list_* tools (different resources). The inclusion of '👥' emoji reinforces the user-focused purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use this to see who has access to Metabase') and provides clear prerequisites ('Requires admin permissions'). It also distinguishes from alternatives by specifying this lists ALL users, unlike get_current_user which returns only the current user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers excellent behavioral disclosure. It explicitly states '[SAFE]' and 'Risk: None - read-only', clarifies it 'may return large amounts of data' and 'returns large payloads', and warns about comprehensiveness - all crucial behavioral traits not in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly front-loaded with the core purpose in the first sentence, followed by usage guidance and risk information. Every sentence earns its place with zero wasted words, making it highly efficient while remaining comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 100% schema coverage but no annotations or output schema, the description provides complete context. It covers safety, behavioral characteristics (large payloads), usage guidance, and distinguishes from siblings - everything an agent needs to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'databaseId' parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'complete metadata for a database', specifying it includes 'ALL tables, columns, and field types'. It distinguishes from siblings like 'get_table_metadata' by emphasizing comprehensiveness and full database schema understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when you need to understand the full database schema', providing clear when-to-use guidance. It contrasts with siblings by specifying this tool returns comprehensive metadata rather than partial or specific components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![metabase-mcp-mab MCP server](https://glama.ai/mcp/servers/MikelA92/metabase-mcp-mab/badges/card.svg)](https://glama.ai/mcp/servers/MikelA92/metabase-mcp-mab)

Score Badge

Copy to your README.md:

[![metabase-mcp-mab MCP server](https://glama.ai/mcp/servers/MikelA92/metabase-mcp-mab/badges/score.svg)](https://glama.ai/mcp/servers/MikelA92/metabase-mcp-mab)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MikelA92/metabase-mcp-mab'

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