Metabase MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools are distinct by resource and action, but there is notable overlap between get_dashboard_cards, get_dashboard_items, and get_dashboard_by_id, which could confuse agents about which to use for retrieving dashboard content. Additionally, execute_sql_query and get_card_query_results serve different purposes but might be conflated for query execution.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a clear verb_noun structure (e.g., create_metabase_card, delete_metabase_user, update_metabase_dashboard). The prefix 'metabase' is uniformly applied, and verbs like get, create, update, delete are used predictably across resources.
Tool Count2/5
With 30 tools, this server is overly heavy for typical MCP usage, likely causing cognitive overload and inefficiency. While Metabase is a complex platform, the tool set could be more streamlined by consolidating overlapping getters or removing less critical operations to improve usability.
Completeness5/5
The tool set provides comprehensive CRUD coverage for all major Metabase entities (cards, dashboards, collections, databases, groups, users), plus auxiliary operations like copying dashboards and executing SQL queries. There are no obvious gaps; agents can perform full lifecycle management and query execution seamlessly.
Average 3.3/5 across 30 of 30 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 5 community issues answered or closed in the last 6 months
- 8 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 Apache 2.0.
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?
No annotations are provided, so the description carries full burden. While 'Delete' implies a destructive mutation, the description doesn't disclose critical behavioral traits: whether deletion is permanent or reversible, what permissions are required, whether it affects dependent resources, or any rate limits. The 'Returns' section mentions a confirmation but doesn't describe its structure or meaning.
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 with three sentences: purpose, args, and returns. It's front-loaded with the main action. The structure is clear but could be more efficient by integrating the parameter explanation into a single cohesive paragraph.
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 that this is a destructive mutation tool with no annotations and an output schema exists (though not shown), the description is minimally complete. It covers the basic purpose and parameter, but lacks important context about behavioral implications, error conditions, and usage guidelines that would be crucial for safe 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 description adds the parameter 'card_id' with type 'int' and explanation 'ID of the card to delete', which provides basic semantics. However, with 0% schema description coverage and only 1 parameter, this is adequate but minimal. It doesn't explain where to find the card ID, format constraints, or validation rules.
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 'Delete a card from Metabase' which is a specific verb+resource combination. It distinguishes this from sibling tools like 'create_metabase_card' or 'update_metabase_card' by specifying the destructive delete operation. However, it doesn't explicitly differentiate from other delete operations like 'delete_metabase_dashboard' beyond the 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 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. There's no mention of prerequisites (e.g., needing the card ID), when not to use it (e.g., for soft deletion), or what happens after deletion. With multiple sibling delete tools, explicit differentiation would be helpful.
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 the full burden. It states the tool deletes a collection and returns a confirmation, but lacks critical behavioral details: whether deletion is irreversible, permission requirements, effects on nested items, or error handling. For a destructive operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured but slightly verbose for a single parameter; every sentence earns its place by clarifying inputs and outputs efficiently.
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 (destructive operation), lack of annotations, and presence of an output schema (which handles return values), the description is partially complete. It covers the basic action and parameter but misses critical context like safety warnings or usage prerequisites, making it adequate with clear gaps.
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 0%, but the description compensates by documenting the single parameter 'collection_id' with its type and purpose. However, it doesn't add meaning beyond the schema (e.g., valid ID ranges or sourcing methods). With one parameter and partial compensation, this meets the baseline for minimal viability.
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 ('Delete') and resource ('a Metabase collection'), making the purpose unambiguous. It distinguishes from siblings like 'get_metabase_collection' or 'update_metabase_collection' by specifying deletion. However, it doesn't explicitly differentiate from other delete tools (e.g., 'delete_metabase_card'), which slightly limits sibling differentiation.
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. It doesn't mention prerequisites (e.g., needing collection ID from 'get_metabase_collection'), exclusions (e.g., not for non-existent collections), or comparisons with other deletion tools in the sibling list. This leaves the agent without contextual usage cues.
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. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what happens with invalid dashboard IDs. The description mentions the return type but doesn't explain the structure or content of the returned items.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose, though the 'Returns' section could be slightly more informative about what 'All items' encompasses.
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 operation with one parameter and an output schema, the description is minimally adequate. However, with no annotations and multiple similar sibling tools, it should provide more context about differentiation, authentication requirements, and error handling to be truly 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?
The description explicitly documents the single parameter 'dashboard_id' and its purpose ('ID of the dashboard'), which adds meaningful context beyond the schema's 0% description coverage. However, it doesn't provide format details (e.g., where to find this ID, valid ranges) or examples, leaving some gaps in parameter understanding.
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 verb ('Get') and resource ('all items in a dashboard'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'get_dashboard_by_id' or 'get_dashboard_cards', which appear to have overlapping functionality in the same domain.
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_dashboard_by_id' or 'get_dashboard_cards'. It doesn't mention prerequisites, exclusions, or specific contexts where this tool is preferred over similar sibling tools.
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 full burden for behavioral disclosure. It states this is an update operation but doesn't mention permission requirements, whether partial updates are allowed, what happens to unspecified fields, or any rate limits. The 'Returns' section describes output but doesn't cover error conditions or side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (Args, Returns) but is overly verbose due to listing all 16 parameters with brief descriptions. While this provides necessary information given the poor schema coverage, it makes the description lengthy. The core purpose statement is front-loaded, but the parameter list dominates the content.
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 complexity (16 parameters, mutation operation, no annotations) and the existence of an output schema, the description is partially complete. It covers parameters extensively but lacks behavioral context about permissions, partial updates, and error handling. The output schema handles return values, so the description appropriately focuses on inputs, but more behavioral guidance is needed for a mutation 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 description provides a comprehensive parameter list with brief explanations for all 16 parameters, adding significant value beyond the input schema which has 0% description coverage. While the explanations are minimal (e.g., 'New name of the card'), they at least clarify what each parameter represents, which is essential given the schema's lack of descriptions. The required card_id is appropriately highlighted.
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 ('Update') and resource ('an existing card in Metabase'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling update tools like update_metabase_collection or update_metabase_dashboard, which follow the same pattern for different resources.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites (like needing an existing card_id), when not to use it, or how it differs from create_metabase_card or other sibling tools. The agent must infer usage from the tool name alone.
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. While it mentions the tool copies a dashboard and describes parameters, it doesn't disclose important behavioral traits: whether this requires specific permissions, whether the copy is immediate or asynchronous, what happens if the source dashboard doesn't exist, or whether there are rate limits. The 'is_deep_copy' parameter hint is useful but insufficient for full transparency.
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 well-structured with clear sections (Args, Returns). The opening sentence states the core purpose concisely. The parameter explanations are efficient, though the 'Returns' section could be more specific about what 'new dashboard metadata' includes. Overall, it's front-loaded and wastes little space.
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 mutation tool with 6 parameters and no annotations, the description is adequate but has gaps. The output schema exists, so return values don't need explanation. However, it lacks context about permissions, error conditions, and how this tool relates to siblings. Given the complexity of dashboard copying operations, more behavioral context would be helpful despite the parameter documentation.
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% schema description coverage, the description compensates well by explaining all 6 parameters in the Args section, adding meaning beyond the bare schema. It clarifies optional vs required parameters and provides semantic context for each (e.g., 'is_deep_copy' copies linked cards). However, it doesn't explain parameter constraints like valid ID ranges or name length limits.
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 verb 'copy' and resource 'dashboard', making the purpose evident. It distinguishes from siblings like 'create_metabase_dashboard' by specifying it's a copy operation rather than creating from scratch. However, it doesn't explicitly contrast with other dashboard-related tools like 'update_metabase_dashboard' or 'get_dashboard_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 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. With siblings like 'create_metabase_dashboard' and 'update_metabase_dashboard', there's no indication whether this should be used for duplicating existing dashboards versus creating new ones from templates or modifying existing ones. The description is purely functional without contextual guidance.
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 full burden but only states it 'creates' without detailing behavioral aspects. It doesn't mention whether this requires admin permissions, if collections are permanent or deletable, rate limits, or error conditions. The return type is mentioned but not elaborated.
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 well-structured with clear sections for Args and Returns. It's front-loaded with the core purpose, and each sentence adds value. Slightly verbose with 'Dict[str, Any]' but overall efficient.
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, 3 parameters with 0% schema coverage, and an output schema exists (though not shown), the description covers basics but lacks depth. It explains parameters and return type but misses behavioral context like permissions, side effects, or error handling that would be crucial for a creation 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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: name (required), color (optional hex code), and parent_id (optional parent collection ID). This adds meaningful context beyond the bare schema, though it doesn't explain format constraints like color validation.
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 creates a new Metabase collection, specifying the verb 'create' and resource 'Metabase collection'. It distinguishes from siblings like 'create_metabase_card' or 'create_metabase_dashboard' by focusing on collections, but doesn't explicitly contrast with similar creation tools beyond naming.
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 like 'update_metabase_collection' or 'get_metabase_collection'. The description lacks context about prerequisites, permissions needed, or typical workflows involving collection creation.
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 full burden but provides minimal behavioral context. It mentions the tool creates something and returns metadata, but doesn't disclose permission requirements, whether this is a write operation (implied but not stated), error conditions, rate limits, or what happens if a dashboard with the same name exists. The 'Returns' section adds some value but is basic.
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 clear sections (Args, Returns). The main description is a single clear sentence, and parameter explanations are efficient. Some minor verbosity in repeating 'optional' for each optional parameter, but overall very efficient.
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 creation tool with 7 parameters and no annotations, the description provides good parameter documentation and mentions the return type. However, it lacks important context about permissions, error handling, and behavioral constraints. The existence of an output schema helps, but the description should do more for a mutation tool with no safety annotations.
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% schema description coverage and 7 parameters, the description provides excellent parameter semantics. It clearly explains what each parameter represents (e.g., 'Name of the dashboard', 'Dashboard description', 'Collection ID', etc.) and indicates which are optional. This significantly compensates for the schema's lack of descriptions.
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 'Create a new dashboard in Metabase' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'copy_metabase_dashboard' or 'update_metabase_dashboard' - the agent must infer that 'create' means new vs 'copy' or 'update'.
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 on when to use this tool versus alternatives like 'copy_metabase_dashboard' or 'update_metabase_dashboard'. The description provides no context about prerequisites, permissions needed, or when this creation operation is appropriate versus other dashboard-related operations.
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. It states this is a deletion operation, implying it's destructive, but doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, what permissions are required, if there are side effects (e.g., orphaned resources), rate limits, or error conditions. The return value is mentioned but not elaborated beyond type.
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: the first sentence states the core purpose, followed by structured Args and Returns sections. Every sentence earns its place, though the Returns section could be more informative given the output schema exists. No wasted words, but slightly sparse for a destructive operation.
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 this is a destructive tool with no annotations, 0% schema coverage, but an output schema exists, the description is minimally adequate. It covers the basic purpose and parameter, but lacks behavioral context (safety, permissions, side effects) and usage guidance. The output schema mitigates the need to explain return values, but overall completeness is limited for a high-stakes operation.
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% schema description coverage and only 1 parameter, the description compensates well by explicitly documenting the parameter in the Args section: 'user_id (int): ID of the user to delete.' This adds essential meaning beyond the bare schema, clarifying the parameter's purpose and type. However, it doesn't specify format constraints (e.g., valid ID range) or 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 verb ('Delete') and resource ('a user from Metabase'), making the purpose immediately understandable. However, it doesn't differentiate from sibling delete tools (like delete_metabase_card, delete_metabase_collection, etc.) beyond specifying the resource type, which is somewhat implied by the tool name itself.
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 about when to use this tool versus alternatives. While sibling tools include create_metabase_user and get_metabase_users, the description doesn't mention prerequisites (e.g., user must exist), exclusions (e.g., cannot delete active users), or related operations. The agent must infer usage from context alone.
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 the full burden. It states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, error conditions, or what 'Query result data' entails (e.g., format, size, or pagination). The description is minimal and lacks critical operational context for a tool that likely interacts with a database system.
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, with the core purpose stated first. The 'Args' and 'Returns' sections are structured but slightly redundant since an output schema exists. Every sentence earns its place, though the 'Returns' line could be omitted given the output schema. It's efficient without being overly terse.
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 complexity (a query tool with no annotations), 0% schema coverage, but an output schema exists, the description is minimally complete. The output schema handles return values, so the description doesn't need to explain them. However, it lacks context on behavioral aspects (e.g., permissions, errors) and usage guidelines, making it adequate but with clear gaps for effective tool selection.
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% schema description coverage, the description must compensate. It adds meaning by explaining that 'card_id' is an 'ID of the card', which clarifies the parameter's role beyond the schema's generic 'integer' type. However, it doesn't provide details like valid ranges, where to find card IDs, or examples. Since there's only one parameter, the description adequately covers its semantics, but more context would be beneficial.
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 verb 'Get' and the resource 'results of a card's query', making the purpose understandable. It distinguishes from siblings like 'execute_sql_query' (which runs raw SQL) and 'get_metabase_cards' (which lists cards), but doesn't explicitly contrast with 'get_dashboard_cards' or 'get_dashboard_items' which might retrieve related metadata. The purpose is specific but sibling differentiation could be more explicit.
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. It doesn't mention prerequisites (e.g., needing an existing card), exclusions (e.g., not for dashboard queries), or direct comparisons to siblings like 'execute_sql_query' or 'get_dashboard_cards'. Usage is implied from the name and purpose alone, with no explicit context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get cards in a dashboard,' which implies a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, error handling, or what 'cards' entail (e.g., metadata, content, or both). This leaves significant gaps for safe and effective use.
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 well-structured and concise, with a clear purpose statement followed by separate 'Args' and 'Returns' sections. Every sentence serves a purpose without redundancy, making it easy to parse and understand 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?
Given the tool's low complexity (1 parameter) and the presence of an output schema (implied by 'Returns: Dict[str, Any]'), the description is somewhat complete. However, with no annotations and minimal behavioral details, it falls short of providing full context for reliable use, especially compared to sibling tools that might offer similar functionality.
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 description includes an 'Args' section that explains the 'dashboard_id' parameter as 'ID of the dashboard,' adding semantic meaning beyond the schema's title 'Dashboard Id' and type 'integer.' Since schema description coverage is 0%, this compensates partially, but it's minimal and doesn't elaborate on format or constraints (e.g., valid ranges).
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 cards in a dashboard.' This specifies the verb ('Get') and resource ('cards in a dashboard'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this from sibling tools like 'get_dashboard_items' or 'get_metabase_cards', which might have overlapping functionality.
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. With sibling tools such as 'get_dashboard_items' and 'get_metabase_cards' available, there's no indication of how this tool differs in context, scope, or use cases, leaving the agent to guess based on names alone.
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. It states the action ('Get a list') and return type, but lacks details on permissions, rate limits, pagination, or error handling. For a tool with no annotations, this leaves significant behavioral gaps, though it doesn't contradict any annotations.
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 brief and front-loaded with the core purpose in the first sentence. The second sentence adds return value details, which is useful given the output schema. There's no wasted text, though it could be slightly more structured for 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 simplicity (0 parameters, output schema exists), the description is adequate but minimal. It covers the basic purpose and return type, but lacks context on usage, behavior, or sibling differentiation. With no annotations and an output schema, it meets minimum viability but has clear gaps in guidance and transparency.
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 doesn't add param info, which is appropriate here. A baseline of 4 is applied as per rules for 0 parameters, since it doesn't need to compensate for any schema gaps.
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 verb ('Get') and resource ('list of all saved questions (cards)'), making the purpose evident. It distinguishes from siblings like 'get_card_query_results' by focusing on metadata retrieval rather than query execution. However, it doesn't explicitly differentiate from other 'get' tools like 'get_metabase_collection' or 'get_metabase_dashboards' beyond the resource name.
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. With siblings like 'get_metabase_collection' and 'get_metabase_dashboards', the description lacks context on whether this is for general listing, filtering, or specific use cases. It mentions returning metadata but doesn't specify prerequisites or exclusions.
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 full burden but only states it's a retrieval operation. It doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or whether it's idempotent. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by structured Args and Returns sections. It's front-loaded and wastes no words, though the 'Dict[str, Any]' return type could be slightly more descriptive for non-technical contexts.
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 (single parameter) and the presence of an output schema (which covers return values), the description is moderately complete. However, it lacks context on permissions, errors, or relationships to sibling tools, leaving room for improvement in guiding 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?
The description adds meaningful context for the single parameter by specifying it's an 'ID of the collection', which clarifies its purpose beyond the schema's generic 'Collection Id' title. Since schema description coverage is 0%, this compensation is valuable, though it doesn't detail format constraints (e.g., valid ID ranges).
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 verb 'Retrieve' and resource 'a single Metabase collection by ID', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_metabase_cards' or 'get_metabase_dashboards' which retrieve other resources, so it doesn't reach the highest score.
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. It doesn't mention sibling tools like 'get_metabase_collections' (if it existed) for listing collections or 'update_metabase_collection' for modifications, leaving usage context implied at best.
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 the full burden. It mentions the return type ('Dict[str, Any]') and some metadata fields ('id, name, and cards'), but lacks critical behavioral details like whether this lists all dashboards or requires permissions, if there's pagination or rate limits, or how 'cards' are structured. For a read operation with zero annotation coverage, this is insufficient.
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 well-structured: one sentence states the purpose, and another describes the return value. Both sentences earn their place by providing essential information without redundancy. It could be slightly more front-loaded by integrating the return details, but overall it's efficient.
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 (0 parameters) and the presence of an output schema (which likely details the return structure), the description is somewhat complete. However, it lacks behavioral context (e.g., permissions, pagination) and usage guidelines relative to siblings, making it adequate but with clear gaps for an agent to operate effectively.
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 doesn't add parameter details, which is appropriate. A baseline of 4 is applied since there are no parameters to explain, and the schema fully covers this aspect.
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 a list of dashboards in Metabase.' It specifies the verb ('Get') and resource ('dashboards in Metabase'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_dashboard_by_id' or 'get_dashboard_cards', which are more specific retrieval operations.
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. With many sibling tools for retrieving Metabase data (e.g., 'get_dashboard_by_id', 'get_dashboard_cards', 'get_metabase_cards'), there's no indication of whether this tool is for bulk listing, filtering, or other contexts. Usage is implied but not stated.
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. While it mentions the return type ('Dict[str, Any]: Group metadata including id, name, etc.'), it doesn't disclose important behavioral traits like whether authentication is required, rate limits, pagination behavior, or what happens when no groups exist. The output schema exists, but the description doesn't add meaningful behavioral context beyond the return format hint.
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 concise with two sentences: one stating the purpose and one describing the return. Both sentences earn their place, and the structure is front-loaded with the core purpose first. It could be slightly more efficient by combining the two sentences, but it's not wasteful.
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 (0 parameters, simple read operation) and the existence of an output schema, the description is minimally adequate. However, it lacks important context for a tool with no annotations: it doesn't mention authentication requirements, error conditions, or how it differs from similar 'get' tools. The output schema helps, but the description should provide more operational context.
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 baseline is 4. The description correctly indicates no parameters are needed by not mentioning any, which aligns perfectly with the empty input schema.
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 a list of groups (roles) in Metabase.' It uses a specific verb ('Get') and resource ('groups/roles'), but doesn't explicitly distinguish it from sibling tools like 'get_metabase_users' or 'get_metabase_cards' that also retrieve lists of different resources.
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. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from other 'get' tools in the sibling list like 'get_metabase_users' or 'get_metabase_dashboards'.
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 full burden for behavioral disclosure. While it mentions the return type ('Dict[str, Any]: User metadata including id, email, groups, etc.'), it doesn't address important behavioral aspects like whether this requires authentication, has rate limits, returns paginated results, or includes deactivated users. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 efficiently structured with a clear purpose statement followed by return information. Both sentences add value: the first states what the tool does, the second clarifies the return format. No wasted words or redundant information, though it could be slightly more comprehensive given the behavioral gaps.
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 that this is a read operation with no parameters and an output schema exists, the description is adequate but has clear gaps. The presence of an output schema means the description doesn't need to detail return values, but it should provide more context about when to use this versus sibling tools and address authentication/behavioral concerns that aren't covered by annotations.
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 (empty schema). The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the schema fully documents the absence of inputs.
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 verb ('Get') and resource ('list of users in Metabase'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'get_metabase_current_user' or 'get_metabase_groups' - it just says 'users' without clarifying scope or relationship to other user/group retrieval 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 guidance is provided about when to use this tool versus alternatives. With multiple sibling tools that retrieve user/group information (get_metabase_current_user, get_metabase_groups), the description offers no context about whether this retrieves all users, active users, or how it differs from the other user-related tools. The agent must infer usage from the name alone.
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 full burden for behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't specify what permissions are required, whether changes are reversible, what happens when optional parameters are omitted, or any rate limits/constraints. The return type is documented but not the content or structure of the metadata.
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 well-structured with a clear purpose statement followed by organized Args and Returns sections. While somewhat lengthy due to listing 9 parameters, every sentence serves a purpose - no redundant or unnecessary information. The formatting helps readability.
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 mutation tool with 9 parameters and no annotations, the description does reasonably well by documenting all parameters and the return type. However, it lacks important context about authentication requirements, error handling, what constitutes valid 'details' or 'schedule' objects, and how this tool differs from other update operations in the sibling list.
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% schema description coverage for 9 parameters, the description provides excellent parameter semantics by listing all parameters with brief explanations of what each controls. It clarifies that 'database_id' identifies the target, 'details' are connection details, 'auto_run_queries' enables auto run, etc. This significantly compensates for the schema's lack of descriptions.
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 verb ('Update') and resource ('an existing database connection in Metabase'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'update_metabase_card', 'update_metabase_collection', etc., which all follow the same 'update_metabase_X' pattern.
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 'create_metabase_database' or other update tools. There's no mention of prerequisites (e.g., needing an existing database_id), error conditions, or typical use cases for updating database connections versus creating new ones.
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 full burden for behavioral disclosure. While 'Update' implies mutation, it doesn't specify whether this requires admin privileges, if changes are reversible, what validation occurs (e.g., email format), or potential side effects (e.g., password changes triggering notifications). The description lacks these critical behavioral details.
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 well-structured with a clear opening sentence followed by organized 'Args' and 'Returns' sections. Every sentence adds value, though the parameter explanations could be slightly more detailed given the lack of schema descriptions.
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 mutation tool with 8 parameters, 0% schema coverage, no annotations, but with an output schema, the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral context, usage guidelines, and detailed parameter constraints that would make it fully complete.
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% schema description coverage, the description compensates well by listing all 8 parameters with brief explanations of what each represents. It clarifies that 'user_id' identifies the target user and provides context for fields like 'login_attributes' and 'group_ids'. However, it doesn't explain format expectations (e.g., password complexity) or constraints (e.g., unique email).
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 ('Update') and resource ('an existing user in Metabase'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'create_metabase_user' or other update tools, which would require 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 'create_metabase_user' or 'delete_metabase_user'. It also doesn't mention prerequisites (e.g., needing admin permissions) or constraints (e.g., what happens if email is already in use).
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. While it correctly indicates this is a creation operation, it doesn't describe what happens after creation (e.g., whether the group becomes immediately active, default permissions, or if there are limitations on group names). It mentions LDAP integration but doesn't explain the implications. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 well-structured and appropriately sized. It begins with a clear purpose statement, then provides organized sections for Args and Returns with bullet-like formatting. Every sentence earns its place, with no redundant or unnecessary information. The formatting helps with readability despite being a single paragraph.
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 that this is a creation tool with no annotations, 2 parameters (one optional), and an output schema exists (so return values are documented elsewhere), the description is moderately complete. It covers the basic purpose and parameters but lacks important context about permissions, error conditions, relationship to other tools, and behavioral details that would help an agent use it correctly in complex scenarios.
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 description adds meaningful semantic context beyond the 0% schema description coverage. It explains that 'name' is for the group name and 'ldap_dn' is an optional LDAP Distinguished Name, clarifying what these parameters represent. However, it doesn't provide format requirements, length limits, or examples for either parameter, leaving some practical usage questions unanswered.
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: 'Create a new group (role) in Metabase.' It specifies the verb ('Create') and resource ('group/role'), but doesn't explicitly differentiate it from sibling tools like 'create_metabase_user' or 'create_metabase_collection' beyond the resource type. The parenthetical '(role)' adds helpful clarification about what a 'group' represents in Metabase context.
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. It doesn't mention sibling tools like 'get_metabase_groups' (for listing existing groups) or 'delete_metabase_group' (for removal), nor does it specify prerequisites, permissions needed, or typical use cases for creating groups versus users or other resources.
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 the full burden. It states the tool returns a list of database metadata, which is helpful, but doesn't disclose behavioral traits like whether it's a read-only operation, requires authentication, has rate limits, or pagination. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence clearly states the purpose, and the second provides return value information. There's no wasted text, and every sentence earns its place by adding necessary context beyond the tool name.
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 0 parameters, 100% schema coverage, and an output schema exists (implied by 'Has output schema: true'), the description is adequate for a simple list operation. However, with no annotations and sibling tools that are similar, it could benefit from more context about when to use it or what 'connected databases' entails. It's minimal but not incomplete.
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, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline. No additional value is required, and it doesn't introduce confusion about parameters.
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 a list of connected databases in Metabase.' It specifies the verb ('Get') and resource ('connected databases'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_metabase_dashboards' or 'get_metabase_cards', which follow a similar pattern for other resources.
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. It doesn't mention prerequisites, context for usage, or exclusions. Given the sibling tools include other 'get_' operations for different Metabase resources, the agent must infer usage based on naming alone.
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 mentions 'update an existing collection' which implies mutation, but doesn't cover permissions needed, whether changes are reversible, error handling, or rate limits. This leaves significant 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 well-structured and front-loaded with the core purpose, followed by organized sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 (mutation with 4 parameters) and no annotations, the description is moderately complete. It covers parameters and return type, but lacks behavioral details like side effects or error cases. The presence of an output schema reduces the need to explain return values, but more context would help.
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 description coverage is 0%, but the description compensates by listing all parameters with brief explanations (e.g., 'ID of the collection to update', 'New name'). It clarifies that collection_id is required and others are optional, adding meaningful context beyond the bare schema.
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 verb 'update' and resource 'Metabase collection', making the purpose evident. However, it doesn't differentiate from sibling tools like update_metabase_card or update_metabase_dashboard, which follow the same pattern for different resources.
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. For example, it doesn't mention prerequisites like needing an existing collection ID or how it differs from create_metabase_collection. The description only states what it does, not when to use it.
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. It states this is a 'Get' operation, implying read-only behavior, but doesn't disclose important traits like whether it requires authentication, what happens with invalid IDs (e.g., errors vs. null returns), rate limits, or pagination. The description adds minimal behavioral context beyond the basic 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 perfectly structured and concise: a clear purpose statement followed by well-formatted Args and Returns sections. Every sentence earns its place, with no redundant information. The front-loaded purpose makes it immediately scannable.
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 (single parameter, read operation) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the parameter semantics adequately. However, it lacks context about authentication requirements and error handling, which would be helpful despite the 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 description explicitly documents the single parameter 'dashboard_id' with its type (int) and meaning ('ID of the dashboard'), adding semantic value beyond the schema which has 0% description coverage. This fully compensates for the schema gap. However, it doesn't provide examples or constraints (e.g., valid ID ranges).
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 verb ('Get') and resource ('a dashboard by ID'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'get_metabase_dashboards' (plural) by specifying retrieval of a single dashboard via ID. However, it doesn't explicitly contrast with other get_* tools like 'get_dashboard_cards' or 'get_dashboard_items'.
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. It doesn't mention when to choose this over 'get_metabase_dashboards' for listing dashboards, or how it relates to 'get_dashboard_cards'/'get_dashboard_items'. There's also no information about prerequisites like authentication or permissions needed to access dashboards.
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 full burden but only states it 'creates' a user without disclosing behavioral traits like required permissions, whether it sends email notifications, rate limits, or error conditions. It mentions the return type but doesn't explain what 'Created user metadata' includes or potential side effects.
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 well-structured with a clear purpose statement followed by Args and Returns sections, making it easy to parse. It's appropriately sized, though the parameter explanations could be more detailed without sacrificing conciseness.
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 (7 parameters, mutation operation) and no annotations, the description is moderately complete but has gaps: it doesn't cover error handling, authentication needs, or how it differs from sibling tools. The output schema exists, so describing return values isn't necessary, but more behavioral context 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 description coverage is 0%, so the description must compensate—it does by listing all 7 parameters with types and brief explanations, adding meaning beyond the schema's titles. However, it lacks details on format constraints (e.g., email validation, password complexity) or examples for optional parameters like 'login_attributes'.
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 'Create a new user in Metabase' with specific verb ('Create') and resource ('user'), distinguishing it from sibling tools like 'update_metabase_user' or 'delete_metabase_user'. It precisely defines what the tool does without ambiguity.
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 on when to use this tool versus alternatives like 'update_metabase_user' or 'get_metabase_users' is provided. The description lacks context about prerequisites, permissions needed, or typical use cases, offering only basic functional information.
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 the full burden. While it mentions 'Delete' (implying a destructive operation) and 'Deletion confirmation' (hinting at a response), it lacks critical behavioral details such as whether deletion is permanent/irreversible, if it requires admin permissions, or if it affects dependent resources (e.g., cards on the dashboard).
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 with the core purpose in the first sentence. The Args/Returns sections are structured but slightly verbose for a single parameter; however, every sentence adds value without redundancy.
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 destructive nature, no annotations, and an output schema (which covers return values), the description is minimally adequate. It explains the action and parameter but lacks context on safety, permissions, or side effects, which is a significant gap for a deletion 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?
With only 1 parameter and 0% schema description coverage, the description compensates well by clearly explaining 'dashboard_id (int): ID of the dashboard to delete.' This adds essential meaning beyond the schema's basic type information, though it doesn't specify format constraints (e.g., valid ID ranges).
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 ('Delete') and resource ('a dashboard from Metabase'), making the purpose immediately apparent. It distinguishes itself from sibling tools like 'get_dashboard_by_id' (read) and 'update_metabase_dashboard' (modify) by focusing on permanent removal.
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. It doesn't mention prerequisites (e.g., needing the dashboard ID from a previous operation), exclusions (e.g., not for cards or collections), or related tools like 'delete_metabase_card' for similar operations on different resources.
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 the full burden of behavioral disclosure. It states the tool deletes a database connection and returns a confirmation, but lacks critical details: whether deletion is permanent/reversible, required permissions, side effects (e.g., impact on dependent dashboards/cards), or error handling. For a destructive operation with zero annotation coverage, this is a significant gap.
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 well-structured and appropriately sized, with a clear purpose statement followed by Args and Returns sections. Every sentence adds value: the first defines the action, and the others document parameters and return type. It could be slightly more concise by integrating the Args/Returns into a single sentence, but it's efficient overall.
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 (destructive operation), lack of annotations, and presence of an output schema (which covers return values), the description is partially complete. It covers the basic purpose and parameters but misses behavioral context like safety warnings or dependencies. For a delete tool, more detail on consequences would improve completeness, but the output schema helps mitigate gaps.
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 description adds meaningful context beyond the input schema. The schema only indicates 'database_id' is an integer, but the description clarifies it's 'ID of the database to delete', specifying its purpose. With 0% schema description coverage and only 1 parameter, this adequately compensates, though it could note format constraints (e.g., where to find the ID).
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 ('Delete') and resource ('a database connection from Metabase'), distinguishing it from sibling tools like 'delete_metabase_card' or 'delete_metabase_dashboard' which target different resources. It precisely identifies what the tool does without being vague or tautological.
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. It doesn't mention prerequisites (e.g., needing an existing database), exclusions (e.g., not for read-only operations), or comparisons to siblings like 'get_metabase_databases' for listing databases. Usage is implied by the name but not explicitly stated.
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 full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't mention required permissions, whether this operation is idempotent, potential side effects, rate limits, or error conditions. The return format is mentioned but without behavioral context about what happens during creation.
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 well-structured with clear sections (Args, Returns) and uses bullet-like formatting. The opening sentence is front-loaded with the core purpose. Some parameter descriptions could be more detailed (e.g., 'Connection details' is vague), but overall the structure is efficient with minimal wasted space.
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 complexity (9 parameters, mutation operation, no annotations) but with output schema present, the description is moderately complete. It covers parameters well and mentions the return type, but lacks behavioral context about the creation process, permissions, or error handling. For a mutation tool with this many parameters, more operational guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 9 parameters (3 required), the description provides excellent parameter semantics. Each parameter is listed with name, type, and brief explanation of purpose (e.g., 'Connection details' for details, 'Enable auto run' for auto_run_queries). This fully compensates for the lack of schema descriptions and helps the agent understand what each parameter controls.
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 ('Create a new database connection') and resource ('in Metabase'), distinguishing it from sibling tools like create_metabase_card or create_metabase_dashboard which create different Metabase resources. The verb 'create' paired with 'database connection' provides unambiguous purpose.
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. There are sibling tools like update_metabase_database and delete_metabase_database, but no indication of when to create versus update, or what prerequisites might be needed. No exclusions or contextual 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 full burden for behavioral disclosure. While it mentions 'Deletion confirmation' in returns, it doesn't specify whether this operation is reversible, requires specific permissions, has side effects (e.g., removing users from the group), or any rate limits. For a destructive operation with zero annotation coverage, this leaves significant behavioral gaps.
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 structured and front-loaded: the first sentence states the purpose, followed by clear Arg/Return sections. Every sentence earns its place with no redundant information. The formatting with headings makes 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?
Given this is a destructive operation with no annotations and 0% schema coverage, the description does the minimum viable job. The output schema exists (Returns: Dict[str, Any]), so the description doesn't need to detail return values. However, for a delete operation, it should ideally mention permissions, irreversibility, or side effects to be fully complete.
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 only 1 parameter and 0% schema description coverage, the description compensates well by clearly explaining that 'group_id' is the 'ID of the group to delete.' This adds essential meaning beyond the bare schema, though it doesn't specify format constraints (e.g., positive integers) or where to find valid group IDs.
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 ('Delete') and resource ('a group (role) from Metabase'), distinguishing it from sibling tools like delete_metabase_user or delete_metabase_card by specifying the target resource type. It uses precise terminology that leaves no ambiguity about what the tool does.
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. It doesn't mention prerequisites (e.g., needing admin permissions), consequences (e.g., what happens to users in the deleted group), or when to choose other deletion tools like delete_metabase_user. The agent must infer usage from the tool name alone.
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. It states the tool returns user details, which is helpful, but doesn't disclose behavioral traits like authentication requirements, rate limits, or error handling. It adds basic context about the return type but misses key operational 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 front-loaded with the core purpose in the first sentence, followed by a concise note on the return type. Both sentences add value without redundancy, making it efficiently structured and appropriately sized for the tool's simplicity.
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 annotations, but with an output schema), the description is reasonably complete. It explains what the tool does and the return format, though it could benefit from more behavioral context. The output schema reduces the need to detail return values, so gaps are minor.
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 appropriately doesn't discuss parameters, focusing instead on the return value. This meets expectations for a parameterless tool, earning a high score.
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 verb ('Get') and resource ('current logged-in user info from Metabase'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_metabase_users', which retrieves multiple users rather than the current one. This omission prevents 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 implies usage by mentioning 'current logged-in user', suggesting it's for retrieving the authenticated user's details. However, it lacks explicit guidance on when to use this versus alternatives like 'get_metabase_users' or prerequisites such as authentication context. This leaves 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 full burden. It discloses important behavioral traits like PostgreSQL case-sensitivity requirements and quoting conventions, but doesn't mention authentication needs, rate limits, transaction behavior, or what happens with invalid queries. The description adds meaningful context but leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Notes) and front-loaded purpose. Every sentence adds value, though the PostgreSQL-specific notes might be overly detailed for a general SQL execution tool. The example query is helpful but slightly lengthens the description.
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 this is a mutation tool with no annotations, 0% schema coverage, but with output schema present, the description does well. It covers purpose, parameters, return type, and important behavioral notes. The main gap is lack of guidance on error handling or security implications for a raw SQL execution 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?
Schema description coverage is 0%, so the description must compensate. It clearly explains all three parameters: database_id identifies the target, native_query contains the SQL, and parameters are optional query parameters. The description adds crucial meaning beyond the bare schema, though it could specify parameter format or types more explicitly.
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 native SQL query') and resource ('through Metabase'), distinguishing it from all sibling tools which focus on CRUD operations for Metabase objects rather than direct SQL execution. The verb+resource combination is precise and unambiguous.
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 (executing SQL queries on Metabase databases) and includes specific notes about PostgreSQL case-sensitivity. However, it doesn't explicitly state when NOT to use it or mention alternatives like the 'get_card_query_results' sibling tool for pre-defined 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 the full burden of behavioral disclosure. It effectively describes that this is a creation operation (implying mutation), specifies it uses the /api/card endpoint, and provides detailed examples of visualization settings. However, it doesn't mention authentication requirements, rate limits, or error handling, which are important for a tool with 15 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is comprehensive, it's quite lengthy with detailed formatting examples and notes that could be condensed. The front-loaded purpose is clear, but the extensive parameter documentation and examples make it less concise than ideal, though all content appears relevant.
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?
Given the tool's complexity (15 parameters, nested objects, no annotations), the description provides complete coverage: clear purpose, detailed parameter explanations, return value documentation, and a comprehensive example. With an output schema present, the description appropriately focuses on usage rather than return structure, making it fully adequate for this complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage and 15 parameters, the description compensates excellently by providing detailed explanations for all parameters, including required structures, common values, optional defaults, and extensive examples for visualization_settings. It adds substantial meaning beyond what the bare schema provides, making parameter usage clear.
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 creates a new card (chart or table) in Metabase via a specific API endpoint, specifying it supports SQL or MBQL queries and all chart types. This distinguishes it from sibling tools like create_metabase_dashboard or create_metabase_collection by focusing on visual cards rather than other Metabase entities.
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 (creating visual cards with queries) and implies alternatives through sibling tools like update_metabase_card for modifications or get_metabase_cards for retrieval. However, it lacks explicit guidance on when NOT to use it or direct comparisons to alternatives like create_metabase_dashboard for dashboard creation.
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 does an excellent job describing key behaviors: partial update capability, auto-fallback to existing values when fields are omitted, specific handling of dashcards without IDs (auto-assigns -1), and collection_id edge cases. It also includes a comprehensive 'Behavior' section detailing how unspecified fields are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Behavior, Example) but is quite lengthy due to the high parameter count. While most content is valuable, some redundancy exists (e.g., 'If omitted, existing values will be preserved' is repeated for multiple parameters). It could be more front-loaded with the most critical information.
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 complex mutation tool with 17 parameters, 0% schema description coverage, and no annotations, the description is remarkably complete. It covers purpose, usage, detailed parameter semantics, behavioral patterns, return values (though an output schema exists), and includes a practical example. The only minor gap is lack of authentication/authorization requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by providing detailed semantic information for all 17 parameters. Each parameter includes: purpose explanation, optionality handling, default behaviors, and for complex parameters like dashcards and tabs, it details sub-fields and constraints (e.g., 'id must be unique within the dashboard'). This goes far beyond what the bare schema provides.
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: 'Update an existing dashboard in Metabase using structured inputs and auto-fallback behavior.' It specifies the verb ('update'), resource ('dashboard in Metabase'), and distinguishes it from siblings like 'create_metabase_dashboard' by focusing on modifying existing resources rather than creating new ones.
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: for updating existing dashboards with partial updates. It mentions the auto-fallback behavior for unspecified fields. However, it doesn't explicitly state when NOT to use it (e.g., vs. create_metabase_dashboard for new dashboards) or mention prerequisites like authentication requirements.
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-server MCP server](https://glama.ai/mcp/servers/CW-Codewalnut/metabase-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/CW-Codewalnut/metabase-mcp-server)

Score Badge

Copy to your README.md:

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

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/CW-Codewalnut/metabase-mcp-server'

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