Superset MCP Server

by Amit-DAlal-1

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clear, distinct purposes targeting specific resources and actions. The only potential confusion is between get_sql_result (async result retrieval) and get_query (query history/status), and between get_chart_data and get_chart, but descriptions are sufficiently clear.
Naming Consistency4/5
The vast majority follow a consistent verb_noun snake_case pattern (list_, get_, create_, update_, execute_). The single outlier is superset_status, which is not verb-first but still readable and not disruptive.
Tool Count3/5
At 25 tools, this is at the heavy end of the borderline range. Each tool has a purpose, but the granularity is excessive in places (e.g., four dashboard-related getters), making the surface feel larger than necessary.
Completeness3/5
The set covers most core workflows for dashboards, charts, datasets, saved queries, and SQL execution, but there are notable gaps: no list_charts, no delete operations for any resource, and no get_database by ID. These missing operations will require workarounds.
Average 3.6/5 across 25 of 25 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states that the tool gets chart definitions and form data, implying a read operation, but it does not explicitly disclose whether the operation is safe, requires permissions, or has any side effects. It also does not explain what 'form data' means or the structure of the response. This lack of detail is insufficient given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action ('Get'). It contains no unnecessary words or fluff, 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.
Completeness2/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, no output schema, no annotations), the description is insufficiently complete. It does not explain the required 'id_or_slug' parameter, the nature of the returned data, or the difference from sibling tools. An agent would have limited context to invoke this tool correctly. The description is a minimal statement of functionality but lacks the necessary guidance and expected behavior context.
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 parameter, 'id_or_slug', with no description, resulting in 0% schema description coverage. The tool description does not compensate by explaining the parameter's meaning, format, or usage. Although the parameter name is somewhat self-explanatory, the description should add context, but it does not mention the parameter at all.
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: retrieving chart definitions and form data for a dashboard. It uses a specific verb ('Get') and resource ('chart definitions and form data for a dashboard'), which distinguishes it from sibling tools like 'get_dashboard' or 'get_chart'. However, it does not explicitly differentiate itself from related tools such as 'get_dashboard_datasets' or 'get_chart_data', so it falls short of 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. It does not mention any contexts, prerequisites, or exclusions that would help an agent decide between this and sibling tools like 'get_chart_data' or 'get_dashboard_datasets'. There is no 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not specify what is returned (e.g., dataset IDs or full definitions), whether the result is a list, or any side effects/permissions. The word 'referenced' hints at a list but provides no concrete detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words, entirely front-loaded with the action and resource. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and no output schema, yet the description provides only a minimal statement of purpose. It lacks parameter guidance, return format expectations, and usage context, making it incomplete for an agent to confidently select and invoke the tool.
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 makes no mention of the only parameter, id_or_slug. The parameter name is somewhat self-explanatory, but the description adds no additional meaning or usage context beyond what the schema's title already 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 uses a specific verb ('Get') and resource ('datasets referenced by a dashboard'), clearly distinguishing it from siblings like get_dashboard_charts (charts) and list_datasets (all datasets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_dashboard or get_dataset. The intended use case is implied but not explicitly stated, and no exclusions or alternative tool mentions 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, the description carries the full burden. It does disclose that SQL is executed unchanged and that permissions are the safety boundary, which hints at potential side effects. However, it does not explicitly warn that SQL can be mutating, nor does it describe return behavior or async execution, leaving gaps for a dangerous 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 a single, front-loaded sentence with no wasted words. It states the core purpose and a safety caveat succinctly. However, it is so brief that it under-specifies critical aspects, though that is more relevant to completeness than conciseness.
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?
For a tool that executes arbitrary SQL, with no output schema, no annotations, and 6 undocumented parameters, this description is insufficient. It does not explain the return value, the effect of run_async or query_limit, or how this relates to sibling tools like get_sql_result. The tool is high-complexity and the description leaves many critical gaps.
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 provides no information about any of the 6 parameters (database_id, sql, schema, catalog, run_async, query_limit). The agent gets no help understanding what these parameters mean or how to use them, so the description fails to compensate 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute SQL') and the specific context ('through SQL Lab'), distinguishing it from sibling tools like get_sql_result or get_query. It is 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_sql_result or get_query. The safety-boundary remark is a caution, not a usage guideline, and no exclusions or alternative references are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It discloses the preview-vs-write duality and the confirm requirement, which is critical for avoiding unintended mutations. However, it does not disclose other potential side effects, permission requirements, or what the preview vs create modes return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose. Every word earns its place; there is no fluff. However, it is minimal enough that it leaves some gaps, though for the amount of content presented, it is appropriately concise.
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 5 parameters, no output schema, and no annotations, the description is too sparse to provide complete context. It does not describe return values, error conditions, or how preview mode output differs from create mode. The confirm requirement is helpful but does not cover the full range of behaviors an agent might encounter.
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?
Schema description coverage is 0%, so the description must compensate for missing parameter explanations. It only explains the confirm parameter ('required to write'). Other parameters (slug, owners, published, dashboard_title) have self-evident names but no explicit description of constraints, formats, or how they interact with the preview/create behavior.
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 identifies the verb 'create' and the resource 'dashboard', and adds the nuance of 'Preview or create', which distinguishes it from pure creation tools. It also mentions the confirm=true write requirement, which is a specific behavior not present in siblings like update_dashboard. However, it doesn't fully elaborate on what 'preview' entails or explicitly contrast with list/get dashboard tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the key condition for actual creation: confirm=true is required to write. This implies that the tool should be used when the agent wants to either preview a dashboard or create it, and that without confirm=true it stays in preview mode. But it does not explicitly say when to use this over alternatives (e.g., update_dashboard) or mention any prerequisites for 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, the description must disclose safety and side effects. It only says 'Get', implying read-only, but does not mention return structure, error behavior, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clear, front-loaded sentence. Every word contributes, though it may be too brief to convey necessary context.
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?
For a tool with no output schema and no annotations, the description is insufficient. It omits what the returned metadata includes, error cases, and any preconditions.
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?
Schema has one integer parameter with no description (0% coverage). The phrase 'by numeric ID' adds no semantics beyond the schema's type definition; it does not explain how to obtain the ID or expected format.
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?
Clearly states it retrieves dataset metadata using a numeric ID. This distinguishes it from sibling tools like list_datasets (which lists) and update/refresh 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 on when to use this tool versus alternatives like list_datasets or get_dashboard_datasets. The description only states what it does, not the appropriate 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 full responsibility for behavioral disclosure. It only mentions that databases are 'accessible,' which gives minimal context but does not explain pagination, search behavior, or the full structure of the response, leaving important behaviors undocumented.
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 extremely concise, one sentence with no wasted words. However, it could have used this brevity as an opportunity to add a bit more practical detail without harming clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values and behaviors. It only states that IDs are included, without mentioning other fields or the paginated response structure, making it incomplete for an agent relying solely on this 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 description provides no additional meaning for the three parameters (page, search, page_size) beyond their self-explanatory names. Since schema description coverage is 0%, the description fails to compensate, leaving agents to guess at search semantics or default page sizes.
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 accessible Superset databases and includes their IDs, using a specific verb and resource. This distinguishes it from sibling tools like list_datasets or list_dashboards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need to see available databases, but it does not provide explicit guidance on when to prefer it over alternatives such as list_datasets, nor does it mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds meaningful context about a confirmation gate ('confirm=true is required') and preview-versus-update behavior. However, it does not describe side effects, return values, or what a preview actually returns, leaving important 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 a single, front-loaded sentence that conveys the key purpose and the critical confirm requirement. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, no annotations, and a complex pre-view/update operation, the description is too sparse. It omits return value behavior, side effects, permissions, and how to interact with preview mode. The sibling list suggests related tools but the description does not connect to them.
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?
Schema description coverage is 0%, so the description must compensate for the 5 parameters. It names 'layout/metadata/publication' which maps loosely to position, metadata, and published, but does not explain their structure or the roles of dashboard_id and confirm beyond 'confirm=true is required'. This is minimal added value over the 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 identifies the tool as updating dashboard layout, metadata, and publication status, which distinguishes it from sibling tools like create_dashboard or get_dashboard. The phrase 'Preview or update' adds some ambiguity about the exact dual behavior, but the core purpose is clear.
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 stating 'Preview or update' and explicitly requires 'confirm=true' for actual updates, which is a practical usage guideline. However, it does not explicitly contrast with alternatives like create_dashboard or add_chart_to_dashboard, nor does it explain when to choose preview mode.
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 disclosing behavior. It only states the listing function and optional label search, but does not mention pagination behavior (page/page_size), sort order, or return format. This is a significant gap for a list tool with pagination parameters.
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 sentence that is concise and front-loads the core purpose. Every word earns its place, with no filler or 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?
For a simple list operation with no output schema or annotations, the description is minimally sufficient but leaves gaps. It does not explain pagination mechanics, what fields are returned, or the exact behavior of label search. However, given the tool's low complexity, this is not severely incomplete.
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 description coverage is 0%, so the description must compensate. It only briefly hints that 'search' is a label search, but does not explain the page or page_size parameters (e.g., zero-indexing, defaults, or effect). The schema titles and defaults help, but the description adds little semantic value beyond what is already inferable.
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 saved SQL queries, with an optional label search. This distinguishes it from sibling tools like get_saved_query, which retrieves a single query, and create/update_saved_query. The verb 'list' plus the resource 'saved SQL queries' is 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for listing queries, but it does not explicitly state when to use this tool versus alternatives (e.g., get_saved_query). No exclusions or context are provided, so the usage guidance is minimal but not misleading.
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 must carry full behavioral disclosure. It only says 'Get', which implies a read-only operation, but provides no details on error behavior, caching, or lack of side effects. This is minimal and leaves the agent to infer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. Every word is necessary, and there is no unnecessary detail or repetition.
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 adequately states the core function, but it does not describe the return value or behavior when the ID does not exist. The absence of an output schema makes this gap more noticeable, though the tool's simplicity mitigates the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for query_id (0% coverage), but the parameter name is self-explanatory. The description's 'by ID' clarifies that the integer is the identifier, but adds little beyond what the parameter name already conveys. It does not specify constraints or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'saved query' with clear scope: 'one by ID'. This distinguishes it from sibling tools like list_saved_queries (which returns all) and create/update variants, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a specific saved query ID is known, but it does not explicitly mention when to use this over list_saved_queries or how to handle non-existent IDs. No alternative tools are referenced, so guidance is limited.
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 of behavioral disclosure. It reveals the key behavior that confirm controls write operations and that the default is preview, which is important safety information. However, it doesn't disclose permissions, return values, or what exactly happens during preview, leaving gaps for a creation 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?
One sentence, front-loaded with the action, and every word earns its place. The semicolon separates the core function from the critical write condition, making it highly scannable.
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 six parameters, no annotations, no output schema, and no mention of prerequisites or return behavior, the description is too sparse. It gives the essential preview/write concept but omits what a preview returns, how required fields interact, and any permissions or side effects, leaving the agent under-informed 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 adds meaning to the 'confirm' parameter by explaining it gates writes, and implies 'sql' is central via 'SQL-backed.' Other parameters (database_id, table_name, owners, schema) are not addressed, so compensation is partial.
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 states a specific verb ('Preview or create') and resource ('SQL-backed virtual dataset'), making the tool's function clear. It distinguishes itself from siblings like create_chart or create_dashboard by focusing on virtual datasets, though it doesn't explicitly name alternatives.
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 usage context by explaining that 'confirm=true is required to write,' which tells the agent when a write occurs versus a preview. It doesn't mention when to prefer this over execute_sql or create_saved_query, but the core preview/write distinction is useful 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 must carry the full burden of disclosing behavior. It only mentions 'bounded pagination' without specifying the bound, and it omits details about default page/page_size, ordering, return format, or required permissions. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes to the core meaning, and it is 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a minimal tool with 3 optional parameters and no output schema. The description gives enough to know its basic function but leaves out details like the return shape (what dataset fields are returned) and defaults for pagination. It is adequate but not rich; slightly more context would make it complete for an agent.
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?
Schema description coverage is 0%, so the description must compensate. It does add some meaning by clarifying that 'search' is a name search and that pagination is bounded, but it does not explain the semantics of page/page_size (e.g., zero-indexing, default values, maximum page size). The parameter usage remains under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('List datasets'), identifies the resource (datasets), and distinguishes it from sibling list tools (e.g., list_saved_queries, list_dashboards) by naming the target resource. It also mentions two key features (optional name search and bounded pagination), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for listing datasets, optionally filtered by name and paginated. It does not explicitly state when not to use it or suggest alternatives, but the context is sufficient for a simple list operation.
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 transparency burden. It discloses a key behavioral requirement (confirm=true) and hints at a preview mode, which is valuable. However, it omits details about side effects, reversibility, permissions, or what preview returns.
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 sentence that front-loads the action and the key requirement. It contains no filler or redundant words, making it appropriately concise for the information it conveys.
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 tool has 7 parameters, no annotations, and no output schema, the description is too thin to be complete. It does not explain the preview/update workflow, the distinction between params and query_context, the effect on existing chart settings, or any return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It maps some updateable fields (params, query_context, dashboard_ids) and explains confirm's role, but it does not clarify the structure of free-form objects (params, query_context) or explain slice_name/description beyond their self-evident names.
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 specifies a clear action ('update' or 'preview') on a chart resource and lists the affected aspects (parameters, query context, dashboard links). It distinguishes from siblings like create_chart and get_chart, though the dual 'preview or update' phrasing introduces minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying an existing chart, but it does not explicitly state when to use it over alternatives like create_chart or update_dashboard. No when-not or alternative guidance is provided, leaving usage to be inferred.
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 of behavioral disclosure. It explicitly states the critical side-effect condition: 'No write occurs unless confirm is true,' which informs the agent about the safe preview mode and the actual write behavior. While it doesn't detail return values or error conditions, this is a substantial transparency improvement over typical create tools.
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 just two sentences, front-loading the main purpose and then adding the crucial confirm caveat. Every word earns its place, with no fluff or repetition.
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?
This is a complex tool with 9 parameters, 3 required, no output schema, and no annotations. The description is far too brief to cover the required context: what preview returns, how the saved query is stored, what extra_json and template_parameters do, and what happens on write. The agent is left with significant unknowns.
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?
Schema description coverage is 0% (no descriptions on the 9 parameters), so the description must compensate. It mentions 'confirm' indirectly but does not explain the key required parameters (db_id, label, sql) or optional ones like extra_json, template_parameters, schema, or catalog. The agent gets almost no guidance on what these values mean or how to use them.
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 core action: 'Preview or create a saved query.' The verb 'create' is specific to the resource 'saved query,' and 'preview' adds a secondary mode. This distinguishes it from siblings like update_saved_query, list_saved_queries, and execute_sql, which handle different operations.
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 when you need to preview or create a saved query, and the confirm flag provides a hint about the two modes. However, it does not explicitly contrast with alternatives like update_saved_query or explain when to prefer this over executing SQL directly. This 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the confirm requirement, which implies a two-step or confirmation-based behavior, but it does not explicitly state that refresh is destructive or what the side effects are. This adds some transparency but leaves ambiguity about the preview vs refresh semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and requirement. No wasted words or 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?
For a two-parameter tool with no annotations or output schema, the description covers the core action and the confirm flag, but it does not describe return values or the difference between preview and refresh outcomes. Some ambiguity remains about the tool's behavior, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It clarifies that confirm must be true for the operation to proceed, which is essential. However, it does not elaborate on dataset_id, which is self-explanatory but still undocumented. The description adds marginal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: preview or refresh dataset columns from its SQL. The verb 'refresh' and resource 'dataset columns' make it specific, and it distinguishes from sibling tools like update_dataset_sql by focusing on column refresh rather than SQL modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key operational requirement (confirm=true) but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool references are given; usage context is only implied through the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that 'force bypasses the Superset cache,' which is useful, but it does not explicitly state that the operation is read-only, error behavior, or return format. The core behavior is clear, but some transparency gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the primary action and appending the cache-bypass detail. Every word earns its place, with no redundancy or extraneous information.
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 (two parameters, no output schema), the description is largely sufficient. It covers the main function and one parameter's behavior, but lacks details on return data structure or error conditions. This is a minor gap in an otherwise adequate description for a straightforward read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'force' parameter's cache-bypass effect, but 'chart_id' is only self-evident from its name. This partial coverage is helpful but not fully compensating for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Run the stored chart query and return its data.' It distinguishes this from siblings like get_chart (chart metadata) and get_sql_result (arbitrary SQL), as it targets saved chart queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or mention of alternatives. The context of sibling tools implies usage, but there is no stating of when this should be used over get_sql_result or other fetch tools.
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 tool checks JWT auth, current-user access, and optional OpenAPI availability, but it does not explicitly state side-effect safety (e.g., read-only, no state changes). The lack of explicit behavioral disclosure is a moderate gap, though the nature of a status check mitigates risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that lists all key validation targets without waste. It is concise, grammatical, and immediately conveys the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter), the presence of an output schema, and the description covering all main validation points, the context is largely complete. It could add nuance about failure modes or what 'configuration' entails, but the essential information for selecting and invoking the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by mentioning 'optional OpenAPI availability,' which maps to the check_openapi parameter. However, it does not explicitly state the boolean's effect (e.g., false disables the check), relying on the parameter name. This is adequate but not richly explanatory.
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 validates configuration, JWT authentication, current-user access, and optional OpenAPI availability. The verb 'validate' and specific resources make the purpose unambiguous, and it is distinct from sibling tools that operate on saved queries, charts, and datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a health/status check, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or recommended call patterns. As a standalone status tool among data-operation siblings, the context is somewhat clear, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It explicitly states that writing only occurs when confirm=true, which is a key behavioral trait, preventing accidental mutations. It does not mention permissions or return details but sufficiently discloses the conditional-write behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose and including the essential confirm instruction. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested objects, no output schema, no annotations), the description is too sparse. It omits parameter semantics, return values, and prerequisites, leaving the agent under-informed for correct invocation.
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?
Schema description coverage is 0%, so the description must compensate. However, it only clarifies the confirm parameter ('confirm=true is required to write'). Other parameters like params, viz_type, and datasource_id are left unexplained, providing minimal value beyond their field 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 clearly states the tool's function with a specific verb ('preview or create') and resource ('chart on a Superset dataset'), and distinguishes it from sibling operations like update_chart or get_chart_data. The confirm=true flag further clarifies the dual-mode nature.
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 gives concrete usage context by stating that confirm=true is required to write, implying preview mode when omitted. It does not explicitly name alternative tools or when not to use it, but the confirm instruction offers clear guidance on invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool fetches metadata (not data) and accepts ID or UUID, but it says nothing about permissions, errors, or return behavior. For a simple read operation this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description does not specify what 'metadata' includes or any return structure. It is sufficient for a basic fetch but leaves some ambiguity about the response.
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 1 parameter with 0% description coverage, but the phrase 'by ID or UUID' clarifies the `id_or_uuid` parameter meaning and accepted formats. The single parameter's semantics are effectively covered by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and resource 'chart metadata' with identifier types 'ID or UUID'. It clearly distinguishes from siblings like get_chart_data (which retrieves data) and get_dashboard/get_dataset (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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs chart metadata and has an ID or UUID, but it does not explicitly state when not to use the tool or name alternatives. There is no contextual comparison with 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?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only says 'get metadata,' which implies a non-destructive read, but it does not explain return format, error behavior (e.g., not-found), authentication requirements, or what 'metadata' specifically includes. This is a significant gap for a tool with no auxiliary structured annotations.
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, clear sentence with no filler. It delivers the necessary information about resource, action, and identifier type in a compact format. Every word earns its place.
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 one-parameter retrieval tool, the description is minimally viable. It states the action and how to specify the target, but because there is no output schema, it does not describe the returned metadata structure. It also does not mention any edge cases or related tools. This is a common level of completeness for a basic getter, but it leaves room for improvement.
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 provides only a required string parameter 'id_or_slug' with no description (0% coverage). The description compensates by explaining the parameter accepts a numeric ID or a slug, giving essential semantic meaning. It does not detail slug format, but it adds enough for an agent to understand the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and the resource (dashboard metadata), and specifies the identifier form (numeric ID or slug). It distinguishes from sibling tools like list_dashboards (which lists) and get_dashboard_charts/datasets (which retrieve specific subresources).
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 'by numeric ID or slug' provides clear usage context: call this when you already have a dashboard identifier. It does not explicitly mention alternatives or exclusions, but the identifier requirement implies when to use it. Sibling tools like list_dashboards are not referenced, but the guidance is sufficient for a get-by-ID tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It implies a read-only operation via 'Get' and clarifies the data scope (history/status), but does not disclose potential errors, permissions, response shape, or rate limits. It provides some value beyond the schema but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that clearly conveys the tool's purpose. No wasted words, front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description is adequate but does not explain what 'details' includes or how it differs from get_saved_query. Given no output schema, more detail on return values would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'query ID' which aligns with the sole parameter query_id, but adds little beyond the schema: the schema already defines query_id as an integer. Since schema coverage is 0%, the description's 'by query ID' is essentially redundant, though it does confirm the parameter is the identifier for the query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' and identifies the resource as 'Superset query history/status details' with a clear access method 'by query ID'. This differentiates it from sibling tools like get_saved_query or get_sql_result by focusing on history/status rather than saved definitions or result sets.
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 clearly implies when to use: when you need query history/status details by ID. It does not explicitly state when not to use it or name alternative tools, but the context is unambiguous enough for the intended purpose.
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 and provides some behavioral context through 'bounded pagination' and 'optional title search'. However, it does not explicitly state read-only behavior, return format, or the actual pagination limit, leaving notable transparency 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?
One front-loaded sentence states the action, resource, and key modifiers without any filler. It is 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 simple list tool with optional search and pagination, the description covers the essential selection criteria. It could mention return shape or default behavior, but the low complexity and sibling context make the current level adequate.
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?
Since schema description coverage is 0%, the description compensates by clarifying that 'search' targets titles and that page/page_size implement bounded pagination. This adds meaning beyond the bare schema, though it does not elaborate on exact bounds or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with resource 'dashboards' and adds relevant modifiers ('optional title search', 'bounded pagination'), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like get_dashboard, create_dashboard, and update_dashboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for browsing or searching dashboards, but it does not explicitly state when to prefer this over get_dashboard or other list tools. It lacks exclusions or alternative recommendations, so usage guidance remains implicit.
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?
The description discloses a key behavioral trait: confirm=true is required to write, indicating a two-phase (preview/commit) operation. This adds meaningful context beyond the schema, and since no annotations are provided, it carries the full burden of transparency for this significant behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the purpose and includes the critical confirmation constraint. 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 a simple parameter set, no output schema, and no annotations. The description covers the essential operational nuance (preview vs. write) and is sufficient for an agent to understand the core behavior, though it omits details like return values or side effects, which are less critical at this 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?
The description adds meaning to the confirm parameter by explaining its role in writing, but it does not describe chart_id or dashboard_ids, relying on their self-explanatory names. With 0% schema description coverage, this is only partial compensation for the parameter semantics gap.
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 clear verbs 'Preview' and 'add' with a specific resource ('a chart to one or more dashboards'), which immediately distinguishes it from sibling tools like get_dashboard_charts or create_dashboard. The scope of action is explicit 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 implies when to use the tool (for previewing or adding charts to dashboards) and emphasizes the confirm=true requirement for writing, which guides safe invocation. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to distinguish it from related tools.
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 discloses the asynchronous nature of the result, but does not explain behavior around readiness, errors, or idempotency. This is more than a bare tautology but lacks rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately states the action and required input. No wasted words; every phrase contributes meaning.
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 one-parameter retrieval tool, the description is adequate: it names the input and its origin. It does not mention return value shape or error conditions, but given the tool's simplicity and lack of output schema, the description covers essential 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?
Schema coverage is 0% and the schema only labels the parameter as 'Result Key'. The description adds meaning by clarifying it is the key returned by execute_sql, which is essential for correct invocation. This compensates well for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states the tool 'Retrieve[s] an asynchronous SQL Lab result' using a resultsKey from execute_sql. This clearly identifies the verb, resource, and mechanism, and distinguishes it from sibling tools like execute_sql by framing it as the retrieval counterpart.
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?
Usage is implied through 'using the resultsKey returned by execute_sql', which tells the agent when to invoke this tool (as a follow-up to an async execution). It does not explicitly list alternatives or exclusions, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the preview/replace dual behavior and that confirm=true is needed for the mutation. However, it does not describe side effects like whether the change is irreversible, how SQL is validated, or what happens on failure. The disclosure is minimal but meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and the critical requirement in a compact form.
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 tool with three parameters and no output schema, the description covers the essential usage. It does not explain return values or error conditions, but the tool's simplicity and the clear preview/replace framing make it largely complete. Slight gaps remain regarding validation or post-update behavior.
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 meaning to the 'confirm' parameter by explaining that confirm=true is required for replacement, implying a preview when false. This goes beyond the schema's default value. It does not explicitly define dataset_id or sql, but their names are self-explanatory and the description implicitly references them ('existing virtual dataset', 'SQL').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs: 'Preview or replace SQL' for 'an existing virtual dataset'. It distinguishes itself from sibling tools like create_virtual_dataset and execute_sql by specifying this is about updating an existing dataset's SQL, not creating or executing.
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 the tool (to preview or replace SQL of an existing virtual dataset) and includes a key usage guideline: 'confirm=true is required' to actually perform the replacement. It does not explicitly mention alternatives, but the domain is narrow and obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for behavioral disclosure. It explicitly states that unspecified fields are preserved (partial update semantics) and that confirm=true is required to write, effectively explaining the two-phase preview/commit behavior. This is valuable context beyond what the schema alone provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the primary purpose and key constraints. No unnecessary words or repetition.
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 workflow (preview vs. write, partial updates) but omits details about the meaning of several parameters, possible error conditions, or return behavior. With no annotations and no output schema, this is a clear gap, though the core usage is understandable.
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?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It only clarifies the role of confirm (required to write) but provides no explanation for other parameters like sql, db_id, extra_json, or template_parameters. Given 10 parameters, this is a significant gap.
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 can 'preview or update a saved query', which is a specific action on a specific resource. It also distinguishes from sibling tools like get_saved_query (read) and create_saved_query (new) by focusing on the update/preview workflow for existing queries.
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 useful context by indicating this tool is for previewing or updating an existing saved query, and that confirm=true is required to actually write. It doesn't explicitly name alternative tools or state when not to use it, but the preview/update workflow and confirmation requirement imply a clear usage pattern.
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:

[![superset_v4_mcp MCP server](https://glama.ai/mcp/servers/Amit-DAlal-1/superset_v4_mcp/badges/card.svg)](https://glama.ai/mcp/servers/Amit-DAlal-1/superset_v4_mcp)

Score Badge

Copy to your README.md:

[![superset_v4_mcp MCP server](https://glama.ai/mcp/servers/Amit-DAlal-1/superset_v4_mcp/badges/score.svg)](https://glama.ai/mcp/servers/Amit-DAlal-1/superset_v4_mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Amit-DAlal-1/superset_v4_mcp'

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