metabase-lite-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action (cards vs dashboards vs databases). The only potential overlap is copy_card vs create_card, but descriptions clearly distinguish duplication from fresh creation. Search vs get follows standard patterns, and all tools have clear boundaries.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case (get_, search_, create_, update_, move_, add_, remove_, ensure_, run_). Even copy_card fits the convention. No camelCase or mixed verb styles.
Tool Count4/5
17 tools is slightly above the typical 3-15 range but is justified for the domain, covering cards, dashboards, and database metadata. Each tool has a legitimate purpose, and the set is not bloated with redundant utilities.
Completeness3/5
The set covers CRUD for cards (create, read, update, copy/move) and dashboards (create, read, update, add/remove cards, filters), but lacks delete operations for both cards and dashboards. Missing direct get_dashboard (only full) but full supersedes. These are notable gaps that prevent full lifecycle management.
Average 3.6/5 across 17 of 17 tools scored. Lowest: 2.9/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
This repository is licensed under MIT License.
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

Behavior2/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 only mentions the search scope ('name or text') but does not describe return format, pagination, case sensitivity, or permission requirements.
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 a single concise sentence, easy to read and front-loaded. However, it is so brief that it sacrifices substance for brevity, which is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain return values or behavior. It does none of that. For a tool with only two parameters, this minimal description is insufficient for an agent to understand the full behavior.
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% coverage with descriptions for both parameters (query and limit). The description adds minimal extra meaning beyond the schema, essentially restating that searches are by name or text.
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 action ('Search') and the resource ('dashboards'), specifying the criteria ('by name or text'). This differentiates it from sibling tools like search_cards, though it doesn't explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_cards or get_dashboard_full. No context or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It merely states 'Create a new dashboard' but does not disclose whether the operation requires specific permissions, what the return value is, or whether it is idempotent. This is too thin for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately sized for a tool with a clear primary action and does not repeat schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, yet the description provides no information about return values, side effects, or operational context. The schema covers parameter names but not nesting rules (e.g., the empty items schema for parameters). The description does not fill this gap, making it incomplete for an agent to use confidently.
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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter semantics, leaving the schema to carry the full weight. This is adequate for simple parameters, but it does not clarify semantics for nested fields like tabs or parameters.
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 action ('Create') and the resource ('a new dashboard in Metabase'), making the tool's purpose unambiguous. It is effectively distinguished from sibling tools like update_dashboard, which implies a different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_dashboard or add_card_to_dashboard. There is no mention of prerequisites or typical workflow context, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get') but does not mention the write side effect implied by the output_file parameter, nor does it describe response format, whether the function returns JSON in addition to writing to a file, or any auth/rate-limit requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose ('Get full dashboard details') and enriched with specific inclusions. Every word adds value; no unnecessary elaboration.
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 low-complexity tool with two parameters and no output schema, the description provides the essentials: what it returns and where results go. However, ambiguity remains about whether the function also returns the JSON directly or only writes to the file, and it does not cover potential errors or limitations of the 'full' representation.
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 coverage is 100%, with both parameters described ('Dashboard ID' and 'file path where full JSON results will be written'). The description adds context about the contents (tabs, dashcards, parameters), which helps understand the output_file meaning, but does not add parameter-specific syntax or formatting details beyond the schema.
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 ('full dashboard details'), and specifies relevant components (tabs, dashcards, parameters). It distinguishes itself from sibling tools like search_dashboards (search vs full retrieval) and create/update dashboard tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, such as obtaining a dashboard ID via search_dashboards, or when not to use it (e.g., for lighter-weight metadata). The description simply restates its purpose without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Create a new card' without mentioning authentication needs, validation behavior, possible side effects, or what happens on success or failure. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. It is appropriately sized and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the rich schema, the description lacks context about the creation process, return values, or potential errors. As a mutation tool without annotations or an output schema, it should provide more behavioral and contextual guidance to the agent.
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 all parameters. The description adds no parameter-specific information, which matches the baseline of 3 for full 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 uses a specific verb 'Create' and a specific resource 'a new card (saved question) in Metabase'. This clearly distinguishes it from sibling tools like copy_card, update_card, or get_card.
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 that this tool is for creating new cards, but it does not explicitly state when to use it versus alternatives like copy_card or update_card. No exclusions, prerequisites, or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It states the operation ('Create/update') but does not explain whether it is idempotent, how it handles existing filters or mappings, whether it replaces or merges, or what side effects may occur. The name 'ensure' suggests idempotency, but this is not confirmed in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and clearly specifies the object and scope. Every word contributes meaning, with no redundancy or filler. It is appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutating operation with no annotations and no output schema. The description explains the primary function but omits critical contextual details such as idempotency guarantees, behavior when filters already exist, handling of dashcard IDs, and any required permissions or constraints. Given the moderate complexity and the absence of annotations, the description is incomplete.
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% coverage with descriptions for all three parameters (dashboard_id, filters, apply_to_dashcard_ids), including nested details. The description adds no additional parameter-level meaning beyond what the schema provides. This aligns with the baseline of 3 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 function: 'Create/update dashboard parameters (filters) and wire them to card variables on specified dashcards'. It uses specific verbs and identifies both the resource (dashboard parameters/filters) and the additional action (wiring to card variables), which distinguishes it from sibling tools like update_dashboard or add_card_to_dashboard.
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 the use case: configuring dashboard filters and connecting them to card variables. However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. The context is clear but the guidance is not explicit, so it falls short of a 4 or 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to mention that the tool writes full JSON results to an output_file path, which is a significant side effect. The description only covers the retrieval aspect, omitting the file-writing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose. It contains no redundant or filler content, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical context about the output_file side effect and does not explain the return value format (no output schema is present). For a tool that writes results to a file, this is a notable gap. The description only partially conveys what the tool does, leaving important aspects undisclosed.
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% with clear descriptions for both database_id and output_file. The description adds no extra parameter-level meaning, but since the schema already fully documents parameters, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'schema, tables, and fields for a specific database'. This clearly distinguishes it from sibling tools like get_configured_databases (which lists databases) or get_card (which retrieves a card), making the purpose unambiguous.
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 the tool is used to retrieve database metadata but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions, prerequisites, or alternative tool references are provided, so guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It notes 'safe iteration' implying the original is unchanged, but does not state the new card is created, whether any permissions are needed, or what happens to associated data. The description provides minimal behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, entirely focused on the tool's purpose.
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?
The tool is simple and the schema is comprehensive, but there is no output schema and the description does not mention return values or side effects beyond duplication. It is adequate but not fully 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 all three parameters. The description adds no parameter-specific meaning, aligning with the baseline 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 action ('Duplicate') and resource ('a card'), with a purpose ('safe iteration or re-use'). This distinguishes it from siblings like create_card, update_card, and move_card.
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 phrase 'safe iteration or re-use' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives like create_card or move_card. No when-not conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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, but it only says 'Get full details.' It does not mention that results are written to an output_file, whether that file is overwritten, permissions required, or what 'full details' includes. The output_file parameter implies a side effect, but this is in the schema, not the description, so the description adds little transparency.
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 one concise sentence that front-loads the key verb, resource, and scope. It contains no filler or redundant information, and the parenthetical clarification is valuable and efficiently phrased.
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 retrieval tool with two self-describing required parameters, the description is largely sufficient. The lack of an output schema or more detailed behavior is offset by the clear 'full details' intent and the output_file parameter, though it does not offer guidance on how to obtain the card ID or contrast with search tools.
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 fully describes both parameters: id is 'Card ID' and output_file is 'File path where full JSON results will be written.' The tool description adds only that this is for a specific card, reinforcing the semantic but not going beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate.
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 action ('Get full details') and the resource ('a specific card'), with a clarifying parenthetical that a card is a saved question. It distinguishes itself from sibling tools like search_cards (searching) and update_card (modifying) by implying a direct lookup by ID.
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 this tool is for retrieving a specific known card, but it does not explicitly state when to use it versus searching for cards with search_cards or copying with copy_card. No exclusions or alternative tool guidance is provided, leaving usage mostly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. The word 'List' implies a read-only operation, and the description mentions the return fields (id, name, engine), which gives some indication of output. However, it does not disclose potential limitations like permissions, pagination, or what happens if no databases are found. For a simple list tool, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action ('List all databases') and includes the key return fields in parentheses. Every word serves a purpose, with no unnecessary detail or restating of the tool name.
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 zero-parameter list tool with no output schema, the description provides complete context: it states the scope ('all databases configured in Metabase') and the fields returned (id, name, engine). This fully covers what the agent needs to know to invoke and interpret the 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?
This tool has zero parameters, so there is no parameter information to convey. The baseline score for a zero-parameter tool is 4, and the description need not explain anything further. The schema is empty and coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all databases configured in Metabase, with the specific fields returned (id, name, engine). The verb 'List' and resource 'all databases configured in Metabase' make it specific and unambiguous. However, it does not explicitly distinguish from the sibling tool get_database_metadata, which might retrieve details for a single database, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_database_metadata. It simply states what it does, leaving the agent to infer usage from the tool name and sibling context. There is no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It does state the tool is read-only and that it 'Validates queries are read-only before execution,' which adds safety context. However, it does not clarify whether the function returns preview rows directly, whether it overwrites 'output_file', or any error/limit behaviors. The file-writing side effect is only briefly hinted at via the schema's 'output_file' description.
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 two sentences, direct, and front-loaded with the main action. Every word adds value: it names the operation, the resource, the read-only guarantee, and the validation step. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should clarify the return value and side effects. It says 'return results' and that 'full JSON results will be written' to output_file, but it does not explain what the function actually returns (e.g., a preview subset, a status code) or whether output_file is overwritten. The nested dataset_query structure and constraints are well-documented in the schema, but the tool's runtime behavior remains ambiguous.
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 all parameters (dataset_query, output_file, parameters, constraints) already have descriptive text in the schema. The description adds no additional param-level meaning beyond the overall 'read-only' intent. This meets the baseline for full schema coverage with no extra value from the description.
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 function: 'Execute a read-only query preview and return results.' It uses a specific verb ('execute'), identifies the resource ('query preview'), and adds the key characteristic of read-only with validation. This distinguishes it from sibling tools that cover CRUD operations on cards/dashboards, none of which execute queries.
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 usage context is implied by 'read-only query preview' and the error-checking behavior ('Validates queries are read-only before execution'). However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any siblings or exclusions. Since there is no sibling that also runs queries, the purpose is reasonably clear, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add the key behavioral trait that 'Only provided fields are changed', which clarifies partial update semantics. However, it does not disclose permissions, reversibility, return value, or error behavior, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 10 words. It conveys the core action and a key semantic without any wasted words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema is rich for the patch object, the description omits crucial operational details such as what the tool returns, error conditions, and prerequisites. Since there is no output schema, the description should at least hint at the response, but it does not. The complex dataset_query structure would also benefit from additional usage context, making the tool under-specified overall.
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?
Schema descriptions cover both parameters ('Card ID' and 'Fields to update'), meeting the high coverage baseline. The description adds useful meaning beyond the schema by stating that only provided fields are changed, which enriches understanding of the 'patch' parameter.
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 states 'Update an existing card (saved question)' with a specific verb and resource, and clarifies partial update behavior. It clearly differentiates from sibling tools like get_card, create_card, copy_card, and move_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., create_card for creation, get_card for retrieval, copy_card for duplication). The usage is implied from the verb 'update' but no explicit exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states the search action without mentioning whether it is read-only, how results are returned, pagination behavior, or any matching nuances. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that packs in the essential information without any fluff or redundancy. Every word contributes to understanding the tool's purpose.
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 simplicity of the tool (2 parameters, no output schema), the description is adequate but lacks usage guidance and behavioral specifics. It does not state what the search returns or how to handle edge cases, leaving some gaps for the agent.
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?
Although the schema already describes both parameters with 100% coverage, the description adds meaningful context by specifying that the query searches by name or text. This clarifies the query semantics beyond the schema's generic 'Search query'.
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 action ('Search'), the resource ('cards' with clarification 'saved questions'), and the search scope ('by name or text'). It effectively distinguishes this tool from siblings like search_dashboards and get_card.
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 that this tool is for text-based searching of cards, but does not explicitly state when to use it over alternatives or provide exclusions. For example, it does not mention that get_card should be used for retrieving a specific card by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly indicates a read operation ('List all'), so an agent can infer it is non-destructive. However, there are no annotations and no additional behavioral details such as pagination, permissions, or ordering. The lack of explicit safety disclosure is mitigated by the obvious read-only nature, but it could be more informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is concise and to the point, using the exact pattern 'verb + resource'.
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 list tool, the description 'List all collections in Metabase' is sufficient to convey the scope and purpose. There is no output schema, but the return value (list of collections) is reasonably implied. It could mention that it returns all collections without filtering, but 'all' already conveys this.
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, so there are no parameter semantics to clarify. Per the rubric baseline for 0 params, this is a 4.
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 uses a specific verb ('List') and resource ('collections in Metabase'), clearly stating the tool's function. It distinguishes itself from sibling tools like get_configured_databases and get_database_metadata by targeting collections specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_cards or search_dashboards. It does not mention e.g., 'use this to get all collections, or search_cards to filter'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds the useful clarification that the card is not deleted, allaying a common concern about move operations. However, it does not mention other side effects such as removal from the current collection, permission requirements, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a helpful parenthetical. There is no wasted text, and the key information is 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 simple move operation with two clearly described parameters and no output schema, the description is largely sufficient. It could be slightly more complete by mentioning the alternative tool or the effect on the original collection, but the core information is present.
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 already provides complete descriptions for both parameters, both listed in the schema properties. The description adds no additional parameter-specific meaning 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 action ('Move'), the resource ('a card'), and the destination ('a different collection'). It distinguishes from sibling tool copy_card by using 'move' rather than 'copy', and the parenthetical clarifies the non-destructive nature of the operation.
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 when to use the tool (when a card needs to be relocated) but does not explicitly contrast with alternatives such as copy_card, nor does it state when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 does disclose the key non-destructive trait (the card remains intact), but it does not specify other behaviors such as whether the removal is permanent or reversible, or how the dashboard layout is affected. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action and an important caveat. Every word earns its place, with no redundancy or filler.
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 two-parameter tool with no output schema, the description is complete enough: it states the operation and a key behavioral nuance. It does not explain return values or error conditions, but these are not necessary given the tool's simplicity and the schema's clarity.
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 already provides full coverage for both parameters (dashcard_id and dashboard_id) with clear descriptions. The tool description adds no additional context about these parameters, so the schema's baseline of 3 is appropriate.
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 identifies the tool's function: removing a dashcard from a dashboard. It adds the important qualifier 'the card itself remains intact,' which distinguishes it from delete or move operations and directly addresses potential confusion with sibling tools like copy_card or move_card.
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 when to use this tool (when you want to remove a dashcard but keep the underlying card), but it does not explicitly state alternatives or when not to use it. There is no comparison to sibling tools like delete_card or add_card_to_dashboard, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It discloses a useful behavior: 'Auto-packs if no placement given.' However, it does not mention side effects, permission requirements, or what happens on invalid tab/placement. This adds some transparency but lacks depth.
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 two short sentences with no filler. It front-loads the core purpose and includes a key behavioral note. Every sentence earns its place, making it highly concise 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 (5 parameters, nested object, no output schema), the description provides the essential purpose and a key behavior. The schema covers parameter details, so the description is sufficient for an agent to select and invoke the tool correctly. It lacks return value or error handling info, but these are not critical for a simple add operation.
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 descriptions cover 100% of parameters, so the baseline is 3. The description adds minimal context beyond the schema, only mentioning optional 'tab and position' and the 'auto-packs' behavior, which relates to the placement parameter's defaults. This is a slight enhancement, but not enough to raise the 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 tool's function with a specific verb ('Place') and resource ('a saved card on a dashboard'). It distinguishes from siblings by emphasizing 'saved card' and dashboard placement, differentiating it from create_card, copy_card, and move_card.
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: it is for adding an existing saved card to a dashboard, with optional tab and position. It implies a prerequisite ('saved card') and the 'optionally' phrasing signals when placement is not required. However, it does not explicitly name alternatives or exclusion cases.
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?
No annotations are provided, so the description carries the full burden. It discloses two important behaviors: only provided fields are changed (partial update) and a GET-then-PUT pattern is used for safety. This adds meaningful context beyond the name, though it omits return values and 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 two sentences, front-loaded with the action, and contains no filler. Each sentence adds meaningful information: the first defines purpose, the second explains update semantics and safety mechanism.
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 has nested objects and no output schema, the description adequately covers the core update behavior but lacks information about return values, error handling, permissions, or limitations. More detail on these aspects would improve completeness.
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?
Schema coverage is 100% for both parameters. The description adds value by clarifying that the 'patch' parameter is a partial update, meaning unspecified fields remain unchanged—this is not explicit in the schema and helps the agent understand the merge 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 begins with 'Update an existing dashboard,' clearly stating the verb and resource. It distinguishes from siblings like create_dashboard and get_dashboard_full by emphasizing the update action and partial-update semantics.
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 purpose is clear, but there is no explicit guidance on when to use this tool versus alternatives such as create_dashboard or add_card_to_dashboard. Usage is implied from the name and action, but no when/when-not context is provided.
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-lite-mcp MCP server](https://glama.ai/mcp/servers/Sanjeev4523/metabase-lite-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Sanjeev4523/metabase-lite-mcp)

Score Badge

Copy to your README.md:

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

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/Sanjeev4523/metabase-lite-mcp'

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