Apache Superset MCP server for AI assistants

What the Apache Superset MCP server for AI assistants changes

A data or BI team is often asked to let AI assistants answer questions from Superset dashboards and charts. The MCP server changes the access path, not the data: an MCP client such as Claude or ChatGPT connects to a Superset instance your team operates, and the assistant can then request information that Superset exposes to it through the server's tools. Before anything is enabled, confirm which MCP tools and resources your chosen Superset version exposes in its documentation, because the set of capabilities is version-specific and should not be assumed from the feature name alone.

The central point is that an assistant connection is a new client to your Superset, not a bypass around it. Requests arriving through MCP must pass the same permission model as the web interface: the user's roles, the dataset and database access those roles grant, and any row level security filters attached to the datasets involved. The authentication method you configure, JWT or OIDC as covered elsewhere on this page, determines whose identity the assistant acts under. Treat that identity as the control point, and test it with a user whose access is deliberately narrow before any broader group is connected.

This changes three decisions for the owning team. First, you decide which service identities or users may use MCP at all, since a shared or over-privileged account would give every assistant user more reach than the web interface does. Second, you decide whether tool calls are logged in a form your security team can review, and confirm what the audit trail records for MCP activity in your version. Third, you plan for load: assistant queries run against the same warehouse as dashboards, so worker limits and query timeouts need an owner. Ask your Superset administrators to document these three choices before the first pilot user connects.

How JWT and OIDC login map an assistant to a Superset user

Every tool call an assistant makes through the Superset MCP server must be attributed to an identity, and that identity decides what the assistant can see. The assistant does not get its own permission set. It acts as a Superset user and inherits that user's roles, database access and row level security filters. A user who cannot open a dataset in the Superset interface cannot reach it through an assistant either, and a user limited to one region sees only that region's rows in every answer. Before rollout, decide which Superset users an assistant may act as, and treat that mapping as the access model you are approving.

The two common token patterns differ in operational terms. A static JWT issued for a service identity is simple to configure, but every assistant session shares one account, so the audit trail shows the service rather than the person asking. Revoking it cuts off every user at once, and offboarding an employee does nothing to the token, because the token never belonged to them. An OIDC flow tied to a named user authenticates each person through your identity provider. Access follows the user's group membership, offboarding removes access when the identity provider disables the account, and audit entries name the individual. The cost is more setup: the identity provider, client registration and token handling all have to be configured and tested.

Confirm the exact token settings, audiences, signing algorithms and endpoints in the Superset documentation for the version you run, because MCP authentication details can change between releases. Check whether the MCP server validates tokens against your identity provider's keys, how long tokens live, and how refresh behaves when a user's group changes. Test with two accounts holding different roles and confirm that each sees only its own datasets and rows before any assistant client is connected.

Authentication and access options for MCP clients

This table compares three access models for an AI assistant connecting to a self-hosted Superset through its MCP server. Read each column as one complete option, and check the owner and revocation rows before you decide, because they determine who you call when access must end. The main takeaway is that the identity an MCP client uses sets what the audit log can attribute, so decide that before setup.

Decision point	Dedicated service account with JWT	Per-user OIDC sign-in	Read-only analyst role
Best fit	Shared automation or a single assistant integration with one approved purpose	Teams where each person should use their own Superset permissions through the MCP client	Limiting what any MCP client can reach, whatever identity it uses
Who owns token lifecycle	Your platform or security team issues, stores and rotates the JWT	Your identity provider controls sign-in and session length, with the MCP client receiving tokens after login	Depends on the identity behind the token, so it is shared with the option you pair it with
How revocation works	Revoke or stop issuing the service account's token, and disable the account if it is no longer needed	Disable the user or remove them from the group in your identity provider, then confirm the session ends in Superset	Remove the role from the account or group, or change the database and dataset permissions it grants
What the audit log attributes	Actions to the service account, so you need a separate record of which person or workflow used it	Actions to the individual user, which supports per-person review	Actions to whichever identity is used, so the role limits impact but does not add attribution
Data reach	Whatever the service account's roles allow, so scope it deliberately	Each user's existing roles, row level security and database access	Only the databases and datasets granted to the role, which should be confirmed in your environment
Main risk	A long-lived credential that many people or tools can reach	Users inherit broad roles they already have, which the assistant then exposes	Overlooked grants, such as a shared dataset or a permissive database, widen what the role can read
What to confirm before setup	Token issuance and expiry settings in your Superset version, and where secrets are stored	How your identity provider and Superset map groups to roles for MCP clients	Which databases and datasets the role can access, tested with a sample query

Setting up the Superset MCP server step by step

This sequence takes a self-hosted Superset from version confirmation to an AI assistant that can query only the datasets its role allows. Each step ends with a check you can record, so the setup can be signed off before any assistant reaches production data.

Confirm the version and MCP documentation
Your platform team confirms which Superset release you run and reads the MCP server documentation for that exact version, because the feature set and setting names can differ between releases. Superset 6.1.0 was published on PyPI on May 13, 2026, and 7.0.0rc2 is listed on GitHub as a pre-release, so do not assume a pre-release behaves like the stable line. Done when you have a written note of the version, the documented setting names and the authentication methods the docs support for MCP clients. Ask your vendor contact or DeployOpen to confirm any gap before the next step.
Configure identity and tokens in staging
In a staging copy of the platform, the identity owner configures the identity provider and the JWT or OIDC settings your version documents for the MCP server. Map the assistant to a dedicated service account that belongs to no individual user, and set token lifetimes that your identity policy allows. Done when a test token issued for that account is accepted by staging, and an expired or wrongly issued token is refused. Keep the configuration in version control so the production change can be reviewed.
Create the assistant role and dataset access
Create a role for assistant traffic that grants only the database connections, datasets and dashboards the use case needs, then assign it to the service account from the previous step. Apply row level security filters to any dataset that holds customer or employee rows, so the assistant sees the same restricted rows a person in that role would see. Done when a test query from the account against a dataset outside the role returns a permission error, and an in-scope dataset returns only the rows its row filter allows.
Enable the MCP server through its setting
Turn on the MCP server with the feature flag or configuration setting named in the documentation for your confirmed version, and do not copy setting names from forum posts or older guides. Restart the web and worker processes the way your deployment normally does, then confirm the endpoint refuses unauthenticated requests. Done when an unauthenticated request is refused and an authenticated test request succeeds from the staging network. Record the change in your change log before promoting it to production.
Connect one MCP client and run a query
Connect a single MCP client, such as Claude or ChatGPT where the client supports MCP, using the endpoint and token from the earlier steps. Limit the first test to one assistant user and one non-sensitive dataset. Ask a question the role allows, then ask one about a dataset outside it. Done when the allowed question returns results that match the same chart run in the Superset interface, and the forbidden question fails without exposing column names or sample rows.
Verify audit entries and query limits
Check that each tool call from the assistant appears in your audit or event log with the service account, the tool name and the timestamp, using the logging your version provides. Run a deliberately heavy query through the assistant to see how worker limits and query timeouts behave, and confirm they match the limits your SQL Lab users face. Done when the log entries are complete enough to answer who asked what and when, and the slow query stops at the configured limit instead of continuing to run.

Where the MCP server fits by rollout stage

A pilot puts the MCP server in front of a small analyst group, usually on one Superset instance with a test or staging metadata database. The main question is not scale. It is whether an assistant can only reach what the analyst could already reach in the Superset interface, and whether every tool call can be traced back to a person.

Identity scope: Give each pilot user a named Superset account with the roles they already hold. Avoid a shared service account for testers, because tool calls would then be attributed to one identity in the logs.
Data scope: Limit the pilot to datasets analysts already use, and test that RBAC and row level security filters apply to the queries an assistant sends.
Log retention: Decide where tool call records are written and how long they are kept before the pilot starts, even if the volume is small.
Metadata database: Use PostgreSQL or MySQL from the start if the pilot may become production, since the architecture documentation does not recommend SQLite or the Docker Compose PostgreSQL container for production.

Before moving on, ask the team which identity each MCP client uses, which tool calls were recorded in a test session, and what a user without access to a dataset receives when an assistant requests it.

Which Superset controls still decide what an assistant sees

An MCP client does not get a separate data path into Superset. Every tool call runs as a Superset user, so the same permissions, filters and limits that govern the web interface also decide what an assistant can read. The cards below cover the controls to verify with the assistant identity before you widen its access.

Roles and dataset permissions

The assistant acts as a Superset user, so it can only reach the dashboards, charts and datasets that user's roles grant. Map the assistant to a dedicated service identity with the narrowest role set that answers the questions you expect. Then confirm, by calling the tools as that identity, that datasets outside the role are not listed or returned. Assume nothing about what the model can discover on its own.

Database-level access

Dataset permissions sit on top of database connections, and some teams forget that a connection can expose more tables than the datasets built on it. Check which database connections the assistant identity can use, and whether any ad hoc or SQL access path exists for that identity. Where the assistant does not need SQL Lab or raw query capability, confirm it cannot reach it through the tools you enable.

Row level security filters

Row level security applies to MCP-originated queries because the filter is attached to the dataset and evaluated when the query runs under the user's identity. The common mistake is to assume the assistant sees only the rows the user is allowed to see, when the filter depends on a group key or user attribute that the service identity does not carry. Test a filtered dataset with each identity the assistant will serve.

SQL execution limits

Assistants generate queries quickly and often without regard to cost. Confirm the row limits, query timeouts and any asynchronous execution settings that apply to the connection and to Superset's query path. Ask the vendor or your own tests which limits apply to tool-originated queries, and measure the load a broad natural-language question places on the warehouse before exposing it to users.

Export and download controls

Even when an assistant returns only a filtered result, the text it produces can be copied into a chat transcript, a ticket or a third-party model service. Review which export, CSV download and clipboard paths the assistant identity can reach, and decide whether results with sensitive columns should be returned at all. Record the decision in your data classification policy.

Test each control before expanding access

Treat every control above as unproven until you have run it with the assistant identity. Build a short test set: a dataset the identity should not see, a filtered dataset with two users, a query that exceeds your limits and an export attempt. Repeat the set after each Superset upgrade or role change, and keep the results with your audit evidence before you give wider groups access.

Audit logging of tool calls and worker limits to plan for

Plan the audit trail for assistant activity before you enable the MCP server, because an assistant query is only useful as evidence if it can be tied to an identity, a tool, a dataset, a time and an outcome. For each tool call, the team should be able to answer who or what made the request (the human user whose token was used, or a dedicated service identity), which MCP tool ran, which Superset dataset or chart it touched, when it happened, and whether it succeeded, was denied or failed. Superset's own event and audit logging covers much of the web application activity, but you should confirm with the Superset configuration documentation and your own tests exactly which fields are written for MCP-originated calls, including whether the token subject is recorded, before you rely on it for an audit. Where a field is missing, plan a compensating record at the gateway or MCP client layer rather than assuming it exists.

Route these records to the same log store your security team already reviews, not to the Superset container's local output. Decide the retention period, who can read the records, and how the token subject is mapped back to a directory identity. Test the pipeline end to end by running a known query through an assistant, then confirming that the record arrives with the expected identity, dataset and outcome. Also decide how denied row level security results and query errors will be flagged, since they are often the first sign of an assistant probing data it should not see.

Plan worker capacity as a shared resource. Per the Superset architecture documentation, alerts and reports, async queries and dashboard thumbnails depend on the caching layer and Celery worker and beat components, and most installations run Redis and Celery for them. Long-running queries and scheduled report jobs use the same workers, so a burst of assistant questions can delay a Monday morning report or the reverse. Check the architecture documentation to see which of your enabled features depend on those components, then decide whether assistant traffic gets its own worker queue, its own concurrency limit, or a timeout that stops runaway queries. Ask your database team for the query limits they will enforce on the Superset service account, because the warehouse is where the load actually lands.

Limits to confirm before exposing Superset to AI clients

An MCP server gives an AI client a standing path into your analytics data, so its release status, exposed tools and identity flow need checking before any user connects. The items below are the questions to settle in a test environment and against the vendor documentation.

Release and stability status

Confirm which Superset release includes the built-in MCP server and whether that feature is marked stable, experimental or behind a feature flag. Superset 6.1.0 was published on May 13, 2026 and 7.0.0rc2 is a pre-release, so check whether the MCP server appears in the version you plan to run. Record the exact version in your change ticket, because the interface may change between releases.

Default exposed tools

Ask which MCP tools are enabled out of the box, which ones can read data, and which ones can change dashboards, charts or datasets. List every tool in a test instance and compare it with the actions your analysts actually need. Plan to disable any write or export capability that the assistant use case does not require.

Supported identity flows

Confirm which authentication methods the MCP server accepts, such as JWT bearer tokens or OIDC-issued tokens, and how the token audience, expiry and signing keys are configured. Test that a token issued to one user cannot be reused by another client. Verify that the identity the server sees is the one RBAC and row level security evaluate.

Rate and concurrency controls

Ask whether the MCP server offers request rate limits, per-user quotas or concurrency caps, and where they are enforced: the web server, a gateway or the Superset application. An assistant can issue many queries in a short loop, so test how a runaway session affects the warehouse and the web tier. Check what the Celery worker limits and SQL execution timeouts do to long-running tool calls.

Data residency of prompts and results

Determine where prompts, tool arguments and returned rows travel when a client such as Claude or ChatGPT calls the server. Some AI providers process data outside your region or retain it under their own terms, so review the provider agreement and the host's data handling documentation. Confirm which result fields reach the model and whether sensitive columns can be masked before they leave Superset.

Storage of returned data by the assistant host

Find out whether the assistant host keeps tool results in chat history, logs, memory features or caches, and for how long. A query that returned customer records may persist in a conversation transcript long after the analyst closed it. Ask the host vendor about retention, deletion and admin controls, and make sure your audit logging captures every tool call so the trail does not depend on the host.

Questions teams ask before adding an AI assistant to Superset

Can our own team connect an AI assistant to Superset without a partner?

Yes, if your team already runs Superset in production and has people who manage its identity configuration, database roles and staging environment. The work is mostly configuration and verification rather than new software. It does touch authentication, access rules and logging at the same time, so a mistake in one area can expose data through another. Teams new to Superset administration usually find the access model and the audit trail harder than the connection itself. A partner adds value when you need an independent review of who can see what. Whichever route you take, ask for a written scope that lists each identity provider, role, database and log source covered by the work.

What drives the cost of an MCP integration for Superset?

Cost follows the number of decisions and systems involved. The main drivers are the identity integration, including how many identity providers you use and how groups map to Superset roles through AUTH_ROLES_MAPPING. Data model cleanup matters because an assistant can only be as well governed as the datasets and row level security filters behind it. Audit logging and testing add effort in proportion to the number of roles and databases in scope. Most of this is one-time work. Recurring costs come from upgrades, access reviews and log retention. In a quote, ask for these items priced separately, plus the assumptions about identity providers, databases and environments that the estimate depends on.

How long does a pilot take to run?

A pilot length depends on what is ready on the first day, so the useful question is which inputs are in place. A pilot moves quickly when a staging Superset matches the production version, the identity provider client registration is available, read-only database roles exist for the pilot datasets, and named data owners can approve the datasets the assistant will query. It slows down when any of those inputs arrive late. Upgrades also need a staging test first according to the Superset upgrade documentation, so plan that test into the pilot if the version may change during the work. Ask a partner to tie each phase of the pilot to a named input and an owner.

What must our team provide for an MCP engagement on Superset?

The team needs to provide access and decisions that only your organization can give:

Administrative access to your identity provider, so an OAuth2 or OIDC client can be registered for Superset and group claims can be checked
Read-only database roles for each warehouse or database the assistant will query, created by your database administrators
A staging Superset that tracks the production version and metadata database, so changes are tested before release
Ownership of the secret key, metadata database backups and the log destination for audit records
Named data owners who approve which datasets, metrics and row level security rules are exposed to the assistant

Ask the partner to confirm this list in writing before the work starts.

Can an AI assistant see data that its user cannot see in Superset?

It should not, but you need to verify this for your setup rather than assume it. The design goal is that the assistant acts with the signed-in user's identity, so Superset's role-based access control and row level security decide what it can read. Check this with a restricted test account and compare the results with what the same user sees in the Superset interface. Also review the database connection. If every Superset user shares one broad database account, the database cannot tell which user asked for which rows, so row level security in Superset becomes the only control. Confirm the exact enforcement behavior of the built-in MCP server in the version you deploy.

Does the Superset MCP setup log each tool call for audit?

You should require it, and confirm what the built-in server records before you rely on it. An audit record for an assistant should show the authenticated user, the tool called, the dataset or chart touched, the time, and the outcome. Those records need to reach your central log platform with retention that matches your policy, because an assistant produces more queries than most dashboards. Test the trail by running a known query as a test user and checking that every expected field appears. Also agree with your security team who reviews these logs and how often. Auditors will ask for evidence of that review, not just the existence of the logs.

When does a support retainer make sense for Superset upgrades?

A retainer makes sense when Superset runs in production and you want upgrades handled on a predictable schedule. The upgrade path itself is documented: back up the metadata database, run superset db upgrade and superset init, test in staging, and check UPDATING.md for breaking changes between versions. Upgrades also affect the MCP integration, so each one needs regression tests for authentication, access rules and audit logs. Deployment method matters too. The Helm chart is marked deprecated in current development documentation, and the Kubernetes Operator is in alpha with a v1alpha1 API that may change between releases. Ask any provider how it will track those changes and what a retainer covers versus a fixed-scope upgrade.

How DeployOpen scopes and delivers an MCP server rollout

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes an MCP server rollout for Apache Superset. We agree scope, deliverables and timelines in writing before work starts, so the access model, authentication and audit trail are settled before any AI client connects.

How we scope

Written scope lists which MCP tools and datasets AI clients may reach on your Superset.
Scope records the JWT or OIDC identity provider and how its groups map to Superset roles.
Scope states which RLS rules, worker limits and audit log destinations are in and out of the work.

How we build

We deploy the MCP server within your own infrastructure alongside your existing Superset instance.
We configure authentication so every tool call runs under a named user with its own permissions.
We test RBAC and row level security through MCP calls, then check tool call logging end to end.

How we hand over

You receive documentation of the configuration, access model, tool inventory and audit log fields.
Handover covers the runbook for rotating signing keys, adjusting worker limits and revoking client access.
Your team reviews test results and signs off the rollout before AI clients go to wider audiences.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrade planning follows the Superset upgrade steps, including staging tests and breaking change review.
Retainer work can repeat authentication and access tests whenever roles, datasets or identity providers change.