Skip to main content
Glama

query_dataset

Query a Superset dataset using metrics and dimensions, aggregating over columns without raw SQL. Supports time-series, filters, and sorting.

Instructions

Query a dataset using Superset's metric/dimension abstraction.

This executes the same query path that charts use — aggregating metrics over dimension columns — without needing raw SQL. Use get_dataset to discover available metrics and columns first.

For time-series queries, set time_column plus start/end (ISO-8601) and optionally granularity (e.g. "P1D", "P1W").

Args: dataset_id: ID of the dataset to query metrics: Metric names to aggregate (e.g. ["count", "revenue"]) columns: Dimension columns to group by time_column: Time column for time-filtered or time-series queries start: Start date/time in ISO-8601 format (e.g. "2025-01-01") end: End date/time in ISO-8601 format (e.g. "2025-06-01") granularity: Time grain (e.g. "P1D", "P1W", "P1M") where: SQL WHERE clause fragment for filtering having: SQL HAVING clause fragment for post-aggregation filtering order_by: Columns or metrics to order by order_desc: If True, sort descending (default: True) row_limit: Max rows to return (default: 10000) force: If True, bypass query cache response_mode: 'compact' (columns only), 'standard' (sample rows), or 'full' (all rows). Default: standard.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataset_idYes
metricsYes
columnsNo
time_columnNo
startNo
endNo
granularityNo
whereNo
havingNo
order_byNo
order_descNo
row_limitNo
forceNo
response_modeNostandard

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes query path, aggregation, time-series support, caching (force parameter), and response modes. Given no annotations, it carries the burden well, but lacks explicit statements about being read-only or side effects. Still, it covers many 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a clear one-liner, followed by a brief explanation and structured Args list. While somewhat lengthy, each sentence serves a purpose and the structure is logical. Minor redundancy in describing time-series could be trimmed.

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?

Covers main use cases (aggregation, time-series, filtering) and prerequisites. Mentions output schema exists but doesn't describe return values, which is acceptable. Could include error handling or usage beyond time-series, but overall complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the detailed Args section fully explains each parameter's meaning, format (ISO-8601 for dates), examples for granularity, and response_mode values. Description adds all necessary semantics beyond 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?

Clearly states it queries datasets using Superset's metric/dimension abstraction, differentiating from raw SQL and aligning with chart queries. The tool's purpose is specific and distinct from siblings like run_sql.

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?

Provides a clear prerequisite (use get_dataset first) and contrasts with raw SQL. However, it lacks explicit when-not-to-use or alternatives to other siblings like run_sql or validate_chart. Guidance is present but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/Evan-Kim2028/preset-mcp'

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