The honest centre of it is get_chart_params: chart creation fails without the right parameter structure, so the server makes fetching that structure a first-class call rather than something you reverse-engineer from the UI. Sharp edges are stated where they exist — deleting a dataset is permanent and breaks the charts built on it, and set_chart_filters writes into the chart's stored query context rather than filtering a view.
A server over the Superset REST API, 32 tools across charts, datasets, metrics and calculated columns, database queries and dashboards.
- get_chart_params returns the exact parameter schema for a visualisation type, which is the step create_chart and update_chart are built to depend on
- Charts listed with Rison or JSON filtering, sorting, pagination and column selection, and one chart read in full — parameters, datasource, ownership, dashboards and tags
- Chart-level data filters extracted from the query context and written back
- Physical datasets linked to a table or virtual datasets defined by SQL, with find_and_replace_in_sql editing that query by exact text
- Dataset metrics and calculated columns created, updated and deleted in batches, with get_dataset_columns to see what fields are available first
- refresh_dataset_schema re-syncs a dataset after columns change in the source table
- SQL executed against a configured database through the SQL Lab endpoint, with a row limit and expandable output
- A dashboard chart's full query context — dataset ID, metric SQL expressions, calculated columns and every applied filter — in one read
- Charts added to a dashboard with a position in the layout, removed with their layout nodes cleaned up, and embedded configuration updated
SUPERSET_BASE_URL plus a SUPERSET_USERNAME and SUPERSET_PASSWORD pair that can sign in to that instance and reach the databases you intend to query.
One command plus a key — npx -y superset-mcp, then supply credentials