Agent using MCP cannot properly compute metrics

[fbengayed]

Hi
I am trying out an agent using superset MCP.
Somehow, whenever I ask it to create a chart with some aggregated values, it either uses an existing metric but omits the "saved_metric: True" parameter, or it writes the aggregation SQL on the fly, but always references a non existing column (for example, if I ask it to count the number of rows per category or per day, it will reference the in existing column "count").
Has anyone else had issues with this ?

[dosubot[bot]]

Yes, these are known limitations of the MCP server's metric handling that have been actively worked on. A few things to be aware of:

The saved_metric: true omission was addressed in PR #38981 (merged March 31, 2026), which clarified the MCP schema and instructions so that LLMs properly use {"name": "metric_name", "saved_metric": true} when referencing existing dataset metrics [1].

The non-existent column references (e.g., referencing a "count" column that doesn't exist) happen because the MCP's metric schema previously only supported fixed aggregate functions (SUM, COUNT, etc.) applied to actual dataset columns. When an AI agent tries to compute something like "count of rows," it may hallucinate a column name rather than correctly specifying a COUNT(*) metric.

Custom SQL metric support was added in PR #40448 (merged May 28, 2026), which introduced a sql_expression field allowing agents to express complex SQL adhoc metrics directly [2].

There's also a related feature request (#40917) that documents the broader gap around Custom SQL metrics and virtual dataset limitations [3].

Suggestions:

• Make sure you're on the latest Superset version to get the saved_metric and sql_expression fixes
• When prompting your agent, you may need to explicitly instruct it about the correct metric schema (e.g., use saved_metric: true for existing metrics, or use the sql_expression field for ad-hoc aggregations)
• If the agent is still referencing non-existent columns, it's likely an LLM prompting issue — the agent needs to be told to use dataset columns that actually exist (you can use the MCP's dataset inspection tools to list available columns/metrics first)

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[allenjiji]

The agent invents a "count" column because it is being asked to write the aggregation itself. One way around this is to let it pick field names only and have a planner generate the SQL. That is what 0sql does (disclosure: I work on it).

The agent sends:

{
  "projections": [
    { "field": "category" },
    { "field": "row count" }
  ]
}

And gets back:

SELECT T0.category AS "Category",
       count(*) AS "Row Count"
FROM orders T0
GROUP BY T0.category

"Row count" is defined once in the model as count(*), so the agent never needs to know how it is implemented. If it asks for a field that doesn't exist, it gets a refusal with the nearest valid fields instead of SQL containing a made-up column.

For Superset, you would put the returned SQL into a virtual dataset or SQL Lab rather than the chart API.

Its free to use: https://0sql.io/