Superset MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources and actions. The only potential confusion is between superset_list_datasets and superset_list_all_datasets, but their descriptions clearly differentiate (filtered/search vs all pages). superset_get_dashboard_charts also overlaps slightly with superset_list_charts, but the dashboard scoping is clear.
Naming Consistency5/5
All tools follow a consistent `superset_verb_noun` pattern with snake_case. The verb is always placed immediately after the prefix, and nouns are lowercase (e.g., superset_list_databases, superset_create_dashboard). The only minor deviation is superset_list_all_datasets, but it's still readable and predictable.
Tool Count4/5
17 tools is slightly above the typical sweet spot, but each tool addresses a distinct operation on the core entities (databases, datasets, dashboards, charts). There are no trivial or redundant tools, so the count feels justified for full chart/dashboard lifecycle management.
Completeness3/5
Charts and dashboards have complete CRUD coverage plus extra operations (filters, adding charts). However, databases and datasets only support listing/getting, with no create, update, or delete. Additionally, there is no way to remove a chart from a dashboard without deleting it, which is a notable gap.
Average 3.9/5 across 17 of 17 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only provides parameter format details. It does not mention side effects, permissions, whether the chart is immediately visible, or what happens on success. The description is silent on any behavioral traits beyond the act of creating.
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 two sentences long, front-loaded with the core purpose, and adds a necessary detail about the params format. There is no fluff, but it could be better structured with clearer examples or a link to documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and moderate complexity, the description is too thin. It fails to explain which viz_type values are accepted, how to construct valid params, or any behavioral expectations. The agent is left with too many open questions to reliably use this tool without external knowledge.
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 meaningful context for the params parameter by explaining it must be a JSON string with keys like metrics, groupby, and depending on viz_type. This goes beyond the bare schema. However, it does not clarify the semantics of dataset_id, viz_type, or slice_name, and with 0% schema coverage, more compensation is needed.
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 chart' with a specific verb and resource, distinguishing it from sibling tools like update_chart, delete_chart, and add_chart_to_dashboard. It also mentions the key differentiator of needing a JSON params string depending on viz_type, which aligns with chart creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as update_chart for existing charts or add_chart_to_dashboard for embedding. There are no prerequisites or exclusions mentioned. The description only states the basic purpose, leaving usage context entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the basic read operation without describing any limitations, prerequisites, potential errors, or response format (though an output schema exists). It does not disclose whether the tool returns full chart objects, pagination behavior, or how 'belong to a dashboard' is defined, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundant information. It is front-loaded and immediately communicates the core action and target. Every word earns its place, making it highly concise and structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of closely related sibling tools (superset_list_charts, superset_get_dashboard, superset_add_chart_to_dashboard), the description lacks contextual guidance on how this tool fits in. The one-sentence description is insufficient to fully understand the tool's role, especially with no parameter semantics or behavioral nuance. The output schema may cover return values, but the description still needs to provide more operational context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. The only parameter, dashboard_id_or_slug, is mentioned in the name but its format, semantics, and usage are not explained in either the schema or the description. There is no guidance on how to obtain or format the value (e.g., ID vs. slug), making parameter understanding reliant solely on the variable name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get all charts that belong to a dashboard.' It uses a specific verb (Get) and resource (charts) with an explicit qualifier (that belong to a dashboard), distinguishing it from sibling tools like superset_list_charts (all charts) or superset_get_dashboard (a single dashboard).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need charts for a specific dashboard) but provides no explicit guidance on when not to use it or how it compares to alternatives like superset_list_charts or superset_get_dashboard. There is no mention of exclusions or preferred scenarios, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does indicate the return content (viz_type, params, datasource), which is helpful, but it omits any mention of auth requirements, error behavior, or performance characteristics. As a read-only get operation, the risk is lower, but this is still minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the purpose. No wasted words, and the most important information is front-loaded.
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 get-by-id tool, the description covers the basic purpose and return content. However, it lacks usage guidance and context about how this fits with sibling tools (e.g., when to use get_chart vs list_charts). The presence of an output schema reduces the need to explain return structure, but the description still feels slightly sparse for a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (chart_id) and schema description coverage is 0%, so the description must compensate. However, it only says 'by id,' which merely restates the parameter name. It does not explain the format, source, or any constraints beyond what the schema already shows, leaving no added semantic value.
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 (Get) and resource (chart by id), which is a specific verb+resource pattern. It also briefly lists the return fields (viz_type, params, datasource), providing additional clarity. It does not explicitly mention siblings, but the 'by id' wording distinguishes it from list_charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single chart when you know its id, but it does not explicitly specify when to use it over alternatives like list_charts, nor does it mention exclusions or prerequisites. The guidance is inferred from 'by id' rather than stated.
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?
Since no annotations are provided, the description carries the burden of disclosing behavioral traits. It does add one important side effect: 'This does not delete the charts on it; they remain in Superset.' However, it omits other relevant behaviors such as irreversibility, permission requirements, or failure conditions, leaving gaps in the safety profile for a destructive 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 two short sentences, front-loaded with the core purpose. Every word adds value: the first states the action, the second clarifies an important side effect. There is no redundancy or irrelevant detail.
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 that this is a simple tool with one parameter and an output schema, the description sufficiently covers the core function and its most immediate consequence (charts are preserved). It does not delve into broader context like error handling or reversibility, but the tool's complexity is low, making this a reasonably complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (dashboard_id) but schema description coverage is 0%. The description merely says 'by id,' which adds minimal meaning beyond the parameter name and type. It does not explain what an id is, how to find it, or any format/validation details, so it fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action as 'Delete a dashboard by id,' using a specific verb and resource. It also distinguishes itself from sibling tools like superset_delete_chart and superset_update_dashboard by focusing specifically on dashboard deletion, and adds a clarifying note about charts not being deleted.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply states the function without contextual 'use this when' advice, leaving the agent to infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and an optional search, but does not mention pagination, permissions, or whether this is read-only. This is minimal and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: 'List charts. Optionally search by name.' Both sentences are purposeful and front-loaded, with no redundancy or filler.
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 tool with one optional parameter and an existing output schema, the description is minimally adequate but incomplete. It lacks context about pagination, result limits, access scope, or any special behavior. This is a clear gap given the absence of 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 schema has no description for the 'search' parameter, and coverage is 0%. The description adds meaning by saying 'Optionally search by name', which explains what the parameter does. This compensates for the schema gap, though it does not detail matching behavior (e.g., substring vs exact).
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 'List charts' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'list_databases' and 'get_chart'. The plural 'charts' confirms it is a listing operation, differentiating it from singular retrieval.
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. There is no mention of when to prefer this over 'get_chart' or other list tools, and no exclusions or prerequisites are given.
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 discloses that the dashboard is initially empty and that the response includes the id, which is useful. However, it omits other behavioral aspects such as permission requirements, effects of 'published'/'slug', and any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences, no filler, and directly states the purpose and return. It is front-loaded with the core action and outcome.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and return value, and an output schema exists for return structure. However, it lacks parameter semantics and workflow context (e.g., what 'empty' means, relationship to add/chart tools), leaving gaps for a creation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any of the parameters (dashboard_title, published, slug). The schema only provides types and defaults, so there is no added meaning from the description to guide parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('dashboard'), and key characteristics ('empty', 'Returns the new dashboard with id'). This differentiates it from sibling tools like update, delete, list, and get dashboards.
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 use context: creating a new empty dashboard. It also hints at the next steps ('Then add charts and filters'), implying a workflow. However, it does not explicitly mention when not to use this tool or direct users to alternative tools for modifications.
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 for behavioral disclosure. It identifies the operation as an 'add' (mutation) but fails to mention whether the operation is idempotent, what happens if the chart is already on the dashboard, whether permissions are required, or how errors are handled. This lack of detail leaves the agent uncertain about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the verb and object, and it includes the key positional context. There is no fluff or redundant information, making it both concise 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?
The description covers the primary action but omits important contextual details such as prerequisites (e.g., the dashboard and chart must already exist), whether adding a chart at a position replaces an existing one, and any constraints on the coordinate values. While the output schema handles return values, the description still lacks enough context for handling edge cases or validation.
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 names the positional parameters (x, y, width, height) and explains their role as defining a 'grid position'. It also implicitly defines chart_id and dashboard_id by referring to 'existing chart' and 'dashboard'. Since schema description coverage is 0%, the description compensates by giving the parameters meaningful context that the raw schema lacks.
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: 'Add an existing chart to a dashboard' with the grid position parameters. It uses a specific verb ('Add') and resource ('existing chart', 'dashboard') that distinguishes it from sibling tools like create_chart or create_dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for adding an existing chart to a dashboard with a specified layout. However, it does not explicitly mention exclusions or alternative tools, such as using superset_create_chart to make a new chart first or superset_get_dashboard_charts to verify existing charts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what the tool returns ('full detail including position_json and json_metadata (filters)'), which is useful behavioral context. However, with no annotations provided, it carries the full burden and does not mention permissions, error handling, or that it is a read-only operation. It only partially covers the behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose ('Get a dashboard by id or slug') followed by a high-value detail on the return content. Every word earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear output schema), the description is largely complete. It covers the input semantics, operation, and key return fields. Missing context includes explicit guidance on when to use it versus listing dashboards, but this is not critical for correct invocation.
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 schema has a single string parameter 'id_or_slug' with no description. The tool description compensates by explaining it accepts 'id or slug', which is essential semantic meaning beyond the schema. It could add examples or format constraints, but for a single parameter, this is adequate.
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 operation: 'Get a dashboard by id or slug.' It uses a specific verb (Get) and resource (dashboard), and distinguishes itself from siblings like superset_list_dashboards (listing) and superset_get_dataset (different resource). The mention of 'full detail' further clarifies its role as a retrieval tool for a single dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: you use this when you have a dashboard's id or slug and need full detail. However, it does not explicitly mention alternatives or exclusions (e.g., 'use list_dashboards to find dashboards first'). It provides no 'when-not-to-use' guidance, placing it between implied usage and clear context.
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 available, the description carries the full burden. 'List' implies a read-only operation and the optional title search is disclosed, but there is no mention of pagination, ordering, authentication, or potential response size. It is a safe, minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and resource, and every word adds value. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, output schema present, read-only concept), the description covers the essential usage. The lack of pagination or ordering details is a minor gap, but not critical for a basic list 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?
The schema provides only a nullable 'search' parameter with no description, and schema coverage is 0%. The description compensates by specifying that the search is by title, which adds semantic meaning beyond the raw schema and reduces ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('dashboards'), which distinguishes it from sibling tools that list databases or datasets. The optional title search is also a specific, unique capability.
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 clearly indicates this tool is for listing dashboards, but it does not explicitly state when to prefer it over alternatives like superset_get_dashboard or superset_list_datasets. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies a read-only listing operation but does not disclose pagination, response format, access restrictions, or ordering behavior. It adds minimal behavioral context beyond the obvious list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two crisp sentences, front-loaded with the primary purpose, and includes a clear use case. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and an output schema, the description is nearly complete. It covers purpose, filters, and a concrete use case. However, it could be improved by explicitly distinguishing from superset_list_all_datasets and clarifying any response limitations.
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 adds meaning to the two parameters: 'filter by database_id or search by name.' This goes beyond the schema, but it does not explain matching behavior (case sensitivity, wildcards) or any interplay between the filters, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'datasets (tables/views)' in Superset, and the optional filters differentiate it from siblings like superset_list_all_datasets and superset_get_dataset. It's specific 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 by stating 'Use to find dataset_id for creating charts,' which implies when to use this tool. However, it does not explicitly name alternatives or state when not to use it, such as when an unfiltered list or a single dataset is needed.
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 behavioral transparency burden. It discloses the important partial-update behavior (only specified fields are changed), which is valuable. However, it does not mention permissions, reversibility, or impact on unspecified fields beyond the implication, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes a key usage hint. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be described. The description covers the operation, partial-update semantics, and example fields. It is sufficient for a simple update tool, though it could mention error conditions or side effects. Overall, it is complete enough for the complexity level.
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%, so the description must compensate. It mentions example fields (title, slug, published) which maps to dashboard_title, slug, and published in the schema, but the alias 'title' may cause slight confusion with dashboard_title. It does not explain the required dashboard_id, though that is self-evident. Adds some value but not full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing dashboard') with a specific verb and resource. It distinguishes itself from sibling tools like superset_create_dashboard, superset_delete_dashboard, and especially superset_update_dashboard_filters, as it focuses on dashboard metadata fields rather than filters.
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 guideline 'Pass only the fields you want to change' provides clear usage context for partial updates. It does not explicitly name alternatives or exclusions, but the purpose statement implicitly separates it from create/delete/get operations, making the intended use relatively clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It clearly states that all pages are fetched, which is a key behavioral trait of pagination. It does not mention rate limits or potential performance implications, but for a list operation, this is a reasonable disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and includes a brief, relevant usage example. Every word earns its place with no fluff.
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?
The tool is simple with one optional parameter and has an output schema. The description provides the core behavior and a usage context, making it easy for an agent to decide when to invoke it. The only gap is the unexplained page_size parameter, but this is a minor omission given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter, page_size, with a default of 100, but the description makes no mention of it. With 0% schema description coverage, the description should compensate by explaining how page_size affects the results. It fails to do so, leaving the agent to infer from the name alone.
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 lists all datasets in Superset across all pages. It uses a specific verb ('List') and resource ('datasets'), and the phrase 'across all pages' differentiates it from the sibling tool superset_list_datasets, which likely does not paginate fully.
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 explicitly says 'Use when you need the full list' and provides a concrete example (finding a dataset by name like vw_bioverse_performance_report). It does not explicitly name the alternative sibling, but the usage context is clear.
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, the description carries the full burden. It discloses partial-update behavior ('Pass only the fields you want to change') and the JSON-string requirement for params, which are non-obvious traits. It does not mention side effects, permissions, or failure modes, but the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and resource, and every sentence adds value. There is no fluff or repetition of schema details.
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 presence of an output schema, the description need not explain return values. It covers the key usage aspects: the update action, partial-update semantics, and the params format. The only gap is the exact shape of 'params,' but the reference to create_chart is a reasonable shortcut. Overall, it is sufficiently complete for a tool with this complexity.
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%, so the description must compensate. It explains that 'params' must be a JSON string with the same shape as for create_chart, which is helpful for the most ambiguous parameter. However, it does not detail the JSON structure or clarify 'slice_name' and 'description' beyond their self-evident names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Update an existing chart,' which clearly states the action (update) and resource (chart). This distinguishes it from sibling tools like superset_create_chart and superset_delete_chart, and the tool name reinforces the purpose.
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?
'Pass only the fields you want to change' gives explicit guidance for partial updates, and the reference to 'same shape as for create_chart' implies when to use create vs. update. However, it does not explicitly state when not to use the tool or name alternatives beyond the create_chart reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It explicitly states 'Replaces all existing native filters,' which is a critical behavioral trait indicating the operation overwrites current filters. This goes beyond the schema and provides essential context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, then providing parameter format and replacement behavior. Every sentence earns its place, with no redundant or overly verbose wording.
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 output schema exists, return values are covered. The description covers the tool's purpose, parameter details, and the significant replacement behavior. It could mention potential error cases or the need for existing filter IDs, but overall it is sufficiently complete for a straightforward 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 schema provides only parameter names and types with 0% description coverage. The description compensates by explaining that native_filter_configuration is 'a JSON string: list of filter objects with id, name, filterType, targets, defaultDataMask, scope, etc.' This adds meaningful detail about the structure and content of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update native (dashboard-level) filters.' The verb 'Update' identifies the action, and 'native filters' specifies the resource. This distinguishes it from sibling tools like 'superset_update_dashboard' which updates general dashboard settings.
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 gives clear context on how to use the tool (passing native_filter_configuration as a JSON string) but does not explicitly state when this tool should be used over alternatives like 'superset_update_dashboard'. There is no exclusion or alternative guidance, so usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly identifies the destructive action and differentiates it from non-destructive dashboard removal. However, it does not mention permanence, required permissions, or side effects on dashboards, which prevents a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the action front-loaded in the first sentence. The second sentence adds a valuable distinction without redundancy, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool, the description covers the essential action, scope, and a common confusion (dashboard removal vs Superset deletion). An output schema exists, so return values are already defined; only deeper side-effect or error details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's 'by id' partially compensates by confirming that chart_id is the chart identifier. However, it adds little beyond the parameter name and integer type, and does not explain where to find the id or any format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Delete a chart by id.' The second sentence clarifies that this is a Superset-level deletion, not just a dashboard removal, which distinguishes it from dashboard-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when not to use the tool: 'Removing it from a dashboard does not delete the chart.' It also directs the user to use this tool when the intent is to delete the chart from Superset, giving clear when/when-not guidance even though no alternative tool is named.
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 burden of behavioral disclosure. 'List all databases configured in Superset' transparently indicates a read-only listing operation. It does not mention pagination or permissions, but for a simple list tool, the behavior is adequately disclosed. The example '(e.g. Snowflake)' adds practical context without being misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. The first sentence states the action and resource, and the second provides a concrete use case. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters) and has an output schema, so the return value structure is likely covered elsewhere. The description explains the tool's purpose and a key use case (finding database_id for listing datasets). It is complete enough for an agent to select and invoke the tool correctly, though it could mention that the output contains database metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description does not need to explain any. The baseline for 0-parameter tools is 4, and the description appropriately adds no unnecessary parameter details. The mention of Snowflake serves as an example rather than parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all databases configured in Superset'. The verb 'List' and resource 'databases' are specific, and the example '(e.g. Snowflake)' adds clarity. It is clearly distinguished from sibling tools that handle datasets, dashboards, and charts.
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 a clear use case: 'Use to find database_id for listing datasets.' This tells the agent when to use the tool, specifically when a database_id is needed for dataset-related operations. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough.
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?
In the absence of annotations, the description carries the burden of behavioral disclosure. It states that the tool returns dataset details including columns and metrics, which implies read-only behavior. It does not explicitly say 'does not modify data,' but the verb 'get' and the use case make this evident, which is adequate for a simple retrieval 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 two sentences, front-loaded with the operation and followed by a relevant use case. Every word earns its place, with no redundancy or unnecessary detail.
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?
This is a simple get-by-id tool with one parameter and an output schema present. The description covers the core functionality and provides a pertinent use case, making it complete for an agent to select and invoke correctly without additional 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 schema has one integer parameter `dataset_id` with a 0% schema description coverage. The description's 'Get a dataset by id' clarifies that the parameter is the dataset's identifier, adding meaning beyond the bare schema. For a single simple parameter, this compensation is sufficient, though it could be more explicit about 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 explicitly states 'Get a dataset by id' with a specific verb and resource, and 'including columns and metrics' adds specific content. This distinguishes it from sibling list tools like `superset_list_datasets`, which enumerate datasets rather than retrieving a single one by identifier.
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 phrase 'Use to see available columns before creating charts' provides a clear, concrete scenario for when to use this tool. It does not explicitly mention when not to use it or name alternatives, but it gives enough context to guide the agent.
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:

[![bio-superset-agent MCP server](https://glama.ai/mcp/servers/tlubben/bio-superset-agent/badges/card.svg)](https://glama.ai/mcp/servers/tlubben/bio-superset-agent)

Score Badge

Copy to your README.md:

[![bio-superset-agent MCP server](https://glama.ai/mcp/servers/tlubben/bio-superset-agent/badges/score.svg)](https://glama.ai/mcp/servers/tlubben/bio-superset-agent)

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/tlubben/bio-superset-agent'

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