![\"A](\"/images/content/mcp-dashboard-in-claude.png\")
\n render_view call, one dashboard: KPI tiles, a line chart, a bar chart, and a text summary, rendered inside Claude.We’ve shipped two features requested by early adopters of our open-source MCP Charts package.
\nViews bring BI to your MCP server: you define a dashboard or a single chart once, and the agent renders it by name instead of writing SQL from scratch every time. The package adds two agent tools for this: explore_views lists what’s available, and render_view renders the one the agent picks.
The second feature, embed mode, renders the same charts inside your own web app, not just inside a chat client. Serve the widget from your own route, drop it in an iframe, and it renders chrome-less.
\nA view here is a real, named thing you author: a grid of KPI tiles, chart cells, and text blocks that renders as a dashboard. You write the queries and choose the layout. The agent picks which view to show, not what goes in it.
\nOne addViews call gives your server two tools: one to list what’s published, one to render it by id.
import { addViews, chartCell } from \"@bonnard/mcp-charts\";\nimport { z } from \"zod\";\n\naddViews(server, {\n views: [\n {\n id: \"sales_overview\",\n title: \"Sales overview\",\n kind: \"dashboard\",\n params: { region: z.enum([\"EU\", \"US\", \"APAC\"]).optional() },\n render: ({ region }) => ({\n columns: 2,\n items: [\n { type: \"kpi\", label: \"Revenue\", value: 336800, format: \"currency\" },\n chartCell(monthlyRows(region), { chartType: \"line\", title: \"Revenue by month\", span: 2 }),\n chartCell(regionRows(region), { chartType: \"bar\", title: \"Revenue by region\" }),\n ],\n }),\n },\n ],\n});render_view call, one dashboard: KPI tiles, a line chart, a bar chart, and a text summary, rendered inside Claude.Views take typed parameters, so one dashboard serves every region instead of being rebuilt per filter. Need just one chart from it on its own? Give the cell an id and the agent can call that chart up directly, no extra tool required.
This is the difference between an agent that improvises a chart and an agent that shows your customers a number you already stand behind. The queries, the layout, and the wording are yours. The agent’s job is retrieval.
\nFull detail is in the named views guide and the dashboards reference. examples/dashboard is a runnable six-view server you can point a client at.
Most products that add an MCP server still have a web app, and that web app still needs charts. Embed mode lets one renderer serve both.
\nThe package exports WIDGET_HTML, the same self-contained file the MCP resource serves. Serve it from your own route, point an iframe at it with an #embed fragment, and post it a spec. The widget drops its padding, cell borders, and title, so your card provides the chrome.
import { WIDGET_HTML } from \"@bonnard/mcp-charts\";\n\napp.get(\"/chart-widget\", (_req, res) => res.type(\"html\").send(WIDGET_HTML));<div class=\"my-card\">\n <iframe id=\"rev\" src=\"/chart-widget#embed\" sandbox=\"allow-scripts\"></iframe>\n</div>Wait for the widget’s ready message, post it a ChartSpec, a single dashboard cell, or a whole dashboard with the cell you want addressed by id. It reports back what height it needs when the content has one, which KPI, text, and table cells do and charts do not.
sandbox=\"allow-scripts\" is all the widget needs. It makes no network requests of its own, every payload string is escaped before it reaches the DOM, and it only accepts messages from its own parent window. Theming goes through a small set of validated tokens rather than CSS overrides, so a caller cannot inject a stylesheet into the frame. Charts follow a light or dark theme; the tokens cover the HTML surface around them.
The flags, the message shapes, the token grammar, and the stability contract are in the embed mode guide, with a runnable two-card page in examples/embed.
Bar charts stay vertical unless you ask for horizontal: true. The resolver used to flip any categorical bar chart with more than eight rows, which sent a twelve-month series sideways. Row count was standing in for label width, and it was bad at it.
Text tiles render markdown, so bold, links, lists, and headings in a summary come out formatted instead of as literal syntax. Raw HTML never passes through, which keeps it safe for model-written or user-typed text.
\nTable tiles scroll inside their cell with a sticky header instead of growing the card without limit, and a short cell no longer stretches to match a taller chart beside it.
\nAdd it to an existing MCP server with npm install @bonnard/mcp-charts, then start here. The source is on GitHub. Bonnard never connects to your database: you pass a callback, and we render the rows it returns.
Semantic layers are having a revival. With agents now querying data across businesses, the thinking goes that they need a specific “language” to query it reliably.
\nYour company is openly discussing whether adopting one makes sense. Management are still bruised from the last failed warehouse-querying agent implementation and are looking for a better solution. Someone mentions Cube.dev, another suggests building a custom semantic layer.
\nAs the lead data engineer in your company, you’re thinking practically about the challenges of implementing a semantic layer: another abstraction to be maintained; a second copy of business logic that easily drifts as the data models and metrics evolve; another endpoint that needs to be hosted and monitored; a new framework to learn.
\nBefore committing to anything, there’s another option you should consider: leveraging your database’s native metadata and functions as a lightweight semantic layer.
\nIt’s a surprisingly large lever. In our own agent testing, adding authored descriptions to an opaque schema took an agent’s first-try table-finding from roughly one in four to near-perfect.
\nIf you’re already using dbt, you’re likely most of the way there already, and maintaining a single source of truth is trivial.
\nHere’s how you can achieve this in a few days’ work.
\nInstead of revealing all your marts to agents, curate a helpful set of views (or tables) and columns that meet the specific contexts and use cases you want to provide. This is arguably where the most work will go. Aim for 20-30 views to begin with, then later you can scale up to 50-100 (which agents can easily handle with a good set of tools). Aim to group each view by domain and hide unnecessary internal views.
\nSince you’re building views, you can also bake your metric definitions into them, for example a net_revenue column that already excludes refunds, so the agent uses the correct calculation and inherits your definition instead of re-deriving it.
When using BigQuery/Redshift/Snowflake, declaring primary, foreign and unique keys (even if unenforced) goes a long way later on to help agents build out complex multi-join queries, and spend less time on discovery.
\nUse view comments to help agents discover the right table for their task. A good view comment should help the agent answer:
\nCOMMENT ON VIEW finance.orders IS\n 'One row per customer order (aka sales, purchases). Current orders only,\n excludes cancelled (see finance.orders_all). Joins to finance.customers\n on customer_id. Filter on status; time grain is created_at.';Comment the columns that matter, not every column. A blanket, low-value description on all 60 columns adds noise the agent has to wade through. Depth on the filter, join and date columns beats coverage.
\nKeep these legible, as if one of your business users were using them directly. They should implicitly carry a lot of meaning already:
\nshipping_address over shp_adrsnake_case, as mixed-case identifiers force quoting and will case-fold when unquoted, which leads to a lot of agent errors down the line._id, _at, _date, is_* (for bools), _pct, _ratioamount_cents, weight_kg, duration_secondscustomer_id, account_id etc.-- Hard for an agent to read\nCREATE TABLE ord (\n oid int,\n cust int,\n amt numeric,\n st text,\n dt timestamp\n);\n\n-- Self-describing: the name carries the meaning\nCREATE TABLE orders (\n id bigint,\n customer_id bigint, -- FK -> customers.id\n total_cents integer, -- minor units\n status text,\n created_at timestamptz\n);Column comments help agents use the various columns in the table correctly. Depending on the column type, these should typically provide the agent with:
\nFor categorical columns with a predictable set of values, expose that set so the agent writes the literal verbatim with the right casing. Agents will often guess “Cancelled” vs “cancelled” and return a wrong answer to the user when they get the value wrong. Upfront information about category values also means the agent avoids extra queries to discover the possible values each time.
\n-- Native enum: the allowed values become metadata the agent can read\nCREATE TYPE order_status AS ENUM ('pending', 'paid', 'shipped', 'cancelled');\n\nCREATE TABLE orders (\n id bigint,\n status order_status -- not `text`\n);Native ENUM types exist on Postgres, ClickHouse, DuckDB and MySQL. BigQuery, Redshift and Snowflake have no enum type, so use the fallback ladder there: a CHECK constraint where supported → the allowed values written into the column comment → a lookup/dimension table joined by a foreign key. The lookup table is also the better choice anywhere the value set churns, since a native ENUM is rigid (adding a value is a DDL change) and a lookup row can carry a label and description per value.
CREATE TABLE order_statuses (\n code text PRIMARY KEY, -- 'pending', 'paid', ...\n label text,\n description text\n);Analytical warehouses like Redshift, ClickHouse and BigQuery are columnar engines usually serving denormalized models, built for big scans rather than row-level integrity. ClickHouse in particular has no foreign keys at all, and even on BigQuery and Redshift any keys you declare are unenforced.
\nBut these engines come with their own set of physical keys, chosen for performance, that double as the semantic hints a PK/FK would have given you in Postgres:
\nDISTSTYLE KEY; the default AUTO may pick none)-- ClickHouse: the ORDER BY / PARTITION BY are the grain + cheap filters\nCREATE TABLE events (\n event_date Date,\n user_id UInt64,\n event_type Enum8('view' = 1, 'click' = 2, 'purchase' = 3),\n amount Decimal(10, 2)\n) ENGINE = MergeTree\nPARTITION BY toYYYYMM(event_date) -- time grain + cheapest filter\nORDER BY (user_id, event_date); -- grain + the join/filter columns\n\n-- Redshift: distkey = the join column, sortkey = the cheap range filter\nCREATE TABLE events (\n event_date date,\n user_id bigint,\n amount numeric(10, 2)\n)\nDISTSTYLE KEY DISTKEY (user_id)\nSORTKEY (event_date);Read together, these let an agent infer a table’s grain, the cheapest columns to filter on, and, from the distribution key specifically, a likely join column. Note the split: the distribution key is the join-shaped hint, while the sort and partition keys are grain and cheap-filter hints, not join paths.
\nTwo caveats: they’re heuristics, not guarantees (a distribution key is usually the join key, but not always), so where an engine lets you declare an unenforced PK/FK, do that too; and choose these keys deliberately, since they’re now doing double duty as both a performance decision and documentation an agent reads for free.
\nYour warehouse already computes a lot about your data. Surface it instead of making the agent go and find out.
\nAt the column level, Postgres’ pg_stats and DuckDB’s SUMMARIZE unlock helpful statistics e.g. n_distinct, most_common_vals, histogram_bounds, min/max, null %. These let an agent interpret a column before it queries: the real range of a date column before it writes a BETWEEN, or whether a status column is skewed 95% to one value. (Availability varies: Snowflake and BigQuery expose no user-readable column-stats view, so lean on comments and enums there.)
SUMMARIZE orders;\n-- column_name | min | max | approx_unique | null_percentage | ... (per column)At the table level, row counts and byte size tell the agent what volume it is working with so it can adjust its SQL accordingly. This also serves as fact-vs-dimension routing, so an agent can tell a 50M-row fact table from a 12-row lookup and pick the right driving table in a join.
\nA word of caution in multi-tenant setups: on a table with row-level security, Postgres hides pg_stats from a non-privileged reader (you get nothing), while the row counts here (reltuples, n_live_tup) are RLS-blind and report the whole-table volume regardless of policy. Treat both carefully when tenants share a table.
This gets you discovery and legibility, not a full metrics platform. The main thing you give up versus a dedicated tool like Cube is caching and pre-aggregation: an agent that fans out into dozens of follow-up questions hits your warehouse, and your bill, each time. If controlling cost at high query volume is a hard requirement, that’s where a semantic-layer product still earns its place.
\nOne last thing to keep in mind if your agents are external or per-tenant: metadata itself can leak. Table names, comments and RLS-blind row counts are readable through the catalog, so findable is not the same as safe to expose. Scope what each agent’s role can read.
\nBy applying some or all of the above tips depending on your current warehouse setup, you can create a remarkably effective foundation for agent queries without adopting a completely new tool or framework.
\nHowever, this isn’t all there is to it. Agents will also need the right tools to explore and query your new semantic layer effectively.
\nOur next article will cover what a good agent toolset looks like, whether you are handrolling your own agents or creating a data MCP for your users.
\n", "date_published": "2026-07-16T00:00:00.000Z", "date_modified": "2026-07-16T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/mcp-charts", "url": "https://bonnard.dev/blog/mcp-charts", "title": "MCP Charts: Add Interactive Charts to Your MCP Server", "summary": "Give your AI agent a visualize tool: interactive charts inside any MCP Apps client from real query data. Works with any MCP server via @bonnard/mcp-charts.", "content_html": "Your MCP server returns data. The agent reads it back as a wall of numbers, or it tries to draw a chart in HTML and gets it wrong. The visual, the part the user actually wanted, gets left to the model to improvise.
\nMCP charts fix that. You give your MCP server one visualize tool: the agent calls it with a query, your database returns the rows, and an interactive chart renders right in Claude or ChatGPT. You write no frontend code. That is what @bonnard/mcp-charts does, handling the tool, the chart, the cross-host widget, and the theming.
import { McpServer } from \"@modelcontextprotocol/sdk/server/mcp.js\";\nimport { addCharts } from \"@bonnard/mcp-charts\";\nimport { postgresRunSql } from \"@bonnard/mcp-charts/postgres\";\n\nconst server = new McpServer({ name: \"acme\", version: \"1.0.0\" });\n\naddCharts(server, {\n runSql: postgresRunSql(pool), // maps pg column types to chart field kinds\n});A chart in an MCP client is not an image. It is an interactive widget the host renders from a spec the tool returns.
\nvisualize with a query (SQL, a semantic query, or chart params).runSql callback runs it against your warehouse or ORM and returns rows.ui:// widget.You connect the data. Bonnard never sees your database, only the rows your callback returns. Native adapters ship for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.
@bonnard/mcp-charts renders line, bar, area, pie, scatter, funnel, waterfall, and table, with bar variants for stacked, grouped, horizontal, and 100% stacked. Set chartType or let the resolver pick from the shape of the data: a time dimension and a measure becomes a line; a category and a measure becomes a bar.
Without one, an agent that is asked for “revenue by region as a chart” has two bad options. It dumps a wall of numbers, or it generates HTML and hopes the host renders it. Both put the most important part of the answer, the visual, in the model’s hands to improvise.
\nA dedicated tool fixes that:
\nThe common pattern is two tools: one for the agent to learn your schema, one to chart the result.
\n// the agent discovers tables, writes SQL, then charts the rows\nserver.registerTool(\"explore_schema\", { /* list tables + columns */ }, listSchema);\naddCharts(server, { runSql });Point any MCP client at the server. Ask “chart monthly revenue by plan.” The agent writes the query, runs it through your callback, and the bar chart appears in the chat.
\nMost MCP chart servers take chart parameters from the agent and render a generic image. Bonnard takes your query result and infers the chart, so the visual is grounded in real data, not in parameters the model made up.
\n| Server | \nInput | \nOutput | \nGrounded in your data | \nAgent experience | \n
|---|---|---|---|---|
AntV mcp-server-chart | \nchart params | \nstatic image | \nNo | \nBasic | \n
| Highcharts MCP | \nchart params | \nstatic image | \nNo | \nBasic | \n
| Mermaid Chart MCP | \ndiagram spec | \ndiagram | \nNo | \nBasic | \n
@bonnard/mcp-charts | \nyour query result | \ninteractive widget | \nYes | \nSummaries, row caps, instructive errors | \n
Install @bonnard/mcp-charts, call addCharts(server, { runSql }), and pass a callback that runs SQL against your data. That registers a visualize tool. The agent calls it; the chart renders in the client. No UI code.
If your MCP server returns data an agent will summarize, yes. A chart in the conversation is faster to read than a table, and a dedicated tool keeps the visual deterministic instead of letting the model draw HTML it might get wrong.
\nHosts that support MCP apps render the interactive widget: Claude, ChatGPT, Cursor, and GitHub/Microsoft 365 Copilot today, with more clients adding support.
\nPick on where the chart comes from. If you want the agent to pass chart specs, a generic server like AntV works. If you want charts grounded in your own query results, with no frontend code and agent-tuned behavior, that is what @bonnard/mcp-charts is built for.
No. You provide the runSql callback. Bonnard renders the rows it returns and never connects to your database.
Add it to your server in a few lines: @bonnard/mcp-charts. For the design behind an agent-friendly chart tool, see How Bonnard Builds Agent-Friendly MCPs.
Exposing your data over MCP is the easy part. Designing a tool an agent uses well is the hard part. An agent can only use a tool it can read, so the work is shaping the tool for how the model calls it, not just for the human looking at the result. These are the techniques behind @bonnard/mcp-charts and the visualize tool.
An agent that guesses your schema writes wrong queries. So the first tool the agent meets is a discovery tool. addCharts takes a discovery: { toolName } option naming your own schema tool, and visualize then opens its description by telling the agent to call that tool first and learn your tables and columns before it writes SQL. The chart options travel in visualize’s input schema, each field described where the agent reads it. The agent reads, then acts.
The temptation is one tool per metric, or a single tool that takes arbitrary SQL and hopes. Both fail: too many tools blow the agent’s attention budget; one firehose tool gives it no guardrails. Bonnard ships a small set, discover, query, visualize, each with a narrow, obvious job. The agent picks the right one because there are few of them and each does one thing.
\n// a small, purpose-built set, not one tool per metric\nserver.registerTool(\"explore_schema\", { /* list tables + columns */ }, listSchema);\naddCharts(server, { runSql, discovery: { toolName: \"explore_schema\" } }); // registers visualizeA tool that returns 10,000 raw rows poisons the context window and the agent’s next decision. Bonnard’s responses are sized for a model to read:
\npartial or complete, so the agent knows whether it is looking at everything.A bare “error: invalid column” stalls an agent. Bonnard’s errors carry a fix. A bad field name returns a hint to check names with explore_schema; a SQL error returns targeted guidance; successful calls include a next_step pointing at the right follow-up tool. The agent self-corrects instead of looping.
The most important move is pushing deterministic work out of the model and into the code. The agent picks what to show (a chart type, a query). Bonnard decides how: it infers axes from the typed result, auto-detects currency and percentage formatting, fills missing time buckets, and labels null dimensions. The smaller the agent’s decision surface, the less there is to hallucinate.
\nTo an agent, the tool description is the documentation. Bonnard’s tools use a typed schema with a description on every field, plus a read-me tool that returns usage examples on demand. The agent knows how and when to call visualize because the schema tells it, not because you wrote a prompt.
It is shaped for how a model calls tools: discovery-first so the agent learns before it acts, a small set of narrow tools, compact responses with completeness flags, errors that suggest the fix, and a typed, self-describing schema. The agent uses it correctly without hand-holding.
\nText-to-SQL against raw tables is wrong often enough that you cannot put it in front of a customer, and an agent drawing its own chart HTML is non-deterministic. A governed query path plus a dedicated chart tool returns consistent, trustworthy visuals.
\nYes, as a narrow, audited path, not a bypass around governance. You control what runs via your runSql callback.
See the product this is built on: MCP Charts.
\n", "date_published": "2026-06-16T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/ai-data-analysis", "url": "https://bonnard.dev/blog/ai-data-analysis", "title": "AI Data Analysis: Why Governed Metrics Beat Raw SQL", "summary": "A guide to AI data analysis for SaaS: the tool categories, the accuracy problem, and the MCP-native way to chart query results inside an agent.", "content_html": "AI data analysis tools are everywhere. Upload a spreadsheet to Julius AI and get a chart. Ask ChatGPT’s Data Analyst to find trends. Connect Databricks AI/BI to your warehouse and let it generate queries. The pitch: anyone can analyze data without writing SQL.
\nThe pitch works for one-off exploration. It breaks when you need trustworthy numbers at scale: consistent results across tools, governed access per customer, and an audit trail for every answer. That’s where most AI analytics tools stop and where a semantic layer starts.
\nAI data analysis uses large language models and machine learning to automate parts of the data analysis workflow: generating queries, identifying patterns, creating visualizations, and summarizing findings in natural language. Instead of writing SQL by hand, you describe what you want and the AI produces it.
\nThe tools fall into three categories:
\nSpreadsheet AI. Upload a CSV and ask questions. Julius AI, Formula Bot, ChatGPT Data Analyst. Good for ad-hoc exploration of small datasets. No governance, no multi-tenancy, no audit trail. Your data leaves your infrastructure.
\nBI tool AI. Built into an existing BI platform. Tableau’s AI analytics, Power BI Copilot, Domo AI, ThoughtSpot’s natural language search. Better than spreadsheet tools because they query your warehouse. Still limited by the BI tool’s ecosystem and licensing model.
\nText-to-SQL agents. An LLM generates SQL against your warehouse schema. DataGPT, custom GPT agents, Databricks AI/BI. Most flexible, most dangerous. The agent writes arbitrary SQL. No guardrails on what it queries or how it calculates metrics.
\nAll three share the same fundamental problem: the AI interprets your data on every query. There’s no shared definition of what “revenue” means. Different tools, different phrasings, different numbers.
\nAI data analysis demos are impressive. The tool generates a chart from a natural language question in seconds. But run the same question through two different tools and compare the numbers. They don’t match.
\nWhy? Because each tool independently interprets your schema. “Revenue” might be SUM(amount) in one tool and SUM(total_price) WHERE status = 'completed' in another. Both are plausible. Neither knows that your finance team excludes refunds and trial conversions.
This isn’t a model quality issue. GPT-4, Claude, and Gemini all exhibit this behavior. The model does what it’s designed to do: generate plausible SQL from schema context. But “plausible” and “correct” are different things.
\nThe accuracy problem compounds at scale:
\nText-to-SQL gives you speed. It doesn’t give you trust. For production analytics, you need both.
\nThe gap between a demo and a production system is five things. Most AI data analysis tools have one or two. None of the spreadsheet or text-to-SQL tools have all five.
\nEvery metric has one definition. “Revenue” is SUM(amount) WHERE status != 'refunded' AND type != 'trial'. This definition is fixed, versioned in Git, and referenced by every consumer. The AI doesn’t interpret what revenue means. It queries the governed definition.
cubes:\n - name: orders\n sql_table: public.orders\n measures:\n - name: total_revenue\n sql: \"CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END\"\n type: sum\n description: \"Total revenue excluding refunds and trials\"\n - name: order_count\n type: count\n - name: average_order_value\n sql: amount\n type: avg\n dimensions:\n - name: status\n sql: status\n type: string\n - name: category\n sql: category\n type: string\n - name: created_at\n sql: created_at\n type: timeThis is a semantic layer: a metadata layer between your warehouse and every consumer. The AI agent calls explore_schema to discover available metrics, then query to fetch governed data. It never generates SQL from scratch.
The same metric definition serves dashboards, React components in your product, REST APIs, AI agents, and markdown reports. Ask for “revenue” from any surface and you get the same number. Not because the AI happened to generate the same SQL, but because the definition is fixed.
\nThis matters for AI specifically because AI tools generate different SQL on every call. Even the same tool, same question, different session can produce different queries. Governed definitions eliminate this variance.
\nFor B2B products, Customer A’s AI agent should never see Customer B’s data. This can’t be a prompt instruction (“only query data for customer A”). It needs to be structural: enforced on every query regardless of what the AI does.
\n security_context:\n - name: tenant_filter\n sql: \"{SECURITY_CONTEXT.tenant_id} = customer_id\"Every query through a tenant’s key automatically includes this filter. The AI agent can’t bypass it. See RBAC for more on how this works.
\nAI agents make more queries than humans. A human asks one question. An agent might make 10 queries to answer it: exploring the schema, trying different dimensions, following up on anomalies. Multiply by hundreds of customers’ agents querying simultaneously.
\nPre-aggregation caching pre-computes common rollups. Hot queries return in single-digit milliseconds. Without it, AI-scale query volumes overwhelm most warehouses.
\nWhen the number is wrong, you need to trace it. With a semantic layer, every result traces back to a versioned metric definition in Git. You can point to the exact commit that defined the calculation, see when it changed, and who approved the change. With raw text-to-SQL, the trail is “an LLM generated some SQL” with no reproducibility.
\n| Tool | \nApproach | \nGoverned metrics | \nMulti-tenant | \nAudit trail | \nBest for | \n
|---|---|---|---|---|---|
| Julius AI | \nSpreadsheet upload + LLM | \nNo | \nNo | \nNo | \nAd-hoc exploration of CSVs | \n
| ChatGPT Data Analyst | \nFile upload + code interpreter | \nNo | \nNo | \nNo | \nOne-off analysis, prototyping | \n
| Databricks AI/BI | \nText-to-SQL + Unity Catalog | \nPartial (table-level) | \nPartial | \nPartial | \nTeams already on Databricks | \n
| Power BI Copilot | \nNatural language in Power BI | \nDAX measures (locked to PBI) | \nComplex setup | \nWithin PBI | \nMicrosoft ecosystem | \n
| Tableau AI | \nNatural language in Tableau | \nTableau semantic model | \nEnterprise | \nWithin Tableau | \nSalesforce ecosystem | \n
| ThoughtSpot | \nNatural language BI | \nProprietary semantic layer | \nEnterprise | \nYes | \nEnterprise AI-powered BI | \n
| DataGPT | \nConversational analytics agent | \nNo | \nNo | \nNo | \nAutonomous data analysis | \n
| Domo AI | \nBI platform with AI features | \nWithin Domo | \nWithin Domo | \nWithin Domo | \nEnd-to-end data platform | \n
| Charts in agent (Bonnard) | \nvisualize tool on your MCP server | \nN/A (your runSql) | \nN/A (your DB) | \nN/A | \nInteractive charts inside Claude or ChatGPT | \n
The tools in the top half are AI-first but governance-second. The ones in the middle (enterprise BI) have governance but lock it to their ecosystem. The bottom row is a different kind of option: @bonnard/mcp-charts does not generate SQL or define metrics. It renders interactive charts from the rows your runSql returns, inside the agent.
Use spreadsheet AI (Julius, ChatGPT) when:
\nUse BI tool AI (Power BI Copilot, Tableau AI) when:
\nUse a semantic layer when:
\nGoverning the numbers is one half of AI data analysis. The other half is what the customer actually sees. When someone asks a question in Claude or ChatGPT, they often want a chart, not a table of rows. That’s a separate surface from the governance layer, and it’s where @bonnard/mcp-charts fits.
@bonnard/mcp-charts is not a semantic layer, a BI tool, or a text-to-SQL agent. It is a visualize tool you add to your MCP server that renders interactive charts from your query results, inside the agent.
import { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, {\n runSql: async (sql) => db.query(sql),\n});addCharts registers a visualize tool. The flow:
visualize with a query.runSql returns rows.ui:// widget in Claude or ChatGPT.Chart types: line, bar, area, pie, scatter, funnel, waterfall, and table. Axes, formatting, and gap-fill are determined automatically, so the same typed result produces the same chart. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql. Bonnard never touches your database.
The tool is built for the agent: compact summaries, row caps with completeness flags, a typed schema, and instructive errors with a next_step. For the design principles, see how Bonnard builds agent-friendly MCPs.
The first generation of AI analytics gave agents raw warehouse access and hoped for the best. It worked in demos. It failed in production because the agent interprets business logic on every query.
\nThe next generation separates the concerns. Data teams define governed metrics in a semantic layer. AI agents query those definitions instead of raw tables. The data team’s expertise is encoded in the schema. The AI’s role shifts from “guess what revenue means” to “pick the right governed metric and present the result.”
\nThis is a better division of labor. The data team defines what’s true. The AI handles the interface. Trustworthy numbers with a natural language frontend.
\nIf you want charts rendered inside an AI agent from your own query results, install the package and register the tool on your MCP server:
\nnpm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, {\n runSql: async (sql) => db.query(sql),\n});That registers the visualize tool. Connect your server in Claude or ChatGPT, and the agent can render charts from your query results. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.
Repo: github.com/bonnard-data/mcp-charts. Full walkthrough: MCP charts. For background: What Is a Semantic Layer?.
\nAI data analysis uses large language models and machine learning to automate data querying, pattern detection, and insight generation. Instead of writing SQL manually, you ask questions in natural language and the AI produces queries, charts, and summaries. Tools range from spreadsheet analyzers (Julius AI) to enterprise BI platforms with AI features (Power BI Copilot, Tableau AI).
\nFor ad-hoc exploration, accuracy is “good enough.” For production analytics where customers see the numbers, accuracy varies per query because the AI generates SQL from scratch each time. Two tools generating SQL for “revenue” may produce different numbers because they interpret the calculation differently. A semantic layer solves this by defining each metric once and letting AI query the definition instead of generating its own.
\nIt depends on the use case. For one-off CSV exploration: Julius AI or ChatGPT Data Analyst. For enterprise BI: Power BI Copilot or Tableau AI. For governed metrics served to AI agents and B2B customers: a semantic layer approach. See the comparison table above.
\nFor a SaaS product, two things matter: trustworthy numbers and where the customer sees the result. Govern the numbers with a semantic layer so the AI queries fixed definitions instead of guessing. Then decide the surface. If your customers work in Claude or ChatGPT, @bonnard/mcp-charts adds a visualize tool to your MCP server that renders interactive charts from your query results, inside the agent. Your runSql runs the query, so Bonnard never touches your database. Install with npm install @bonnard/mcp-charts.
Traditional BI requires analysts to write queries and build dashboards. AI analytics automates the query generation. The risk: AI-generated queries are inconsistent. Traditional BI with a semantic layer gives you consistent definitions. AI analytics with a semantic layer gives you both: consistent definitions with a natural language interface.
\nNo. AI can generate queries and create visualizations faster than humans. It can’t define what metrics should mean, decide which questions to ask, or judge whether an insight is actionable. Data analysts bring domain knowledge and judgment. AI handles the mechanical parts. A semantic layer encodes the analyst’s expertise so AI can query it reliably.
\nText-to-SQL is a technique where an LLM generates SQL from natural language. AI analytics is broader: it includes text-to-SQL plus pattern detection, anomaly identification, forecasting, and visualization generation. Both share the same governance gap: the AI interprets your data on every query. A semantic layer addresses this for both.
\nMost AI analytics tools work with common warehouses: Snowflake, BigQuery, Databricks, PostgreSQL (including Supabase, Neon, and RDS), Redshift, and DuckDB (including MotherDuck). The semantic layer generates the appropriate SQL dialect for each warehouse.
\n", "date_published": "2026-03-19T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/ai-reporting", "url": "https://bonnard.dev/blog/ai-reporting", "title": "AI Reporting: How to Automate Reports Without Losing Trust", "summary": "A guide to AI reporting for SaaS: the tool landscape, the trust problem, and the MCP-native way to render charts from your query results inside an agent.", "content_html": "Your data team spends 40% of their time building reports. Weekly revenue summaries. Monthly board decks. Quarterly business reviews. Customer-facing usage reports. Each one requires pulling data, checking the numbers match last month’s methodology, formatting it, and sending it out.
\nAI reporting tools promise to automate this. Ask for a report in natural language and get charts, tables, and summaries in seconds. The problem: the AI generates the queries from scratch each time. This month’s revenue calculation might differ from last month’s. The board deck numbers might not match the customer report. Automation without governance creates reports nobody trusts.
\nAI reporting uses large language models to automate parts of the reporting workflow: querying data, generating visualizations, writing narrative summaries, and scheduling delivery. Instead of an analyst manually pulling numbers and building slides, the AI handles the mechanical work.
\nThe tools range from simple (ChatGPT generating a summary from a CSV) to sophisticated (enterprise BI platforms with AI-powered report builders). What they share: the AI interprets your data on every run. There’s no guarantee that “revenue” means the same thing in this week’s report as it did last week.
\nThe AI generates SQL from your schema context. This week it calculates revenue as SUM(amount). Next week, with slightly different prompt context, it adds a WHERE status = 'completed' filter. The CEO compares the two reports and asks why revenue dropped 8%. It didn’t drop. The calculation changed. Nobody noticed because the SQL is generated on the fly.
When the CFO asks “where did this number come from?”, the answer should be a versioned metric definition, not “an LLM wrote some SQL.” Automated reports need the same auditability as manual ones. If you can’t reproduce a number from a specific report, the report is useless for compliance, board materials, or customer-facing delivery.
\nThe weekly ops report, the monthly board deck, and the quarterly customer report all show “revenue.” Without a shared definition, each report calculates it independently. The numbers diverge. Stakeholders compare reports and lose confidence. The data team gets pulled into reconciliation instead of building.
\nThe fix isn’t avoiding AI. It’s separating what AI is good at (generating natural language summaries, choosing visualizations, scheduling delivery) from what it’s bad at (defining business metrics).
\ncubes:\n - name: revenue_metrics\n sql_table: analytics.monthly_revenue\n measures:\n - name: total_revenue\n sql: \"CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END\"\n type: sum\n description: \"Finance-approved revenue (excludes refunds and trials)\"\n - name: mrr\n sql: monthly_amount\n type: sum\n description: \"Monthly recurring revenue from active subscriptions\"\n - name: net_revenue_retention\n sql: \"current_mrr / previous_mrr\"\n type: avg\n description: \"NRR: current period MRR / prior period MRR for the same cohort\"\n dimensions:\n - name: plan\n sql: plan_name\n type: string\n - name: region\n sql: region\n type: string\n - name: period\n sql: period_date\n type: timeEvery report, whether generated by AI or built manually, references these definitions. The methodology is fixed. This month’s “revenue” uses the same calculation as last month’s.
\nThe AI’s job shifts from “calculate revenue” to “present the governed revenue number.” It queries the semantic layer, gets a trustworthy number, and wraps it in a narrative: “Revenue grew 12% QoQ, driven primarily by Enterprise plan expansion in EMEA.”
\nThis is a better division of labor. The data team defines what’s true. The AI makes it readable.
\nWhen the report lives inside an AI agent, the customer often wants a chart in the conversation, not only a narrative. That’s a separate surface from the governance layer, and it’s where @bonnard/mcp-charts fits.
@bonnard/mcp-charts is not a reporting tool or a BI platform. It is a visualize tool you add to your MCP server that renders interactive charts from your query results, inside the agent.
import { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, {\n runSql: async (sql) => db.query(sql),\n});addCharts registers a visualize tool. The agent calls visualize, your runSql returns rows, Bonnard infers the chart from the typed result, and it renders an interactive ui:// widget in Claude or ChatGPT. Chart types: line, bar, area, pie, scatter, funnel, waterfall, and table. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql. Bonnard never touches your database.
Axes, formatting, and gap-fill are determined automatically, so the same typed result produces the same chart every run. The tool returns compact summaries, row caps with completeness flags, and instructive errors with a next_step, so the agent can reason about the result. For the design principles, see how Bonnard builds agent-friendly MCPs.
AI report generators automate the mechanical parts of building reports. Here’s what exists and where each approach fits.
\nGeneral-purpose LLMs as report generators. Upload a CSV to ChatGPT or Claude and ask for an analysis. Good for one-off reports. No governance, no scheduling, no multi-tenancy. The report is as good as the prompt. Ask the same question next month and you might get a different methodology.
\nDedicated AI reporting tools. Narrative BI, Rath, and similar tools generate automated dashboards and written insights from your data. They connect to your warehouse and produce reports on a schedule. The limitation: they define metrics at report generation time, not in a governed layer. Different reports can calculate the same metric differently.
\nBI tools with AI features. Power BI Copilot, Tableau AI, Domo AI. The AI helps you build reports inside the BI tool. Better than general-purpose LLMs because the data stays in your warehouse. Limited to whatever the BI tool supports.
\nSemantic layer + AI. Define metrics once in a governed layer. Use AI to generate narrative summaries, choose visualizations, and schedule delivery. The AI handles presentation. The semantic layer handles correctness. This is the approach that produces trustworthy automated reports.
\n| Tool | \nApproach | \nGoverned metrics | \nMulti-tenant reports | \nAudit trail | \n
|---|---|---|---|---|
| ChatGPT / Claude | \nUpload data, ask for analysis | \nNo | \nNo | \nNo | \n
| Power BI Copilot | \nAI in Power BI | \nDAX measures (PBI only) | \nComplex | \nWithin PBI | \n
| Tableau AI | \nAI in Tableau | \nTableau model only | \nEnterprise | \nWithin Tableau | \n
| Domo AI | \nAI in Domo platform | \nWithin Domo | \nWithin Domo | \nWithin Domo | \n
| Automated BI tools (Narrative BI, Rath) | \nAI-generated dashboards | \nNo | \nNo | \nNo | \n
| Charts in agent (Bonnard) | \nvisualize tool on your MCP server | \nN/A (your runSql) | \nN/A (your DB) | \nN/A | \n
Use AI reporting with a semantic layer when:
\nUse raw AI reporting tools when:
\nIf you want charts rendered inside an AI agent from your own query results, install the package and register the tool on your MCP server:
\nnpm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, {\n runSql: async (sql) => db.query(sql),\n});That registers the visualize tool. Connect your server in Claude or ChatGPT, and the agent can render charts from your query results. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.
Repo: github.com/bonnard-data/mcp-charts. Full walkthrough: MCP charts. For background: What Is a Semantic Layer?.
\nAI reporting uses large language models to automate report generation: querying data, creating visualizations, writing summaries, and scheduling delivery. The AI handles the mechanical work that analysts currently do manually. The risk: without governed metric definitions, the AI generates different calculations on each run.
\nNo. AI can automate the mechanical parts (pulling data, formatting charts, writing summaries). It can’t define what metrics should mean, decide which numbers matter for a specific audience, or judge whether an insight is actionable. The best approach: data teams define governed metrics, AI automates the delivery.
\nAutomated reporting is any system that generates reports without manual intervention. This includes scheduled dashboard refreshes, programmatic report generation via API, and AI-generated narrative summaries. The key question isn’t whether to automate, but whether the automated reports use governed metric definitions.
\nSeparate metric definition from report generation. Define each metric once in a semantic layer with a fixed calculation. Let the AI query those definitions instead of generating SQL. Every report references the same versioned definitions. When someone questions a number, you point to a Git commit, not “the AI decided.”
\nGovern the numbers first so methodology stays fixed across runs. Then pick the surface where the report lands. If your customers read reports inside Claude or ChatGPT and want a chart in the conversation, @bonnard/mcp-charts adds a visualize tool to your MCP server that renders interactive charts from your query results. Your runSql runs the query, so Bonnard never touches your database. Install with npm install @bonnard/mcp-charts. Repo: github.com/bonnard-data/mcp-charts.
You have metrics. Revenue, active users, churn, usage per customer. They live in your data warehouse. Now you need to serve them to multiple consumers: your product’s frontend, your customers’ integrations, an AI agent, a scheduled report generator.
\nThe first instinct is custom API endpoints. One endpoint for revenue by region. Another for churn by plan. Another for the customer dashboard. Each endpoint has its own SQL query, its own response format, its own maintenance burden. By the twentieth endpoint, you’re running a bespoke analytics service.
\nAn analytics API backed by a semantic layer gives you one query interface that serves every consumer. Define metrics once. Query them from anywhere.
\nAn analytics API is a programmatic interface for querying metrics. Instead of connecting to a database and writing SQL, consumers call an API endpoint with the metrics they want and get structured results back.
\ncurl https://analytics.example.com/v1/query \\\n -H \"Authorization: Bearer bon_pk_...\" \\\n -d '{\n \"measures\": [\"orders.total_revenue\", \"orders.order_count\"],\n \"dimensions\": [\"orders.region\"],\n \"timeDimensions\": [{\n \"dimension\": \"orders.created_at\",\n \"granularity\": \"month\",\n \"dateRange\": [\"2026-01-01\", \"2026-03-31\"]\n }],\n \"orderBy\": { \"orders.total_revenue\": \"desc\" }\n }'The response is structured JSON:
\n{\n \"data\": [\n { \"orders.region\": \"EMEA\", \"orders.total_revenue\": 142000, \"orders.order_count\": 340, \"orders.created_at\": \"2026-01-01\" },\n { \"orders.region\": \"APAC\", \"orders.total_revenue\": 98000, \"orders.order_count\": 220, \"orders.created_at\": \"2026-01-01\" }\n ]\n}Every consumer uses the same interface. The dashboard frontend, the customer’s API integration, the scheduled report, and the AI agent all query the same endpoint with the same metric definitions. The analytics API handles query generation, execution, caching, and access control.
\nCustom endpoints work at small scale. They break at medium scale:
\nMetric drift. /api/revenue and /api/dashboard/revenue both return “revenue” but use different SQL queries. One gets updated. The other doesn’t.
N+1 endpoint problem. Every new metric or dimension combination is a new endpoint. Revenue by region. Revenue by plan. Revenue by region AND plan. Revenue by region AND plan AND month. The combinatorial explosion is real.
\nNo caching strategy. Each endpoint hits the warehouse on every request. Response times grow with data volume. You end up building a caching layer per endpoint.
\nNo access control. Each endpoint implements its own auth. Customer A’s key works on all endpoints or none. Per-tenant, per-metric access control is custom code.
\nA shared query interface handles all of this. But there’s a gap that shows up once AI agents become consumers: an agent that fetches rows still has to present them. A wall of JSON tells the user nothing. Agents need to chart query results, not just fetch them.
\nFetching rows is half the job. The other half is rendering them so a person can read the answer. That’s where @bonnard/mcp-charts fits: a visualize tool you add to your MCP server that renders interactive charts from your query results.
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\n// runSql runs against your warehouse and returns typed rows\naddCharts(server, { runSql });addCharts registers a visualize tool on your server. Bonnard never touches your database. Your runSql does, against Postgres, BigQuery, Snowflake, Databricks, DuckDB, or any source you wire up.
visualize with a query.runSql returns rows.ui:// widget inside Claude or ChatGPT.The agent gets line, bar, and area charts for trends, scatter for distributions, funnel and waterfall for staged data, pie for shares, and a table when a table is the right answer. Axes, formatting, and gap-fill are decided from the typed schema, so the same query produces the same chart every time.
\nOne query interface for the numbers. One visualize tool for the picture.
| Approach | \nMetric governance | \nMulti-tenant | \nCaching | \nMaintenance | \n
|---|---|---|---|---|
| Custom REST endpoints | \nNone (per-endpoint SQL) | \nDIY | \nDIY | \nHigh (per endpoint) | \n
| GraphQL API | \nSchema-level | \nDIY | \nPer-resolver | \nMedium-high | \n
| Direct warehouse access | \nNone | \nManual | \nNone | \nLow (but dangerous) | \n
| BI tool API (Looker, Metabase) | \nTool-specific | \nTool-specific | \nTool-specific | \nMedium | \n
| Bonnard | \nInherits your runSql definitions | \nInherits your runSql | \nInherits your warehouse | \nLow (a few lines on your server). Adds interactive charts via the MCP visualize tool, rendered in Claude/ChatGPT from query results | \n
You need one when:
\nYou don’t need one when:
\nOnce your analytics API can fetch rows, add a visualize tool so agents can chart them:
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, { runSql });That registers the visualize tool on your MCP server. Agents call it with a query, your runSql returns rows, and Bonnard renders an interactive chart inside Claude or ChatGPT. Adapters ship for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.
For the full walkthrough: Add Interactive Charts to Your MCP Server. For the design choices behind the tool: How Bonnard Builds Agent-Friendly MCPs.
\nSource is on GitHub.
\nAn analytics API is a programmatic interface for querying business metrics. Instead of writing SQL against a database, consumers call an API with the measures, dimensions, and filters they want. The API handles query generation, caching, and access control.
\nA generic REST API exposes resources (users, orders, invoices). An analytics API exposes metrics (revenue, churn rate, active users) with aggregation, filtering, and time dimensions built in. The query interface is designed for analytical questions, not CRUD operations.
\nIf AI agents query your data, an analytics API is the governed path. The alternative is giving agents direct database access (dangerous) or text-to-SQL (inconsistent). An analytics API backed by a semantic layer gives agents governed access to metric definitions. See What Is an Agentic Semantic Layer?.
\nGraphQL works for analytics APIs but you end up building the aggregation, caching, and access control layer yourself. A semantic layer provides these out of the box with a purpose-built query interface for analytical workloads.
\n", "date_published": "2026-03-19T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/best-embedded-analytics-tools", "url": "https://bonnard.dev/blog/best-embedded-analytics-tools", "title": "Best Embedded Analytics Tools for SaaS in 2026", "summary": "Comparing the best embedded analytics tools for B2B SaaS in 2026: Metabase, Explo, Luzmo, GoodData, Looker, and the MCP-native option for AI agents.", "content_html": "If you’re building a B2B SaaS product and need to ship analytics to your customers, you’re evaluating embedded analytics tools. The market has more options than it needs. This guide cuts through the noise.
\nWe compare 10 tools across the dimensions that matter for B2B: multi-tenancy, customization, AI agent support, pricing model, and how many surfaces each tool serves beyond dashboards.
\nBefore comparing tools, know what matters for your use case:
\nMulti-tenancy. Every customer sees only their data. This needs to be structural (enforced at the query layer), not bolted on (middleware filters that might miss an edge case). One data leak and your customers’ trust is gone.
\nCustomization. The analytics should look like part of your product. Iframe embedding limits this. Native SDK components give you full control over styling.
\nMetric governance. Every chart should show the same number as your API. If the dashboard says $45K and the API returns $43K, your customer notices.
\nPerformance. Dashboards that take 8 seconds to load don’t get used. Caching matters.
\nPricing model. Per-user pricing kills B2B use cases. If you have 1,000 customers each with 10 users, per-seat licensing makes embedded analytics unaffordable.
\nAI agent support. Increasingly, customers want to connect AI tools to their data. None of the traditional embedded analytics tools support this. It’s a differentiator.
\n| Tool | \nType | \nMulti-tenancy | \nAI/Agent | \nPricing | \nOpen source | \n
|---|---|---|---|---|---|
| Metabase | \nBI tool with embedding | \nEnterprise only ($500+/mo) | \nNo | \nFree OSS / $500+ Pro | \nYes (AGPL) | \n
| Holistics | \nEmbedded BI platform | \nBuilt-in | \nNo | \nPer-user | \nNo | \n
| Explo | \nEmbedded analytics SDK | \nBuilt-in | \nNo | \nUsage-based | \nNo | \n
| Luzmo | \nEmbedded analytics SDK | \nBuilt-in | \nLimited | \nUsage-based | \nNo | \n
| Reveal | \nEmbedded analytics SDK | \nBuilt-in | \nNo | \nPer-app | \nNo | \n
| GoodData | \nEnterprise embedded BI | \nBuilt-in | \nLimited | \nUsage-based | \nPartial | \n
| Looker | \nEnterprise BI with embedding | \nEnterprise | \nNo | \nEnterprise pricing | \nNo | \n
| Power BI Embedded | \nEnterprise BI with embedding | \nComplex setup | \nCopilot (internal) | \nCapacity-based | \nNo | \n
| Tableau Embedded | \nEnterprise BI with embedding | \nEnterprise | \nLimited | \nPer-user + Server | \nNo | \n
| Bonnard | \nCharts for AI agents via MCP (not embedded BI) | \nN/A (your runSql, your DB) | \nNative (visualize tool) | \nOpen source (npm) | \nYes | \n
The most popular open-source BI tool. Great for internal dashboards. Embedding requires Pro ($500+/mo) for static embeds or Enterprise for interactive. Multi-tenancy (sandboxing) is Enterprise only. No semantic layer, no AI agent support.
\nBest for: Internal dashboards, MVPs, teams that want free self-hosted BI.\nNot great for: Customer-facing B2B analytics at scale. Multi-tenancy and embedding costs add up.
\nSelf-service embedded BI aimed at product teams. Built-in multi-tenancy with row-level security. Strong data modeling layer. Drag-and-drop dashboard builder with embedding.
\nBest for: Teams that want a managed embedded BI platform with a modeling layer.\nNot great for: AI agent use cases, custom React components, or teams that want open-source infrastructure.
\nSDK-first embedded analytics. React and JavaScript components for building dashboards in your product. Built-in multi-tenancy. Good API for programmatic control.
\nBest for: Product teams that want prebuilt dashboard components with customization.\nNot great for: Teams that need governed metrics across multiple surfaces beyond dashboards. No semantic layer, no AI agent support.
\nEmbedded analytics with a focus on developer experience. SDK components, API access, and a dashboard builder. Some AI capabilities for insight generation.
\nBest for: Small to mid-size SaaS products that want quick embedded dashboards.\nNot great for: Enterprise multi-tenancy, AI agent integration, or teams that need metrics governance.
\nEmbedded analytics SDK targeting .NET and Java applications. Rich visualization library. Built-in multi-tenancy.
\nBest for: .NET and Java shops building enterprise applications.\nNot great for: React/TypeScript teams, AI agent use cases, or modern data stack.
\nEnterprise embedded analytics platform. Strong multi-tenancy, API access, and metric definitions (“metrics as code” via MAQL). Partial open-source.
\nBest for: Large SaaS companies with enterprise analytics requirements.\nNot great for: Smaller teams, open-source-first teams, or AI agent integration.
\nGoogle Cloud’s BI platform. LookML provides a strong semantic layer, but it’s locked to Looker’s ecosystem. Enterprise pricing. Embedding requires Looker Embed API.
\nBest for: Google Cloud teams with enterprise budgets that need a mature semantic layer.\nNot great for: Teams outside the Google ecosystem, budget-conscious products, or AI agent use cases.
\nMicrosoft’s embedded BI. Capacity-based pricing (SKUs). Deep Azure integration. Complex multi-tenancy setup requiring Azure AD.
\nBest for: Microsoft shops with Azure infrastructure.\nNot great for: Non-Microsoft teams, simple multi-tenancy, or AI agent access.
\nSalesforce’s visualization platform. Rich charting. Embedding requires Tableau Server/Cloud plus custom auth. Per-seat pricing.
\nBest for: Organizations deeply invested in Tableau with budget for per-seat licensing.\nNot great for: B2B products with many end users (per-seat cost is prohibitive). No AI agent support.
\nNot an embedded BI tool. @bonnard/mcp-charts is a visualize tool you add to your MCP server. You call addCharts(server, { runSql }), and it registers a visualize tool that renders interactive charts from your query results, inside the agent. When the agent asks for a chart, your runSql returns rows, Bonnard infers the chart from the typed result, and renders an interactive ui:// widget in Claude or ChatGPT. Chart types: line, bar, area, pie, scatter, funnel, waterfall, and table (with stacked, grouped, horizontal, and 100% bar variants). Native adapters for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or your own runSql. Bonnard never touches your database.
Best for: Teams already building an MCP server who want interactive charts inside Claude or ChatGPT, rendered from their own query results.\nNot great for: Teams that want in-product dashboards for non-technical users. This is charts for AI agents, not an embedded dashboard tool.
\nChoose dashboard embedding (Metabase, Holistics, Explo, Luzmo, Reveal) if:
\nChoose enterprise BI embedding (Looker, Power BI, Tableau) if:
\nChoose charts for AI agents via MCP (Bonnard) if:
\nrunSql returns rows and you want Bonnard to infer the chart from the typed resultMetabase (AGPL) is the most popular free option for dashboards. Superset (Apache 2.0) is free for SQL-native dashboards. If you want charts inside an AI agent rather than an embedded dashboard, @bonnard/mcp-charts is a free, open-source visualize tool for your MCP server. “Free” depends on what you need: basic charting, full embedded BI, or interactive charts inside Claude or ChatGPT.
Embedded analytics is analytics integrated directly into your product for end users. Instead of linking customers to a separate BI tool, charts and metrics appear inside your application. Ranges from basic iframe embedding to native SDK components with governed metrics.
\nFree (Metabase OSS) to enterprise pricing (Looker, Tableau). Mid-range tools (Explo, Holistics, Luzmo) charge per-user or usage-based, typically $500-5,000/mo. If your need is charts inside an AI agent rather than an embedded dashboard, @bonnard/mcp-charts is open source and installs via npm.
Tools with structural multi-tenancy (enforced at the query layer): Explo, Holistics. Tools with configuration-based multi-tenancy: Metabase Enterprise (sandboxing), Power BI (Azure AD + RLS). Tools with no built-in multi-tenancy: Metabase OSS, Superset, Redash.
\nThe traditional embedded analytics tools render charts in your product, not inside an AI agent. Some enterprise tools (Power BI Copilot, Luzmo, GoodData) have limited AI features but none render interactive charts inside an MCP host. If you want charts inside the agent, that’s a different category: @bonnard/mcp-charts adds a visualize tool to your MCP server that renders interactive charts from your query results in Claude or ChatGPT. Install it with npm install @bonnard/mcp-charts. Repo: github.com/bonnard-data/mcp-charts. More in the MCP charts guide.
Your B2B customers want to see their data. Usage metrics, billing summaries, conversion funnels, performance dashboards. Every customer expects analytics inside your product. They shouldn’t have to ask your support team for a CSV export.
\nThe question isn’t whether to ship customer-facing analytics. It’s how.
\nMost teams start with one of two approaches. They embed a BI tool (Metabase, Looker, Power BI) and fight with multi-tenancy, iframe styling, and paid embedding licenses. Or they build custom charts from scratch and spend months maintaining SQL queries, API endpoints, and frontend components that nobody asked for.
\nBoth approaches burn engineering time on the wrong problem. You end up building analytics infrastructure instead of your product.
\nAnd there’s a surface most of these tools miss entirely: the AI agent. Customers increasingly want to ask questions about their data inside Claude or ChatGPT and get a chart back. That’s a different problem from embedding a dashboard, and it’s where @bonnard/mcp-charts fits, covered later in this post.
Embedding a BI tool sounds fast. Drop in an iframe, connect to your database, ship it. In practice, the friction shows up quickly.
\nMost BI tools were built for internal teams, not B2B products serving hundreds of tenants. Multi-tenancy is either missing, manual, or gated behind an enterprise license.
\nMetabase requires the Enterprise license ($500+/month) for row-level permissions and sandboxed embedding. The open-source version has basic embedding but no tenant isolation. You end up writing middleware to filter queries by tenant, which is exactly the custom infrastructure you were trying to avoid.
\nLooker’s embedded analytics requires an enterprise contract. Power BI Embedded uses capacity-based pricing that gets expensive at scale. Tableau’s embedding story is Salesforce-priced.
\nEven when multi-tenancy is available, it’s usually dashboard-level or role-based, not per-query structural enforcement. You’re trusting the BI tool to filter correctly on every query. One misconfiguration and Customer A sees Customer B’s data.
\nAn iframe is a foreign element in your product. It looks like a foreign element. Matching your brand’s fonts, colors, spacing, and interaction patterns inside an embedded BI tool ranges from difficult to impossible. Your customers notice.
\nWhite-label analytics means your customers shouldn’t know they’re using a third-party tool. Most embedded BI solutions make this hard. The ones that make it easy charge for it.
\nEmbedded BI gives you dashboards. That’s one surface. But your customers might also want:
\nEach of these requires a different integration, often with different tools and different metric definitions. The dashboard shows one number. The API returns a different one. The export uses yet another query. The metrics drift.
\nThe alternative: skip the BI tool and build it yourself. Custom SQL queries, custom API endpoints, custom React charts.
\nThis works for the first dashboard. Then the second. By the tenth, you’re maintaining a bespoke analytics platform. Every new metric means a new SQL query, a new API endpoint, a new frontend component, and a new set of tests. Your data engineers are writing API handlers instead of defining metrics. Your frontend engineers are debugging chart edge cases instead of building product features.
\nThe real cost isn’t the initial build. It’s the ongoing maintenance:
\nThe teams on Reddit asking “Is embedded analytics for SaaS actually worth it vs building your own charts?” are wrestling with exactly this tradeoff. There’s no single right answer. The decision depends on how many surfaces you serve and whether your customers want charts in a dashboard, an API, or an AI agent.
\nThe sections above cover the two classic customer-facing analytics options: embed a BI tool or build dashboards from scratch. There’s a third surface that neither covers well: the AI agent. When your customer asks a question in Claude or ChatGPT and wants a chart back, an embedded dashboard doesn’t help.
\n@bonnard/mcp-charts is the MCP-native option for that surface. It is not an embedded BI tool, a dashboard product, or a multi-tenant analytics platform. It is a visualize tool you add to your MCP server that renders interactive charts from your query results, inside the agent.
Install the package and call addCharts with your existing MCP server and a runSql function:
import { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, {\n runSql: async (sql) => {\n // Run the query against your database and return typed rows.\n return await db.query(sql);\n },\n});addCharts registers a visualize tool on your server. The flow:
visualize with a query.runSql returns rows.ui:// widget in Claude or ChatGPT.Chart types: line, bar, area, pie, scatter, funnel, waterfall, and table. Bar charts have stacked, grouped, horizontal, and 100% variants, and a donut is a pie variant. Axes, formatting, and gap-fill are determined automatically, so the same query produces the same chart.
\nNative adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB. You can also pass your own runSql. Bonnard never touches your database. Your code runs the query and returns the rows.
The visualize tool returns compact summaries, row caps with completeness flags, and a typed schema so the agent can reason about the result. Errors are instructive and include a next_step, so when a query fails the agent knows what to try next. For how this is designed, see how Bonnard builds agent-friendly MCPs.
| \n | Build from scratch | \nEmbed BI tool | \nCharts in AI agent (MCP) | \n
|---|---|---|---|
| Surface | \nIn your product UI | \nIn your product UI | \nInside Claude or ChatGPT | \n
| Time to first chart | \n2-4 months | \n1-2 weeks | \nA few lines (addCharts) | \n
| What renders the chart | \nYour frontend code | \nThe BI tool | \nThe agent host (ui:// widget) | \n
| Where the query runs | \nYour code | \nThe BI tool | \nYour runSql, your database | \n
| Chart types | \nWhatever you build | \nTool’s library | \nline, bar, area, pie, scatter, funnel, waterfall, table | \n
| Maintenance burden | \nHigh (you own everything) | \nMedium (tool updates, iframes) | \nLow (one tool registration) | \n
| AI agent support | \nBuild from scratch | \nNone | \nNative (visualize tool) | \n
These are not competing for the same slot. Embedded BI and a from-scratch build put charts in your product UI. Charts in the agent put them inside Claude or ChatGPT. Many teams will do both.
\nEmbedded analytics tools (Metabase Embedded, Holistics, Explo, Luzmo, Reveal) give you dashboards inside your product. That’s their scope. They’re good at it. None of them render a chart inside an AI agent.
\n@bonnard/mcp-charts is the adjacent option, not a member of the embedded BI category:
1. The chart lives in the agent. When a customer asks a question in Claude or ChatGPT, the visualize tool renders an interactive ui:// widget right in the conversation. An embedded dashboard can’t do that.
2. Your database stays yours. Bonnard never touches your database. Your runSql runs the query and returns the rows. Bonnard infers the chart from the typed result.
3. Designed for the agent. Compact summaries, row caps with completeness flags, typed schema, and instructive errors with a next_step. The tool is built for an agent to call, not only for a human to read.
The tradeoff: embedded BI tools render charts in your product UI, which is where many customers expect them. @bonnard/mcp-charts only covers the agent surface. If your customers want both a dashboard and an in-agent chart, use an embedded BI tool for the dashboard and @bonnard/mcp-charts for the agent.
Install the package and register the tool on your MCP server:
\nnpm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, {\n runSql: async (sql) => db.query(sql),\n});That registers the visualize tool. Connect your server in Claude or ChatGPT, and the agent can render charts from your query results. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.
Repo: github.com/bonnard-data/mcp-charts. For the full walkthrough: MCP charts. For the design principles: how Bonnard builds agent-friendly MCPs.
\nCustomer-facing analytics is analytics embedded in your product for your customers to use. Instead of internal dashboards for your team, the analytics are exposed to end users: your B2B customers, their teams, and their tools. The key challenges are multi-tenancy (each customer sees only their data), performance (customers expect fast load times), and consistency (the numbers should match across every surface).
\nEmbedded analytics means integrating analytics capabilities directly into another application. This can be as simple as an iframe embedding a dashboard or as sophisticated as native React components querying a governed API. The term covers a range of approaches from basic chart embedding to full white-label analytics platforms.
\nMetabase offers embedded dashboards via iframe or full-app embedding. The open-source version has basic embedding but no tenant isolation. The Enterprise version ($500+/month) adds row-level permissions and sandboxed embedding. Metabase renders charts in your product UI. @bonnard/mcp-charts is a different surface entirely: it renders interactive charts inside an AI agent (Claude or ChatGPT) via a visualize tool on your MCP server. They are not substitutes. Use Metabase for an in-product dashboard, and @bonnard/mcp-charts for charts in the agent.
White-label analytics means your customers see your brand, not a third-party tool’s brand. No “Powered by Metabase” footer. No foreign-looking iframe. The analytics feel native to your product. Most embedded BI tools charge for white-labeling, and the harder it is to match your design, the more obvious the third-party tool becomes. This is a property of in-product embedding, not of charts rendered inside an AI agent.
\nIt is letting your customers ask questions about their data inside an AI agent (Claude or ChatGPT) and get a chart back. @bonnard/mcp-charts covers this with a visualize tool you add to your MCP server. The agent calls visualize, your runSql returns rows, and Bonnard renders an interactive chart in the conversation. This is the 2026 surface that embedded BI tools do not address.
Yes, if you expose an MCP server. Add @bonnard/mcp-charts with addCharts(server, { runSql }), and the agent can call visualize to render interactive charts from your query results in Claude or ChatGPT. Your runSql runs the query against your database, so Bonnard never touches your data. See MCP for how the protocol works.
Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB. You can also pass your own runSql function to query anything that returns rows. Bonnard never connects to your database directly.
It is open source. Install it with npm install @bonnard/mcp-charts. Repo: github.com/bonnard-data/mcp-charts.
Your company has a KPI dashboard. It was built six months ago by someone who has since moved teams. It shows revenue, churn, and a few product metrics. It loads slowly. The numbers don’t match what finance reports. Nobody trusts it, but everyone screenshots it for the Monday standup.
\nThis is the state of KPI dashboards at most companies. Not because the tools are bad, but because the approach is wrong. A dashboard is a static view of a dynamic system. The moment someone builds it, it starts drifting from reality.
\nA KPI (Key Performance Indicator) dashboard is a visual display of an organization’s most important metrics. Revenue, customer count, churn rate, conversion rate, average order value, NPS. The metrics that tell you whether the business is healthy.
\nTraditional KPI dashboards live in a BI tool: Power BI, Tableau, Looker, Metabase, Grafana. An analyst builds the dashboard, connects it to a data source, and shares a link. People visit the dashboard (or receive a scheduled screenshot) to check the numbers.
\nThe concept is sound. The execution breaks for predictable reasons.
\nBefore diving into what’s broken, here’s what teams typically build:
\nSaaS executive dashboard. MRR, ARR, net revenue retention, churn rate, new customers this month, average contract value. Updated daily. Viewed by the CEO and board. The numbers must match the finance team’s report exactly.
\nProduct analytics dashboard. Daily active users, feature adoption rates, conversion funnel stages, time to value. Updated hourly. Viewed by product managers. Often the first dashboard built and the first to drift from reality.
\nCustomer health dashboard (B2B). Per-customer usage metrics, support ticket volume, NPS, renewal risk score. Updated daily. Viewed by customer success. In embedded analytics use cases, the customer sees this too.
\nEngineering operations dashboard. API error rates, p95 latency, deployment frequency, uptime. Updated real-time. Viewed by engineering leads. Often built in Grafana rather than a BI tool.
\nSales pipeline dashboard. Open deals by stage, weighted pipeline value, win rate, average deal cycle. Updated daily. Viewed by sales leadership. Usually lives in Salesforce or a connected BI tool.
\nEach of these follows the same pattern: connect to a data source, write queries, build charts, share a link. The problems start when multiple dashboards need the same metric (revenue, active users, churn) and define it differently.
\nRevenue is defined in the dashboard as SUM(amount) WHERE status = 'completed'. Finance defines it as SUM(amount) WHERE status != 'refunded' AND type != 'trial'. The CFO looks at the dashboard, compares it to the finance report, and stops trusting the dashboard. This happens every quarter at companies without a shared metric layer.
The root cause: business logic is defined in the dashboard, not in a governed layer. Every dashboard that shows revenue re-implements the calculation. Each implementation drifts independently.
\nDashboards that load in 8 seconds don’t get used. Dashboards behind a BI tool login don’t get used. Dashboards that require navigating to a separate tool don’t get used. The data team builds 50 dashboards. Three get regular traffic. The rest are abandoned.
\nThe data team keeps building new ones because stakeholders keep asking. Each request means a new dashboard, a new query, a new maintenance burden. The team becomes a dashboard factory instead of building the metrics layer that would make dashboards unnecessary.
\nA KPI dashboard in Looker serves people who open Looker. What about:
\nEach of these requires a different integration. The dashboard metric definitions don’t transfer. You end up rebuilding the same KPIs in every tool, with each copy drifting independently.
\nMost KPI dashboards refresh on a schedule: hourly, daily, sometimes manually. Between refreshes, the numbers are stale. For operational KPIs (active users right now, orders this hour, API error rate), stale data is useless data.
\nEven with real-time refresh, the dashboard is a passive display. It shows numbers. It doesn’t answer questions. “Revenue is down 12% this week” is visible on the dashboard. “Why?” requires a human to open the BI tool, write a query, drill into dimensions, and figure it out. An AI agent could answer that question in seconds, but the dashboard can’t feed an agent.
\nThe static dashboard is a snapshot someone built once. The agent path is different: instead of opening a tool and reading a chart someone else laid out, you ask “how’s revenue trending?” and the agent runs the query and draws the chart in the conversation.
\nThat last step (drawing the chart) is what @bonnard/mcp-charts adds: a visualize tool you add to your MCP server that renders interactive charts from your query results. The agent already has access to your data. The visualize tool turns the rows it gets back into a chart the person can actually read.
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\n// runSql runs against your warehouse and returns typed rows\naddCharts(server, { runSql });addCharts registers a visualize tool on your MCP server. Bonnard never touches your database. Your runSql does, against Postgres, BigQuery, Snowflake, Databricks, DuckDB, or any source you wire up.
visualize with a query, and your runSql returns the rows.ui:// widget right in the conversation.The chart types cover the KPI cases you’d reach for on a dashboard: line, bar, and area for trends, bar variants (stacked, grouped, horizontal, 100%) for breakdowns, pie for shares, scatter for distributions, funnel and waterfall for staged metrics, and a table when the answer is a table. Axes, number formatting, and gap-fill come from the typed schema, so the same KPI query renders the same chart every time.
\nNo dashboard to patch. The KPI gets drawn the moment someone asks, from whatever query answers the question.
\n| Approach | \nMetric governance | \nSurfaces | \nAI agent support | \nMulti-tenant | \nPerformance | \n
|---|---|---|---|---|---|
| Power BI dashboard | \nDAX (locked to PBI) | \nPower BI only | \nCopilot (internal) | \nComplex | \nImport mode or DirectQuery | \n
| Tableau dashboard | \nSemantic model (locked) | \nTableau only | \nLimited | \nEnterprise | \nExtract or live | \n
| Looker dashboard | \nLookML | \nLooker + embed | \nNo | \nEnterprise | \nPDTs | \n
| Metabase dashboard | \nNone | \nMetabase + embed | \nNo | \nEnterprise only | \nNo caching | \n
| Grafana dashboard | \nNone | \nGrafana only | \nNo | \nBasic | \nQuery-level | \n
| Superset dashboard | \nNone | \nSuperset + embed | \nNo | \nLimited | \nNo caching | \n
| Bonnard | \nInherits your runSql | \nAny MCP Apps client | \nMCP native (visualize tool) | \nInherits your runSql | \nInherits your warehouse | \n
The traditional tools render KPIs inside the dashboard tool. Bonnard renders them as interactive charts via the MCP visualize tool, from query results, inside any MCP Apps client.
KPI dashboards aren’t always wrong. They work when:
\nThey break when:
\nAdd a visualize tool to your MCP server so an agent can render a KPI chart on demand:
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, { runSql });That registers the visualize tool on your server. Someone asks the agent for a KPI, your runSql returns the rows, and Bonnard renders an interactive chart inside Claude or ChatGPT. Adapters ship for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.
Full walkthrough: Add Interactive Charts to Your MCP Server. For the design choices behind the tool: How Bonnard Builds Agent-Friendly MCPs.
\nSource is on GitHub.
\nA KPI dashboard is a visual display of key performance indicators: revenue, churn, active users, conversion rate, and other metrics that measure business health. Traditional KPI dashboards live in BI tools like Power BI, Tableau, Looker, or Grafana. Modern approaches define KPIs in a semantic layer and serve them across dashboards, AI agents, and embedded analytics simultaneously.
\nThe KPIs depend on your business. Common B2B SaaS KPIs: MRR, ARR, churn rate, net revenue retention, active users, customer count, NPS, average contract value. The specific metrics matter less than the governance: every KPI should have one canonical definition that every consumer references.
\nFor internal-only dashboards: Power BI (Microsoft ecosystem), Tableau (Salesforce ecosystem), Looker (Google Cloud), or Metabase (open source). For governed KPIs served to multiple surfaces including AI agents and embedded analytics: a semantic layer approach. The right choice depends on how many consumers need the same metrics.
\nMost dashboard slowness comes from querying the warehouse on every render. Pre-aggregation caching pre-computes common KPI rollups. The dashboard queries the cache instead of the warehouse. Response times drop from seconds to single-digit milliseconds.
\nWith a semantic layer and MCP support, yes. AI agents discover available KPIs via explore_schema and query them via query. The agent gets governed, multi-tenant data scoped to their access level. Without a semantic layer, agents generate ad-hoc SQL and return inconsistent numbers. See What Is an Agentic Semantic Layer?.
A KPI dashboard focuses on a small set of headline metrics that measure business health. An analytics dashboard provides broader exploration: filtering, drilling, and ad-hoc querying. In practice, both benefit from governed metric definitions. The KPI dashboard shows the numbers. The analytics dashboard lets you investigate why they changed.
\nDepends on the KPI. Revenue and churn: daily or hourly. Active users and API metrics: real-time or near-real-time. Strategic KPIs (NPS, retention cohorts): weekly or monthly. With pre-aggregation, refresh frequency is configurable per metric. Set aggressive refresh for operational KPIs and relaxed refresh for strategic ones.
\n", "date_published": "2026-03-19T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/real-time-analytics", "url": "https://bonnard.dev/blog/real-time-analytics", "title": "Real-Time Analytics: When You Need It and When You Don't", "summary": "Not every metric needs real-time data. Here's how to decide what needs sub-second freshness, what can be cached, and how pre-aggregation handles both.", "content_html": "“We need real-time analytics” is one of the most common requests in data engineering. It’s also one of the most misunderstood. When the VP of Sales says “real-time,” they usually mean “faster than the dashboard that refreshes overnight.” When the CTO says it, they might mean sub-second event streaming. The gap between those two definitions is a 6-month infrastructure project.
\nMost teams don’t need true real-time. They need fast enough. And “fast enough” is achievable with pre-aggregation caching at a fraction of the complexity and cost of a streaming architecture.
\nReal-time analytics means querying data with minimal latency between when an event happens and when it’s visible in your analytics. The spectrum:
\n| Freshness | \nLatency | \nArchitecture | \nUse case | \n
|---|---|---|---|
| True real-time | \n< 1 second | \nEvent streaming (Kafka, Flink) | \nFraud detection, stock trading, live monitoring | \n
| Near real-time | \n1-60 seconds | \nMicro-batch or streaming | \nOperational dashboards, alerting | \n
| Frequent refresh | \n1-60 minutes | \nScheduled refresh + caching | \nKPI dashboards, AI agent queries | \n
| Batch | \nHours to daily | \nScheduled ETL | \nBoard reports, monthly summaries | \n
Most analytics use cases fall in the “frequent refresh” category. Revenue by region doesn’t need sub-second freshness. Active users in the last hour doesn’t need event streaming. A pre-aggregation cache that refreshes every 15 minutes covers 90% of what teams call “real-time.”
\nTrue real-time analytics (sub-second latency from event to query result) is worth the infrastructure investment when:
\nIf you’re in one of these categories, you need an event streaming architecture: Kafka, Flink, Materialize, or similar. A semantic layer complements this by governing the metric definitions, but the freshness comes from the streaming pipeline.
\nMost business analytics doesn’t need sub-second freshness. It needs:
\nPre-aggregation gives you all three without a streaming architecture.
\nThe semantic layer pre-computes your most common queries and caches the results. When a dashboard or AI agent asks for “revenue by region this month,” the query hits the cache instead of scanning raw warehouse tables.
\ncubes:\n - name: orders\n sql_table: public.orders\n measures:\n - name: total_revenue\n sql: \"CASE WHEN status != 'refunded' THEN amount ELSE 0 END\"\n type: sum\n - name: order_count\n type: count\n dimensions:\n - name: region\n sql: region\n type: string\n - name: created_at\n sql: created_at\n type: time\n\n pre_aggregations:\n - name: revenue_by_region\n measures:\n - total_revenue\n - order_count\n dimensions:\n - region\n time_dimension: created_at\n granularity: day\n refresh_key:\n every: 15 minutesThe cache rebuilds every 15 minutes. Queries that match the pre-aggregation return in single-digit milliseconds. Queries that don’t match fall through to the warehouse (seconds).
\nThe result: your dashboard loads in under a second. Your AI agent gets responses in milliseconds. Your data is at most 15 minutes old. For 90% of analytics use cases, this is indistinguishable from “real-time.”
\nNot all metrics need the same freshness. Configure per rollup:
\n pre_aggregations:\n # Operational: refresh every 5 minutes\n - name: active_users_live\n measures: [active_users]\n time_dimension: last_seen_at\n granularity: minute\n refresh_key:\n every: 5 minutes\n\n # Strategic: refresh every hour\n - name: daily_revenue\n measures: [total_revenue, mrr]\n dimensions: [plan, region]\n time_dimension: created_at\n granularity: day\n refresh_key:\n every: 1 hour\n\n # Historical: refresh daily\n - name: monthly_cohorts\n measures: [retention_rate, ltv]\n dimensions: [cohort_month, plan]\n time_dimension: created_at\n granularity: month\n refresh_key:\n every: 24 hoursOperational metrics refresh every 5 minutes. Revenue refreshes hourly. Historical cohorts refresh daily. Each metric gets the freshness it needs without over-engineering.
\nIf you’re shipping analytics to B2B customers, “real-time” has a different meaning. Your customers expect their dashboards to load fast and show recent data. They don’t expect sub-second event streaming.
\nPre-aggregation handles this well:
\n| Approach | \nFreshness | \nQuery speed | \nComplexity | \nCost | \nBest for | \n
|---|---|---|---|---|---|
| Event streaming (Kafka + Flink) | \nSub-second | \nFast (materialized views) | \nVery high | \nHigh | \nFraud, trading, live monitoring | \n
| Streaming DB (Materialize, RisingWave) | \nSeconds | \nFast | \nHigh | \nMedium-high | \nContinuous queries, CDC | \n
| Warehouse + pre-aggregation | \nMinutes | \nMilliseconds (cached) | \nLow | \nLow-medium | \nDashboards, AI agents, embedded analytics | \n
| Warehouse direct | \nMinutes-hours (ETL dependent) | \nSeconds | \nLow | \nMedium | \nAd-hoc analysis, batch reports | \n
| Spreadsheet | \nManual | \nN/A | \nNone | \nFree | \nOne-off analysis | \n
For most teams, the warehouse + pre-aggregation approach covers the use case. Add streaming only for the metrics that genuinely need sub-second freshness.
\nOnce your queries return fast enough, agents become a consumer, and an agent that fetches rows still has to chart them. Add a visualize tool to your MCP server so it can:
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, { runSql });That registers the visualize tool on your server. The agent calls it with a query, your runSql returns the rows (from a cached rollup or the warehouse), and Bonnard renders an interactive chart inside Claude or ChatGPT. Adapters ship for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql.
Full walkthrough: Add Interactive Charts to Your MCP Server. For the design choices behind the tool: How Bonnard Builds Agent-Friendly MCPs.
\nSource is on GitHub.
\nReal-time analytics means querying data with minimal delay between when events happen and when they appear in your analytics. True real-time (sub-second) requires event streaming. Near-real-time (minutes) is achievable with pre-aggregation caching on top of a data warehouse.
\nMost business analytics doesn’t need sub-second freshness. If your use case is dashboards, AI agent queries, or embedded analytics, a pre-aggregation cache refreshing every 5-60 minutes provides “real-time” performance at a fraction of the streaming complexity. True real-time is needed for fraud detection, live monitoring, and financial trading.
\nBatch analytics processes data on a schedule (hourly, daily). Real-time analytics processes data continuously with minimal delay. Pre-aggregation caching sits in between: the cache rebuilds on a schedule (every N minutes), but queries against the cache return in milliseconds. It’s batch refresh with real-time query performance.
\nPre-aggregation pre-computes your most common queries and caches the results. When a user or AI agent queries “revenue by region,” the response comes from the cache in single-digit milliseconds instead of scanning raw warehouse tables (which takes seconds). The data is minutes old, but the query feels instant.
\nStreaming analytics processes events as they arrive, maintaining continuously updated query results. Technologies include Kafka, Flink, Materialize, and RisingWave. It’s the right choice for sub-second freshness requirements. For most business analytics, pre-aggregation caching provides comparable user experience at lower cost and complexity.
\n", "date_published": "2026-03-19T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/self-service-bi", "url": "https://bonnard.dev/blog/self-service-bi", "title": "Self-Service BI Is a Lie (Unless You Govern the Metrics)", "summary": "Self-service BI for customers promised to free the data team. Instead it created metric chaos. The category, the tradeoffs, and where AI agent charts fit.", "content_html": "Self-service BI was supposed to free the data team. Give everyone a BI tool, teach them to drag and drop, and they’ll answer their own questions. The data team can stop building dashboards and focus on infrastructure.
\nThat’s not what happened.
\nWhat happened: everyone builds their own dashboards with their own metric definitions. Marketing’s “active users” counts monthly logins. Product’s “active users” counts weekly feature usage. Finance’s “active users” counts paying customers. Three dashboards, three numbers, one term. The data team now spends their time reconciling conflicting metrics instead of building.
\nSelf-service BI without governed metrics is just self-service chaos.
\nSelf-service BI means non-technical users can query data, build visualizations, and generate reports without help from the data team. The tools (Metabase, Looker, Power BI, Tableau, Superset) provide drag-and-drop interfaces, visual query builders, and template libraries.
\nThe promise: democratize data access. Anyone can answer their own questions.
\nThe reality: it works for simple questions (“how many orders this week?”) and breaks for anything requiring business logic (“what’s our net revenue retention?”). Users either define metrics incorrectly or ask the data team anyway. The data team becomes a help desk for the self-service tool instead of a help desk for SQL.
\nWithout a central definition, every self-service user creates their own version of key metrics. A company with 50 Metabase users might have 30 different “revenue” calculations saved across collections. Which one is right? The one that matches the board report. Which one matches the board report? Nobody knows without checking each one.
\nTrue self-service requires understanding the data model. Which table has revenue? What does status = 3 mean? Is the amount column in cents or dollars? Pre-tax or post-tax? Including shipping or excluding?
Without this context, self-service users either guess (and get wrong answers) or ask the data team (and it’s not self-service). The BI tool gives access to data. It doesn’t give understanding of what the data means.
\nEvery self-service user creates dashboards for their use case. The dashboard count grows from 10 to 500. Most are stale. Many are duplicates. Finding the right dashboard becomes its own research project. The data team periodically “cleans up,” deleting abandoned dashboards and breaking someone’s workflow each time.
\nOpen-source BI tools make self-service accessible without enterprise licensing. The main options:
\nThey share the same fundamental limitation: no semantic layer. Users query raw tables and define metrics ad-hoc. The open-source tools democratize access. They don’t democratize understanding.
\nReal self-service means anyone can query data and get the right answer. Not “anyone can query data and get an answer.” The difference is governance.
\ncubes:\n - name: revenue\n sql_table: analytics.revenue\n measures:\n - name: total_revenue\n sql: \"CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END\"\n type: sum\n description: \"Finance-approved revenue definition (excludes refunds and trials)\"\n - name: net_revenue_retention\n sql: \"current_period_mrr / prior_period_mrr\"\n type: avg\n description: \"NRR for existing customer cohorts\"\n dimensions:\n - name: plan\n sql: plan_name\n type: string\n - name: region\n sql: region\n type: string\n - name: period\n sql: period_date\n type: timeThese definitions live in Git. Finance approves them in a pull request. When the definition changes, every consumer gets the update. There’s one “revenue.” Not 30.
\nThe product manager asks an AI agent: “What’s revenue by plan this quarter?” The agent calls explore_schema, finds revenue.total_revenue, and queries it. Same definition finance approved.
The customer success team views an embedded analytics dashboard in the product. Same definition.
\nThe CEO checks a markdown dashboard. Same definition.
\nNobody re-implements the metric. Nobody guesses which table to query. The data team defined it once. Every surface serves it.
\nWith governed metrics, the data team’s job shifts from “answer ad-hoc questions” and “reconcile conflicting dashboards” to “define and maintain metric definitions.” They add new metrics, refine existing ones, and optimize pre-aggregation strategies. The mechanical work (querying, formatting, presenting) is handled by the semantic layer and its consumers.
\n| Tool | \nSelf-service model | \nGoverned metrics | \nAI agent support | \nOpen source | \n
|---|---|---|---|---|
| Metabase | \nVisual query builder | \nNo | \nNo | \nYes (AGPL) | \n
| Superset | \nSQL + visual builder | \nNo | \nNo | \nYes (Apache 2.0) | \n
| Redash | \nSQL editor | \nNo | \nNo | \nYes | \n
| Power BI | \nDrag-and-drop | \nDAX (PBI only) | \nCopilot | \nNo | \n
| Tableau | \nDrag-and-drop | \nTableau model | \nLimited | \nNo | \n
| Looker | \nLookML + Explore | \nLookML | \nNo | \nNo | \n
| ThoughtSpot | \nNatural language search | \nProprietary | \nProprietary | \nNo | \n
| Charts in AI agent (Bonnard) | \nCharts inside Claude or ChatGPT via MCP | \nN/A (your runSql) | \nNative (visualize tool) | \nYes (npm) | \n
The tools in the top half give users direct data access with no metric governance. The tools in the bottom half add governance but lock it to their ecosystem. The bottom row is a different kind of option: @bonnard/mcp-charts does not replace a BI tool. It adds a visualize tool to your MCP server so customers get interactive charts inside Claude or ChatGPT, rendered from your own query results.
Self-service BI works when:
\nIt breaks when:
\nGoverned metrics fix the consistency problem for internal self-service. There’s a separate question for customer-facing self-service: where does the customer ask their question? Increasingly the answer is an AI agent. They want to ask about their data in Claude or ChatGPT and get a chart back.
\n@bonnard/mcp-charts covers that surface. It is not a BI tool or a dashboard product. It is a visualize tool you add to your MCP server that renders interactive charts from your query results, inside the agent.
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, {\n runSql: async (sql) => db.query(sql),\n});addCharts registers a visualize tool. The agent calls visualize, your runSql returns rows, Bonnard infers the chart from the typed result, and it renders an interactive ui:// widget in Claude or ChatGPT. Chart types: line, bar, area, pie, scatter, funnel, waterfall, and table. Native adapters cover Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql. Bonnard never touches your database.
For background: What Is a Semantic Layer?. For the full walkthrough: MCP charts.
\nRepo: github.com/bonnard-data/mcp-charts.
\nSelf-service BI is a BI model where non-technical users can query data, build visualizations, and generate reports without help from the data team. Tools like Metabase, Power BI, and Tableau provide drag-and-drop interfaces for this. The limitation: self-service without governed metrics leads to inconsistent numbers across the organization.
\nFor internal dashboards: Metabase (most popular), Superset (more technical), or Redash (SQL-focused). For governed metrics served to multiple surfaces including AI agents: a semantic layer approach. Open-source BI tools give you self-service querying. A semantic layer gives you self-service with correct, governed answers.
\nSelf-service BI gives users tools to query data. A semantic layer defines what the data means. They’re complementary: a self-service BI tool with a semantic layer underneath gives users access to governed metrics. Without the semantic layer, self-service users define metrics ad-hoc and the numbers diverge.
\nDefine each metric once in a semantic layer. Version the definitions in Git. Review changes in pull requests. Serve the same definitions to every consumer. When everyone queries the same governed definitions, there’s nothing to reconcile.
\nDecide where customers ask their questions. A traditional embedded BI tool puts a dashboard in your product. The newer surface is the AI agent: customers ask in Claude or ChatGPT and get a chart back. For that surface, @bonnard/mcp-charts adds a visualize tool to your MCP server that renders interactive charts from your query results. The two are complementary, not substitutes. Install with npm install @bonnard/mcp-charts.
Your data warehouse has a table called orders. It has columns like amount, status, created_at, and customer_id. Now three people ask “What was Q1 revenue?”
The analyst writes SELECT SUM(amount) FROM orders WHERE created_at BETWEEN '2026-01-01' AND '2026-03-31'. The data engineer adds WHERE status = 'completed'. Finance excludes refunds and trial conversions. Three queries, three numbers, one question. Nobody is wrong. They just defined “revenue” differently.
Multiply this by every metric in your organization, every team that queries the warehouse, and every tool that displays a number. That’s the problem.
\nA semantic layer solves it by defining each metric once, in one place, and serving that definition to every consumer.
\nA semantic layer is a metadata layer between your data warehouse and every tool that queries it. It defines business metrics, maps them to SQL, and exposes them through APIs. Instead of every consumer writing its own query, they all reference the same definition.
\nWhen someone asks for “revenue,” the semantic layer knows that means:
\nSUM(CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END)That definition lives in one place. Dashboards, APIs, AI agents, and ad-hoc queries all use it. Change the definition once and every consumer gets the updated calculation. No Slack thread asking “which number is right.” No detective work tracing a wrong number back to a stale query in a notebook somewhere.
\nThe core components of a semantic layer:
\nThe idea of abstracting business logic from raw data isn’t new.
\nIn the 1990s, Business Objects introduced “universes,” metadata layers that mapped business terms to database columns. Analysts queried “Revenue by Region” without knowing the underlying table structure. It worked, but only within Business Objects.
\nSSAS (SQL Server Analysis Services) cubes brought multidimensional modeling to the Microsoft stack. You defined measures and dimensions in a cube, and every Excel pivot table and SSRS report consumed the same definitions. Powerful, but tightly coupled to the Microsoft ecosystem.
\nLooker’s LookML (2012) moved semantic modeling into code. Metric definitions lived in version-controlled files, not a GUI. This was a significant shift: data teams could review metric changes in pull requests, not point-and-click editors. But LookML was (and is) proprietary to Looker, which is now proprietary to Google Cloud.
\ndbt’s MetricFlow (2023) brought metric definitions into the dbt ecosystem. Define metrics alongside your transformations. Good idea, but MetricFlow defines metrics without serving them: no caching, no multi-tenancy, no API layer.
\nThe current generation of semantic layers (Cube, AtScale) are standalone infrastructure. They connect to any warehouse, serve any consumer, and run independently of your BI tool. The semantic layer is no longer a feature inside a product. It’s a layer in the stack.
\nWhat’s driving this shift: the number of consumers has exploded. In 2015, a semantic layer served dashboards. In 2026, it also serves AI agents via MCP. One definition needs to serve all of them, and the newest consumer is an agent that queries metrics and then wants to chart the result in the conversation. A BI-embedded semantic layer can’t reach that consumer at all.
\nWithout a semantic layer, business logic lives in three places: your analysts’ heads, scattered SQL files, and buried dashboard definitions. Each copy drifts over time. Someone updates the revenue definition in Looker but forgets the dbt model. A new analyst writes a fresh query from scratch and gets a number that doesn’t match either.
\nThe cost isn’t abstract:
\nInconsistent metrics. Marketing reports 12% growth. Finance reports 8%. The board meeting stalls while someone debugs which number is right. This happens every quarter at companies without a shared metric layer.
\nDuplicated logic. Every new dashboard, API endpoint, or report re-implements the same calculations. You end up with revenue defined in 14 places, each slightly different, each maintained by a different person. One team discovers a bug in their version and fixes it. The other 13 don’t.
\nSlow onboarding. New data engineers spend weeks learning which queries are canonical and which are stale. “Ask Sarah, she knows which revenue query is the right one.” Tribal knowledge doesn’t scale.
\nThe data team becomes a service desk. Instead of building, they spend their time answering ad-hoc questions: “Can you pull revenue by region for Q4?” “Which dashboard has the right churn number?” “Why does this report show different numbers than that one?” A semantic layer makes the data self-serve. The team defines the metrics. Everyone else queries them.
\nAI agents make it worse. An AI agent with warehouse access generates plausible SQL from column names. It doesn’t know your business rules. Ask two different agents the same question and you’ll get two different numbers. Neither matches finance. Text-to-SQL gives you speed without trust. A semantic layer gives you both.
\nNot all semantic layers work the same way. The architecture matters because it determines what consumers you can serve, how fast queries run, and how much you control.
\nEmbedded semantic layers live inside a BI tool. Looker’s LookML, Tableau’s semantic model, Power BI’s DAX measures. They define metrics well, but only for that tool’s consumers. Your Looker semantic layer doesn’t help your React app or your AI agent. If you’re in one BI tool and staying there, this can be enough. Most teams outgrow it.
\nVirtual semantic layers sit between the warehouse and consumers without moving data. AtScale is the primary example. Queries pass through the semantic layer, which translates them to the right SQL dialect and sends them to the warehouse. No data duplication. The tradeoff: every query hits the warehouse, so latency depends on warehouse performance. Virtual layers add caching to mitigate this, but it’s an optimization, not the default.
\nMaterialized semantic layers pre-compute rollups and store them separately. Cube’s pre-aggregation engine is the best-known example. You define which combinations of measures and dimensions to pre-compute, and the semantic layer builds and maintains those materialized tables. Hot queries hit the cache (single-digit milliseconds). Cold queries fall through to the warehouse. This is how you get sub-second performance at scale.
\nHybrid semantic layers combine virtual and materialized approaches. Most modern semantic layers work this way. Define pre-aggregations for your most-queried metrics. Let everything else pass through to the warehouse. You configure the tradeoff per metric based on query frequency and latency requirements.
\nFor most teams, hybrid is the right choice. You get the flexibility of virtual queries with the performance of materialized caching where it matters.
\nModern semantic layers are defined in code (typically YAML), version-controlled in Git, and deployed as an API. Here’s what that looks like end to end.
\ncubes:\n - name: orders\n sql_table: public.orders\n measures:\n - name: total_revenue\n sql: \"CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END\"\n type: sum\n - name: order_count\n type: count\n - name: average_order_value\n sql: amount\n type: avg\n dimensions:\n - name: status\n sql: status\n type: string\n - name: category\n sql: category\n type: string\n - name: created_at\n sql: created_at\n type: time\n - name: customer_id\n sql: customer_id\n type: stringMeasures are the numbers you aggregate: revenue, count, average. Dimensions are the columns you filter and group by: status, date, category. total_revenue is now a governed definition, not a column someone interprets.
You define joins between cubes to model relationships:
\ncubes:\n - name: customers\n sql_table: public.customers\n joins:\n - name: orders\n relationship: one_to_many\n sql: \"{customers.id} = {orders.customer_id}\"\n measures:\n - name: count\n type: count\n dimensions:\n - name: plan\n sql: plan\n type: string\n - name: signed_up_at\n sql: created_at\n type: timeNow any consumer can query “revenue by customer plan” without knowing how the tables join. The semantic layer handles the SQL generation.
\nQueries against raw warehouse tables are expensive, especially when AI agents are querying them frequently. A pre-aggregation caches rollups so consumers get sub-second responses instead of waiting for full table scans.
\n pre_aggregations:\n - name: daily_revenue\n measures:\n - total_revenue\n - order_count\n dimensions:\n - status\n time_dimension: created_at\n granularity: day\n refresh_key:\n every: 1 hourThe semantic layer rebuilds this rollup every hour. Hot queries hit the cache. Cold queries fall through to the warehouse. You configure the tradeoff per metric: high-traffic metrics get aggressive caching, low-traffic metrics query the warehouse directly.
\nFor B2B products serving multiple customers, every query needs to be scoped to the right tenant. A security context enforces this structurally, not through prompt engineering or middleware hacks.
\n security_context:\n - name: tenant_filter\n sql: \"{SECURITY_CONTEXT.tenant_id} = customer_id\"Every query for a given tenant automatically includes this filter. It’s not optional. The consumer can’t skip it or override it. This is how RBAC works in a semantic layer: defined in the schema, enforced on every query. It doesn’t matter if the consumer is a dashboard, an API call, or an AI agent. The access rules are the same.
\nOne set of definitions, multiple consumers. A BI dashboard queries via REST API. A backend service calls an SDK. An AI agent discovers and queries metrics over MCP. They all hit the same definitions and get the same numbers. That’s the point.
\nThe agent is the consumer that changed the most. It queries a metric, then wants to show the result, not as a wall of numbers but as a chart in the conversation. That’s where @bonnard/mcp-charts comes in: a visualize tool you add to your MCP server that renders interactive charts from your query results, right in Claude or ChatGPT.
import { addCharts } from \"@bonnard/mcp-charts\";\n\n// rows come back from your warehouse, the chart renders in the client\naddCharts(server, { runSql });The agent calls visualize with a query, your runSql returns the rows, Bonnard infers the chart from the typed result, and an interactive widget renders in the host. You write no frontend code, and Bonnard never touches your database. More in the MCP Charts guide.
You’re building a SaaS product and your customers want to see their data. Usage metrics, billing summaries, performance dashboards. Without a semantic layer, you build custom API endpoints for each view, maintain the SQL yourself, and hope the numbers match what your internal dashboards show.
\nWith a semantic layer: define the metrics once with row-level security, and let customers query their data through your product’s UI or through their own AI agents (via MCP). Multi-tenancy is structural. The same metric definition serves every customer with automatic data isolation.
\nYour team built 47 Metabase dashboards. Three of them get used. The rest are stale, broken, or duplicated. The data team spends time maintaining dashboard infrastructure instead of defining the metrics that matter.
\nA semantic layer shifts the model: the data team defines and governs metrics. Consumers choose their own surface. Some use dashboards. Some query the API. Some ask an AI agent. The data team’s job is the definitions, not the delivery mechanism.
\nYour engineering team wants to ship an AI-powered analytics feature. The first prototype uses text-to-SQL. It works in demos and breaks in production: inconsistent numbers, no tenant isolation, no audit trail. The fix isn’t better prompts. It’s a semantic layer. The agent queries metric definitions instead of raw tables. Every answer traces back to a versioned, governed definition. Full walkthrough: How to Connect an AI Agent to Your Data Warehouse.
\nThis is the most common question in the space, and the answer is: they’re complementary, not competing. But the differences matter.
\ndbt defines transformations: how raw data becomes clean tables. It runs SQL models that create dim_customers, fct_orders, and other modeled tables in your warehouse. This is the “T” in ELT. dbt is excellent at this.
dbt’s MetricFlow adds metric definitions on top of those tables. You can define revenue as a metric in your dbt project. This is genuinely useful for documentation and consistency within dbt’s ecosystem.
Where dbt stops: MetricFlow defines metrics but doesn’t serve them to production consumers. There’s no built-in:
\nA standalone semantic layer fills these gaps. It connects to the same warehouse where dbt outputs its modeled tables, defines metrics on top, and serves them with caching, multi-tenancy, and multiple APIs.
\nThe practical workflow: dbt transforms your raw data into clean tables on a schedule. The semantic layer defines business metrics on those tables and serves them to dashboards, applications, and AI agents in real time. Many semantic layers can import dbt models directly. You don’t choose between them. You use both.
\nSeveral tools occupy this space, each with different design priorities.
\n| Tool | \nApproach | \nStrengths | \nLimitations | \n
|---|---|---|---|
| Cube | \nOpen-source semantic layer engine | \nBattle-tested query engine, pre-aggregation, REST API, large community | \nNo built-in MCP, dashboards, or multi-tenant keys. You build the product layer yourself. | \n
| dbt Semantic Layer / MetricFlow | \nMetric definitions in dbt | \nTight dbt integration, SQL-native, good for documentation | \nDefines metrics but doesn’t serve them. No caching, no multi-tenancy, no agent support. | \n
| Looker (LookML) | \nBI-embedded semantic layer | \nMature modeling language, strong governance, Google Cloud integration | \nExpensive, enterprise-only, proprietary. Definitions locked to Looker’s ecosystem. No MCP. | \n
| AtScale | \nVirtual semantic layer | \nEnterprise BI compatibility, no data movement, MDX/DAX support | \nEnterprise pricing. Not agent-native. Complex deployment. | \n
| Power BI (DAX) | \nBI-embedded semantic layer | \nDeep Microsoft integration, familiar to analysts | \nLocked to Power BI ecosystem. No API serving. No multi-tenancy for embedded use cases. | \n
| Tableau (Semantic Model) | \nBI-embedded semantic layer | \nVisual modeling, strong visualization | \nDefinitions don’t leave Tableau. No API access. Salesforce pricing. | \n
| Bonnard | \nInteractive charts via the MCP visualize tool | \n@bonnard/mcp-charts adds a visualize tool to your MCP server, rendering charts in Claude/ChatGPT from your query results. No frontend code. | \nCharts the result, not a full semantic layer engine. Pair it with one. | \n
The right choice depends on your primary consumer. If internal dashboards are the only output and you’re already in Looker or Power BI, the embedded semantic layer may be sufficient. If you’re serving multiple consumers (customer-facing products, AI agents, APIs, internal dashboards), you need a standalone semantic layer that isn’t locked to one tool.
\nYour semantic layer needs to work with your warehouse. The integration isn’t just “can it connect.” It’s how well the semantic layer exploits each warehouse’s strengths.
\nSnowflake. Pre-aggregations work well with Snowflake’s auto-suspend compute. The semantic layer can target specific virtual warehouses for different workloads: fast cache rebuilds on a small warehouse, heavy ad-hoc queries on a larger one. Snowflake’s separation of storage and compute means pre-aggregation tables don’t compete with production workloads.
\nBigQuery. BigQuery’s slot-based pricing means pre-aggregations save real money. Every query scans data and costs money. Caching a daily revenue rollup avoids scanning terabytes of raw data on every request. The semantic layer’s pre-aggregation layer can cut BigQuery costs by 10-100x for frequently queried metrics.
\nDatabricks. Unity Catalog provides table-level governance. The semantic layer adds metric-level governance on top: defining what “revenue” means, not just who can access the orders table. Databricks’ Photon engine handles the heavy queries. The semantic layer caches the results.
PostgreSQL (including Supabase, Neon, and RDS). Works well for smaller datasets and development. Most teams start with Postgres for prototyping their semantic layer and migrate to a cloud warehouse as data volume grows. Pre-aggregation is especially valuable here because Postgres doesn’t have the raw compute power of cloud warehouses for large analytical queries.
\nDuckDB (including MotherDuck). In-process analytical database. Useful for local development and testing without a remote warehouse connection. Define your metrics, test locally against DuckDB, deploy to production against Snowflake or BigQuery. Same schema, different warehouses.
\nIf you’re choosing a semantic layer for your stack, here’s what to look at:
\nWho are your consumers? This is the most important question. If it’s only internal dashboards, an embedded semantic layer in your BI tool might be enough. If it’s dashboards plus a customer-facing product plus AI agents, you need a standalone semantic layer with API serving.
\nDoes it support your warehouse? Check for native support, not just “we can connect via JDBC.” Native support means the semantic layer generates optimized SQL for your specific warehouse dialect and exploits warehouse-specific features like Snowflake’s clustering or BigQuery’s partitioning.
\nHow does it handle caching? Pre-aggregation support varies widely. Some tools don’t cache at all (every query hits the warehouse). Some cache at the query level. The best cache at the metric level with configurable refresh schedules and automatic invalidation. If AI agents are querying your data, caching is not optional.
\nMulti-tenancy. If you’re building a B2B product, every query needs tenant isolation. Look for structural multi-tenancy (security context in the schema), not middleware-level filtering. One missed filter is a data leak.
\nSchema-as-code. Metric definitions should live in version control. Changes should go through pull requests. Rollbacks should be git revert, not clicking through a UI. If you can’t diff your metric definitions, you can’t govern them.
AI agent support. If AI agents are current or future consumers, look for MCP support or a tool-use interface. An API is the minimum. MCP is the emerging standard for agent-to-tool communication and gives agents native discovery of available metrics.
\nNot every team needs one. Here’s when it starts to matter.
\nYou need one when:
\nYou probably don’t need one when:
\nThe threshold is usually “more than one consumer for the same metrics.” Once dashboards, APIs, and applications all need revenue numbers, a shared definition pays for itself immediately.
\nIf you’re evaluating options, start with what your primary consumer needs. Internal dashboards only? Your BI tool’s built-in semantic layer may be enough. dbt-native workflow with documentation as the goal? Start with MetricFlow. Multiple consumers including AI agents? A standalone semantic layer like Cube or AtScale, with metrics defined once and served over an API.
\nWhen AI agents are a consumer, the last mile is the chart. An agent queries a metric, then needs to show the result in the conversation. Add that with one tool:
\nnpm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\naddCharts(server, { runSql });addCharts registers a visualize tool on your MCP server. The agent calls it with a query, your runSql returns the rows, and Bonnard renders an interactive chart in Claude or ChatGPT. Bonnard never touches your database. Repo: github.com/bonnard-data/mcp-charts. Full walkthrough: MCP Charts.
A semantic layer is a single place where you define what business terms like “revenue” or “active user” mean in terms of database columns and calculations. Every tool that needs that number references the same definition instead of writing its own query. One definition, every consumer, same answer.
\nA data warehouse stores your data. A semantic layer defines what the data means. The warehouse has a column called amount. The semantic layer defines that total_revenue = SUM(amount) WHERE status != 'refunded'. They work together: the warehouse holds the data, the semantic layer holds the business logic.
dbt is primarily a transformation tool that models raw data into clean tables. dbt’s MetricFlow adds metric definition capabilities, which is one part of a semantic layer. But a full semantic layer also includes caching, multi-tenancy, access control, and API serving, which MetricFlow doesn’t provide on its own. Most teams use dbt for transformations and a separate semantic layer for metric serving.
\nAn OBT flattens everything into a single denormalized table. A semantic layer keeps your data normalized and defines metrics as calculations across tables. OBTs are simpler at first but break down at scale: they’re expensive to rebuild, hard to govern, and create massive tables with redundant data. A semantic layer gives you the same query simplicity without the storage and maintenance cost.
\nThe terms are often used interchangeably, but a metrics layer is a subset of a semantic layer. A metrics layer defines measures and dimensions. A semantic layer adds relationships (joins), access control, caching, and API serving on top. dbt’s MetricFlow is a metrics layer. Cube and AtScale are full semantic layers.
\nIf AI agents query your data, a semantic layer is the difference between “plausible numbers” and “correct numbers.” Without one, agents interpret column names and generate ad-hoc SQL. With one, agents query governed metric definitions and get the same answer every time. See What Is an Agentic Semantic Layer? for the full breakdown.
\nThrough pre-aggregation. The semantic layer pre-computes common rollups (daily revenue by status, weekly order count by category) and caches the results. Queries hit the cache instead of scanning raw tables. Hot queries resolve in single-digit milliseconds. The cache rebuilds on a configurable schedule with automatic invalidation when source data changes.
\nYes. Modern semantic layers are warehouse-agnostic. You configure the connection to your warehouse (Snowflake, BigQuery, Databricks, PostgreSQL (including Supabase, Neon, and RDS), Redshift, DuckDB (including MotherDuck)) and the semantic layer generates the appropriate SQL dialect. Swap warehouses without changing your metric definitions.
\nA universal semantic layer serves every consumer from one set of definitions, regardless of what tool they use. Instead of defining metrics separately in Looker, Power BI, and your application code, you define them once and serve them everywhere. “Universal” means tool-agnostic: the semantic layer isn’t embedded in any single BI product.
\n", "date_published": "2026-03-19T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/what-is-agentic-semantic-layer", "url": "https://bonnard.dev/blog/what-is-agentic-semantic-layer", "title": "What Is an Agentic Semantic Layer?", "summary": "An agentic semantic layer is a metrics layer built for AI agents: business logic defined once, exposed via MCP or API, queried as governed definitions.", "content_html": "An agentic semantic layer is a metadata layer between AI agents and a data warehouse that defines business metrics, enforces access control, and exposes governed query interfaces. Instead of writing raw SQL, agents query metric definitions through protocols like MCP (Model Context Protocol) or REST APIs. Every agent gets the same answer because the business logic is defined once, not interpreted per query.
\nThe “agentic” distinction matters. Traditional semantic layers were built for BI dashboards and human analysts. An agentic semantic layer is built for programmatic consumers: LLMs, AI agents, SDKs, and applications. The interface, security model, and deployment patterns are different.
\nAI agents are becoming a primary interface to data. Executives ask Claude for quarterly numbers. Product managers ask Cursor for usage metrics. Customer success teams ask chatbots for account health scores. The agent is the new dashboard.
\nBut most data infrastructure wasn’t built for this. Two problems dominate.
\nThe default approach: give an agent access to your warehouse and let it write SQL. It works in demos. In production, three failure modes show up every time.
\nInconsistent answers. Ask Claude “What was Q1 revenue?” It writes a query summing amount from orders where created_at falls in Q1. Reasonable. Ask GPT the same question. It filters on status = 'completed' first, then sums. Different number. Also reasonable. Neither agent knows that your finance team excludes refunds and trial conversions. That logic lives in a Notion doc that got updated six months ago. The agents don’t have access to it. They generate plausible SQL from column names and return plausible numbers that don’t match anything your team reports.
This isn’t a model quality problem. It’s a context problem. The agent sees schema, not semantics. Better models produce better-looking SQL that’s still wrong in the same ways.
\nNo access control. You’re building a B2B product. Customer A asks your agent a question. The agent writes SQL against the warehouse. Nothing in the text-to-SQL pipeline enforces that Customer A only sees Customer A’s data. You can patch this: add tenant filters to prompts, write middleware that rewrites queries, build a validation layer. Each patch is a new surface for bugs. One missed filter is a data leak in production.
\nNo audit trail. When your CFO asks “where did this number come from?”, the answer is “an LLM generated some SQL.” You can’t trace which metric definition was used because there wasn’t one. You can’t reproduce the result because the prompt context has changed. You can’t prove the number was correct because correctness wasn’t defined.
\nTraditional semantic layers solve the consistency problem for dashboards. Looker’s LookML, Tableau’s semantic model, Power BI’s DAX measures. They define metrics once and serve them to BI consumers. That’s genuinely useful.
\nBut they were designed for a world where a human browses a catalog, selects metrics, and views a dashboard. That interaction model doesn’t translate to AI agents.
\nAgents don’t browse catalogs. They call tools at runtime. They need programmatic discovery (what metrics exist?), programmatic querying (give me revenue by region for Q1), and programmatic access control (this agent represents Tenant X and can only see Tenant X’s data). They need this over a standardized protocol, not a proprietary query language embedded in a BI tool.
\nA BI-embedded semantic layer can’t serve an MCP client. It can’t issue publishable keys per tenant. It can’t serve a React SDK, a TypeScript SDK, and a markdown dashboard from the same definitions. The interface is wrong.
\nThat’s what an agentic semantic layer changes.
\n| \n | Traditional semantic layer | \nAgentic semantic layer | \n
|---|---|---|
| Primary consumer | \nBI dashboards, analysts | \nAI agents, LLMs, applications | \n
| Interface | \nSQL, proprietary query language (LookML, DAX) | \nMCP, REST API, SDK | \n
| Discovery | \nHuman browses a catalog in a GUI | \nAgent calls explore_schema at runtime | \n
| Multi-tenancy | \nOften manual or absent | \nPer-query enforcement, publishable keys per tenant | \n
| Access control | \nDashboard-level or role-based | \nRow-level, per-consumer, structural | \n
| Query volume | \nDozens of dashboard refreshes per hour | \nHundreds of agent queries per minute | \n
| Caching | \nDashboard-level refresh | \nPre-aggregation with automatic invalidation | \n
| Deployment | \nGUI-configured, click-ops | \nYAML in Git, CLI-driven, CI/CD | \n
| Schema management | \nGUI editor or proprietary file format | \nVersion-controlled code, PR reviews | \n
The core shift: an agentic semantic layer treats programmatic access as the primary use case, not an afterthought. MCP support, multi-tenant keys, and row-level security aren’t add-ons. They’re the foundation.
\nAn agentic semantic layer needs five capabilities to work in production. Missing any one of them and you’ll end up rebuilding it later.
\nMetrics defined in YAML or a similar declarative format that both humans and machines can read. Not trapped in a GUI. Not embedded in a proprietary tool.
\ncubes:\n - name: orders\n sql_table: public.orders\n measures:\n - name: total_revenue\n sql: \"CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END\"\n type: sum\n description: \"Total revenue excluding refunds and trials\"\n - name: order_count\n type: count\n dimensions:\n - name: status\n sql: status\n type: string\n - name: category\n sql: category\n type: string\n - name: created_at\n sql: created_at\n type: timetotal_revenue is now a governed definition with a description the agent can read. Deploy this schema and any MCP-compatible agent (Claude, Cursor, or any client supporting the protocol) can discover and query these metrics at runtime.
The description field matters more than it looks. When an agent calls explore_schema, descriptions are what it uses to decide which metric answers the user’s question. Good descriptions are the difference between an agent that picks the right metric and one that guesses.
Agents need a standardized way to find out what metrics exist and query them. This is what MCP (Model Context Protocol) provides.
\nThe agent calls explore_schema to see available cubes, measures, and dimensions. It reads descriptions to understand what each metric represents. Then it calls query with the right measures, dimensions, and filters. It never writes SQL. The semantic layer handles query generation, execution, caching, and access control.
Agent: explore_schema → \"orders cube has total_revenue, order_count, status, category, created_at\"\nAgent: query(measures: [total_revenue], dimensions: [status], filters: [{created_at: last 90 days}])\nSemantic layer: generates SQL, executes against warehouse, returns structured resultThis is fundamentally different from text-to-SQL. The agent isn’t interpreting column names. It’s selecting from governed definitions. The query isn’t generated by the LLM. It’s generated by the semantic layer’s query engine, which knows how to write correct SQL for your specific warehouse dialect.
\nFive tools make this work:
\nexplore_schema: Discover available cubes, measures, and dimensions with descriptionsquery: Fetch aggregated data using governed metric definitionssql_query: Run queries for edge cases that need custom SQL (still governed by access controls)describe_field: Get detailed metadata about a specific measure or dimensionvisualize: Render charts directly in the conversation from query resultsIf you’re building a B2B product, every agent query needs to be scoped to a specific tenant. This can’t be a prompt-level instruction (“only show data for customer X”). It needs to be structural: impossible to bypass regardless of what the agent does.
\n security_context:\n - name: tenant_filter\n sql: \"{SECURITY_CONTEXT.tenant_id} = customer_id\"Every query for a given tenant automatically includes this filter. The consumer can’t skip it. The agent can’t override it. Generate a publishable key per tenant, and that key carries the security context. The agent authenticates with the key and every query is automatically scoped.
\nThis is how you ship AI-powered analytics to B2B customers without building a custom access control layer. The semantic layer handles isolation. You handle the product.
\nAI agents make more queries than humans. A human refreshes a dashboard once. An agent might make 10 queries to answer one question: exploring the schema, trying different dimensions, following up on anomalies.
\nPre-aggregation handles this. Define which metric combinations to pre-compute:
\n pre_aggregations:\n - name: daily_revenue\n measures:\n - total_revenue\n - order_count\n dimensions:\n - status\n - category\n time_dimension: created_at\n granularity: day\n refresh_key:\n every: 1 hourThe semantic layer builds and maintains these rollups. Hot queries hit the cache (single-digit milliseconds). Cold queries fall through to the warehouse. Without this, agent workloads can overwhelm your warehouse, especially when multiple customers’ agents are querying simultaneously.
\nPre-aggregation isn’t a performance optimization. At agent scale, it’s a requirement.
\nMetric definitions should live in Git. Changes should go through pull requests. Rollbacks should be git revert.
This isn’t just good engineering practice. It’s how you maintain trust in an agentic system. When someone asks “why did the revenue number change?”, the answer is a Git commit, not “someone clicked something in the admin UI.” When a definition is wrong, you revert it and every consumer immediately gets the corrected version. No agent retrained. No dashboard patched. One diff in your schema repo.
\ngit diff HEAD~1 schema/orders.yml # see what changed\ngit revert abc123 # undo a bad metric definition\n# redeploy your semantic layer, and every consumer gets the fixDifferent teams interact with the agentic semantic layer differently. The common thread: everyone benefits from one source of truth for metric definitions.
\nData engineers and analytics engineers define the metrics. They write the YAML, review changes in PRs, and manage pre-aggregation strategies. The agentic semantic layer gives them a single place to define business logic instead of maintaining it across dashboards, notebooks, and custom API endpoints.
\nEngineering leads and product teams consume the metrics. They connect AI agents via MCP, build features on the REST API, and let agents chart query results in the conversation. The semantic layer means they don’t need the data team to build a custom endpoint for every new feature.
\nData leaders govern the metrics. They ensure definitions are correct, access controls are appropriate, and audit trails are maintained. The semantic layer centralizes governance instead of distributing it across tools.
\nCustomers (in B2B products) query their own data. Through embedded dashboards in your product, through AI agents connected via publishable keys, or through APIs. The semantic layer ensures they see only their data, with the same metric definitions your internal teams use.
\nAn agentic semantic layer doesn’t replace your existing infrastructure. It sits on top of it.
\n[Data Sources] → [Ingestion (Fivetran, Airbyte)] → [Warehouse (Snowflake, BigQuery)]\n ↓\n [dbt transformations]\n ↓\n [Agentic Semantic Layer]\n ↙ ↓ ↘\n [MCP Agents] [React SDK] [REST API]\n [Dashboards] [TypeScript SDK]Your ingestion pipeline feeds raw data into the warehouse. dbt transforms it into clean tables. The agentic semantic layer defines business metrics on those tables and serves them to every consumer through the appropriate interface.
\nThe semantic layer connects to your warehouse (Snowflake, BigQuery, Databricks, PostgreSQL (including Supabase, Neon, and RDS), Redshift, DuckDB (including MotherDuck)) and generates the appropriate SQL dialect. Swap warehouses without changing your metric definitions or consumer integrations.
\nThis is the key architectural property: the semantic layer decouples metric definitions from both the warehouse and the consumer. Change your warehouse and consumers don’t notice. Add a new consumer and the warehouse doesn’t change. The semantic layer is the stable interface between infrastructure and applications.
\n| Tool | \nAgent support | \nMulti-tenancy | \nPre-aggregation | \nOpen source | \nPrimary use case | \n
|---|---|---|---|---|---|
| Cube | \nREST API (no MCP) | \nManual | \nYes (battle-tested) | \nYes | \nHeadless BI, API-first analytics | \n
| dbt MetricFlow | \nNone | \nNone | \nNone | \nYes | \nMetric documentation in dbt | \n
| Looker (LookML) | \nNone | \nManual | \nLimited | \nNo | \nEnterprise dashboard BI | \n
| AtScale | \nPartial | \nEnterprise | \nVirtual caching | \nNo | \nEnterprise BI compatibility | \n
| ThoughtSpot | \nProprietary (“Spotter”) | \nEnterprise | \nProprietary | \nNo | \nAI-powered BI platform | \n
| Bonnard | \nMCP visualize tool | \nVia your runSql | \nVia your warehouse | \nYes | \nCharts agent query results in Claude/ChatGPT | \n
The right choice depends on whether AI agents are your primary consumer or a secondary integration. If agents are an afterthought, most semantic layers can be retrofitted with API access. If agents are the primary interface, you need a layer designed for programmatic consumers from the ground up.
\nAn agentic semantic layer gives the agent governed metrics to query. The last mile is what the agent shows the user: not a wall of numbers, a chart in the conversation. That’s what @bonnard/mcp-charts adds, a visualize tool you register on your MCP server in a few lines.
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\n// your data, your connection. Bonnard never touches the database\naddCharts(server, { runSql });The agent calls visualize with a query, your runSql returns the rows, and Bonnard infers the chart from the typed result, then renders an interactive widget in Claude or ChatGPT. Native adapters ship for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or pass your own runSql. It renders line, bar, area, pie, scatter, funnel, waterfall, and table.
For the full walkthrough, see MCP Charts. For the design behind an agent-friendly chart tool, see How Bonnard Builds Agent-Friendly MCPs. For a broader look at semantic layers beyond the agentic use case, see What Is a Semantic Layer?.
\nRepo: github.com/bonnard-data/mcp-charts.
\nA semantic layer is a translation layer between raw data and the people or tools that query it. It defines what business terms like “revenue” or “active user” mean in terms of actual database columns and calculations. Instead of every consumer writing its own SQL, they all reference the same definition. See What Is a Semantic Layer? for the full guide.
\nThree things: programmatic discovery (agents find metrics via API, not a GUI catalog), programmatic querying (agents call tools, not SQL), and structural multi-tenancy (access control enforced per query, not per dashboard). A traditional semantic layer might have an API, but an agentic one is designed for agents as the primary consumer.
\nRAG (Retrieval-Augmented Generation) feeds unstructured documents to an LLM for context. An agentic semantic layer provides structured metric definitions for data queries. RAG answers “What does our refund policy say?” A semantic layer answers “What was Q1 revenue?” They solve different problems and are often used together: RAG for knowledge, semantic layer for data.
\nText-to-SQL lets an agent generate arbitrary SQL from natural language. The agent interprets column names and guesses business logic. An agentic semantic layer defines metrics once and lets agents query those definitions. The difference: text-to-SQL produces plausible answers. A semantic layer produces correct, governed, auditable answers. See text-to-SQL for more on why the raw approach breaks in production.
\ndbt defines transformations: how raw data becomes clean tables. An agentic semantic layer defines metrics: what “revenue” means on top of those tables, and serves them to agents with caching and access control. They’re complementary. dbt gets data into shape. The semantic layer defines the business logic on top and serves it. Most agentic semantic layers can import dbt models directly.
\nMCP (Model Context Protocol) is a standard protocol for connecting AI agents to external tools and data sources. It defines how agents discover available tools, call them, and receive results. For an agentic semantic layer, MCP is the interface that lets any compatible agent (Claude, Cursor, Claude Code, and others) discover and query your metrics without custom integration code.
\nYes. A semantic layer with MCP support works with any MCP-compatible client. For other agents, REST APIs and SDKs provide model-agnostic access. The semantic layer sits between the agent and the warehouse, not inside the model. It doesn’t matter whether the agent runs Claude, GPT, Gemini, or an open-source model.
\nWith pre-aggregation, queries get faster, not slower. The semantic layer caches rollups so agents query pre-computed results instead of running full aggregations on every request. Hot queries resolve in single-digit milliseconds. Without pre-aggregation, agent-scale query volumes (hundreds of queries per minute across multiple tenants) will overwhelm most warehouses.
\nIt eliminates the primary source of data hallucinations: ad-hoc SQL generation. The agent never writes SQL. It selects from governed metric definitions and the semantic layer generates correct SQL. The agent can still hallucinate its interpretation of the results (that’s a model problem), but the underlying data is always correct and traceable to a versioned definition.
\n", "date_published": "2026-03-16T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/why-ai-agents-need-semantic-layer", "url": "https://bonnard.dev/blog/why-ai-agents-need-semantic-layer", "title": "Why Your AI Agents Need a Semantic Layer", "summary": "Why AI agents need a semantic layer: raw SQL produces inconsistent, ungoverned results. What goes wrong without one, and how governed metrics change it.", "content_html": "Give an AI agent access to your data warehouse and it will write SQL. It might even write good SQL. But ask two agents the same revenue question and you’ll get two different numbers. Neither matches finance’s report. That’s the core problem: text-to-SQL gives agents access to data, not understanding of it.
\nA semantic layer for AI agents fixes this by putting a governed metrics layer between the agent and the warehouse. The agent queries defined metrics instead of raw tables. Every consumer, whether it’s an AI agent, a dashboard, or an API, gets the same answer because the calculation is fixed, not interpreted per query.
\nThis isn’t a new idea. Semantic layers have existed in BI for decades. What’s new is that AI agents make the problem worse and the solution more urgent.
\nThree failure modes show up in production. All of them trace back to the same root cause: the agent interprets business logic on every query instead of referencing a shared definition.
\nAsk Claude “What was Q1 revenue?” through text-to-SQL. It writes a query summing amount from orders where created_at is between January 1 and March 31. Reasonable.
Ask GPT the same question. It filters on status = 'completed' first, then sums. Different number. Also reasonable.
Neither agent knows that your finance team excludes refunds and trial conversions from revenue. That logic lives in a Notion doc that got updated six months ago. The agents don’t have access to it. They generate plausible SQL from column names and return plausible numbers that don’t match anything your team reports.
\nThis isn’t a model quality problem. It’s a context problem. The agent sees schema, not semantics.
\nYou’re building a B2B product. Customer A asks your agent a question. The agent writes SQL against the warehouse. Nothing in the text-to-SQL pipeline enforces that Customer A only sees Customer A’s data.
\nYou can patch this. Add tenant filters to prompts. Write middleware that rewrites queries. Build a validation layer. Each patch is a new surface for bugs. One missed filter and you’ve got a data leak in production.
\nRBAC needs to be structural, not bolted on. It should be impossible for an agent to return data outside its authorized scope, regardless of what SQL it generates.
\nWhen your CFO asks “where did this number come from?”, the answer is “an LLM generated some SQL.” That’s not an audit trail. You can’t trace which metric definition was used because there wasn’t one. You can’t reproduce the result because the prompt context has changed. You can’t prove the number was correct because correctness wasn’t defined.
\nMetric governance requires a fixed, versioned definition that every consumer references. Without it, every query is an ad hoc interpretation of raw data.
\nA semantic layer is a metadata layer between your data warehouse and every data consumer. It defines business metrics, relationships between tables, and access rules in one place. Consumers query metric definitions instead of raw tables.
\nFor AI agents specifically, the semantic layer:
\nSUM(amount) WHERE status != 'refunded' AND type != 'trial'. The agent never writes this SQL itself.The term “agentic semantic layer” describes a semantic layer built for this use case: agent-native interfaces (MCP, tool-use APIs), multi-tenant by default, designed for programmatic access rather than human-driven BI.
\nDefine your metrics in YAML. Version them in Git. Review changes in pull requests. This is the same workflow your engineering team uses for application code, applied to data definitions.
\ncubes:\n - name: orders\n sql_table: public.orders\n measures:\n - name: total_revenue\n sql: \"CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END\"\n type: sum\n - name: order_count\n type: count\n dimensions:\n - name: status\n sql: status\n type: string\n - name: created_at\n sql: created_at\n type: time\n - name: customer_id\n sql: customer_id\n type: stringtotal_revenue isn’t a column. It’s a calculation with your business rules baked in. When finance decides to exclude a new edge case, one diff updates the definition for every consumer. No agent retrained. No dashboard patched. No Slack thread asking “which number is right.”
Expose this to AI agents over MCP and the agent discovers available metrics at runtime. It calls a discovery tool to see what metrics exist, then a query tool to fetch data. It never generates SQL. It never interprets column names. It queries governed definitions.
\nThe next step is what the agent shows the user. A governed query returns rows; the user usually wants a chart. Leaving the model to draw HTML puts the most important part of the answer in its hands to improvise. A dedicated tool fixes that. @bonnard/mcp-charts adds a visualize tool to your MCP server in a few lines:
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\n// your data, your connection. Bonnard never touches the database\naddCharts(server, { runSql });The agent calls visualize with a query, your runSql returns the rows, and Bonnard infers the chart from the typed result, then renders an interactive widget in Claude or ChatGPT. The chart comes from your query result, not from tokens the model invents. Same data, same chart, every time.
For the full setup walkthrough, see How to Connect an AI Agent to Your Data Warehouse and the MCP Charts guide.
\nNot every semantic layer works well with AI agents. Most were built for BI tools and retrofitted. The difference matters in production.
\n| Capability | \nTraditional BI semantic layer | \nAgentic semantic layer | \n
|---|---|---|
| Primary consumer | \nDashboards, analysts | \nAI agents, LLMs, applications | \n
| Interface | \nSQL or proprietary query language | \nMCP, REST API, SDK | \n
| Multi-tenancy | \nAfterthought or manual | \nBuilt-in, per-query enforcement | \n
| Access control | \nDashboard-level | \nRow-level, per-consumer | \n
| Discovery | \nHuman browses catalog | \nAgent calls explore_schema at runtime | \n
| Caching | \nCube-level | \nPre-aggregation with automatic invalidation | \n
| Deployment | \nUI-driven | \nCLI, Git, CI/CD | \n
| Schema management | \nGUI editor | \nYAML in version control | \n
The core difference: an agentic semantic layer treats programmatic access as the default, not a secondary integration. MCP support, multi-tenant keys, and row-level security aren’t add-ons. They’re the foundation.
\nIf you’re choosing a semantic layer for AI agent use cases, here’s what matters:
\nMCP or tool-use support. Your agents need a standardized way to discover metrics and query them. MCP (Model Context Protocol) is the emerging standard. Without it, you’re writing custom integration code for every agent.
\nMulti-tenancy. If you’re building a B2B product, every agent query needs to be scoped to a specific tenant. This should be structural, not a prompt injection.
\nRow-level security. Beyond tenant scoping, you need fine-grained access control. Marketing agents see marketing data. Finance agents see finance data. Defined in the schema, enforced on every query.
\nPre-aggregation. AI agents make more queries than humans. Sub-second response times require cached rollups, not full table scans on every request. Look for configurable pre-aggregation with automatic cache invalidation.
\nWarehouse coverage. Your semantic layer needs to support your warehouse. At minimum: Snowflake, BigQuery, Databricks, PostgreSQL (including Supabase, Neon, and RDS). Bonus: DuckDB (including MotherDuck), Redshift.
\nSchema-as-code. Metric definitions should live in version control. Changes should go through pull requests. Rollbacks should be git revert, not clicking through a UI.
Several tools in this space: Cube pioneered the open-source semantic layer. AtScale and dbt offer semantic layer capabilities for different stacks. The right choice depends on your stack, your use case, and whether you need the semantic layer to serve AI agents as its primary consumer or as a secondary integration.
\nOnce the agent can query governed metrics, give it a way to chart the result. @bonnard/mcp-charts adds a visualize tool to your MCP server that renders interactive charts in any MCP Apps client from your query results, with no frontend code.
The a16z team wrote recently that data agents are “essentially useless without the right context.” They’re right. But context isn’t a feature you add later. It’s the layer you build on.
\nThe companies shipping agentic analytics today are the ones that defined their metrics before connecting their agents. The ones struggling are the ones that gave agents raw warehouse access and are now debugging why different tools return different numbers.
\nA semantic layer isn’t optional infrastructure for AI agents. It’s the control plane that makes everything downstream trustworthy.
\ndbt defines transformations: how raw data becomes clean tables. A semantic layer defines metrics: how clean tables become business numbers. They’re complementary. dbt gets your data into the right shape. The semantic layer defines what “revenue” means on top of that shape. Many semantic layers can import dbt models directly.
\nRAG (Retrieval-Augmented Generation) feeds documents to an LLM for context. A semantic layer feeds governed metric definitions to an agent for data queries. RAG is for unstructured knowledge (“What does our refund policy say?”). A semantic layer is for structured data (“What was Q1 revenue?”). You likely need both, but they solve different problems.
\nYes. A semantic layer with MCP support works with any MCP-compatible client: Claude Desktop, Cursor, Claude Code, and others. For non-MCP agents, most semantic layers expose REST APIs or SDKs. The semantic layer is model-agnostic because it sits between the agent and the warehouse, not inside the model.
\nRead-only access prevents writes but doesn’t prevent incorrect reads. The agent still interprets column names, guesses JOIN conditions, and invents filter logic. A semantic layer replaces interpretation with definition. The agent queries total_revenue and gets the exact calculation your finance team agreed on, every time.
With pre-aggregation, queries typically get faster, not slower. The semantic layer caches rollups so agents query pre-computed results instead of running full aggregations on every request. Cold queries hit the warehouse directly. Hot queries resolve in single-digit milliseconds.
\n", "date_published": "2026-03-16T00:00:00.000Z", "date_modified": "2026-06-25T00:00:00.000Z", "authors": [ { "name": "Bonnard Team" } ] }, { "id": "https://bonnard.dev/blog/connect-ai-agent-data-warehouse", "url": "https://bonnard.dev/blog/connect-ai-agent-data-warehouse", "title": "How to Connect an AI Agent to Your Data Warehouse", "summary": "Connect an AI agent to your data warehouse: expose governed metrics over MCP, query without raw SQL, and chart the result in Claude or ChatGPT.", "content_html": "Most teams connecting AI agents to their data warehouse start with text-to-SQL. The agent generates SQL from natural language, runs it against the warehouse, and returns results. It works until it doesn’t: hallucinated JOINs, inconsistent aggregations, no access control, no audit trail.
\nThere’s a better approach. Define your business metrics in a semantic layer, expose them via MCP (Model Context Protocol), and let any AI agent query governed definitions instead of raw tables. Then add one tool so the agent can chart the result in Claude or ChatGPT. This tutorial shows how to set it up in under 30 minutes.
\nThe agent sees column names but not business logic. It doesn’t know that your company excludes refunds from revenue. It doesn’t know that status = 'completed' means something different in orders than in subscriptions. It doesn’t know that marketing and finance defined “active user” differently three years ago and never reconciled.
So the agent writes plausible SQL and returns plausible numbers. Ask the same question twice with different phrasing and you get different answers. Ask two different agents and you get two different numbers. Neither matches the number your finance team reports.
\nBeyond consistency, there’s no row-level security. No multi-tenancy. No audit trail showing which agent queried what, when, and for whom. In production, with real customers, that’s a non-starter.
\nText-to-SQL gives you speed. It doesn’t give you trust.
\nInstead of letting agents write arbitrary SQL, define your metrics once in YAML: cubes, measures, dimensions, access rules. Then expose those definitions via MCP so agents query governed metrics, not raw tables.
\nThe difference: every agent gets the same answer because the metric definition is fixed. total_revenue isn’t a column the agent interprets. It’s a pre-defined calculation with agreed-upon filters and aggregations. When your finance team updates the revenue definition to exclude trial conversions, that change propagates to every consumer instantly. No agent retrained. No dashboard patched. One diff in your schema repo.
This architecture also decouples the query interface from the warehouse dialect. Swap BigQuery for Snowflake and your agents don’t notice. The semantic layer abstracts the SQL generation, so consumers stay stable while infrastructure evolves underneath.
\n| Approach | \nGovernance | \nConsistency | \nMulti-tenant | \nAccess Control | \nSetup Time | \n
|---|---|---|---|---|---|
| Direct SQL | \nNone | \nVaries by query | \nManual | \nManual | \nMinutes | \n
| Text-to-SQL | \nNone | \nVaries by prompt | \nManual | \nManual | \nHours | \n
| Semantic Layer via MCP | \nFull | \nGuaranteed | \nBuilt-in | \nRow-level | \nUnder 30 min | \n
The semantic layer is the control plane between your warehouse and every consumer, whether that’s a human analyst, a React component, or an AI agent.
\nStand up a semantic layer that connects to your warehouse and exposes metrics over MCP. Open-source engines like Cube connect to BigQuery, Snowflake, Redshift, Databricks, PostgreSQL (including Supabase, Neon, and RDS), and DuckDB (including MotherDuck). You configure your warehouse connection in a config file or pass credentials via environment variables.
\nIf you want to explore without connecting your own warehouse, point the semantic layer at a sample PostgreSQL database with orders, customers, and products data so you can follow along with the rest of this tutorial. A few thousand rows across three tables is enough to test aggregations, filters, and multi-dimensional queries.
\nCreate a cube that maps to a table in your warehouse and defines the metrics your agents will query.
\ncubes:\n - name: orders\n sql_table: public.orders\n measures:\n - name: total_revenue\n sql: amount\n type: sum\n - name: count\n type: count\n dimensions:\n - name: status\n sql: status\n type: string\n - name: created_at\n sql: created_at\n type: timeMeasures are the numbers you aggregate: sums, counts, averages. Dimensions are the columns you filter and group by: status, date, category. One definition. Every tool, dashboard, and AI agent that queries total_revenue gets the same number.
You can also define pre_aggregations in the same file to cache expensive computations. For example, a daily rollup of total_revenue by status can cut query times from seconds to single-digit milliseconds. The semantic layer rebuilds these rollups on a configurable schedule and invalidates stale caches automatically.
Schemas are version-controlled alongside your application code. Review metric changes in pull requests. Roll back a bad definition with git revert. Your data contracts get the same CI/CD workflow as your product.
To control what’s exposed to specific consumers, define a view:
\nviews:\n - name: order_metrics\n cubes:\n - join_path: orders\n includes:\n - total_revenue\n - count\n - status\n - created_atViews act as a curated interface. Your agents see order_metrics with four fields instead of navigating the full schema.
Deploy your schema so the semantic layer serves it over an MCP endpoint, then add the MCP server URL to your client’s config:
\n{\n \"mcpServers\": {\n \"semantic-layer\": {\n \"type\": \"http\",\n \"url\": \"https://your-semantic-layer.example.com/mcp\"\n }\n }\n}Paste this into your MCP client’s config file and restart. For Claude Desktop, that’s ~/Library/Application Support/Claude/claude_desktop_config.json. For Cursor, it’s .cursor/mcp.json in your project root. Claude Code reads from .mcp.json in your project directory.
The MCP server handles tool discovery, schema introspection, and query execution over HTTP. Your agent sees available metrics the same way it sees any other MCP tool. No custom integration code required.
\nFor customer-facing use cases, scope each connection to a specific tenant’s data with row-level security defined in the schema, so a customer’s agent sees only that customer’s rows.
\nOnce connected, your AI agent can discover and query your metrics using natural language. Behind the scenes, the agent calls MCP tools.
\nAsk: “What’s our total revenue this quarter?”
\nThe agent calls explore_schema to discover available metrics, then calls query with the right measures and time filters. The response comes back as structured data, not raw SQL results.
Ask: “Break down order count by status for the last 30 days.”
\nSame flow. The agent uses query with count as the measure, status as the dimension, and a date filter on created_at.
A semantic layer typically exposes a handful of MCP tools:
\nexplore_schema: Discover available cubes, measures, and dimensionsquery: Fetch aggregated data using governed metric definitionssql_query: Run queries for cases that need custom SQL (still governed by access controls)describe_field: Get metadata about a specific measure or dimensionEvery query runs through the semantic layer. The agent never touches raw tables. Read more about the architecture in our agentic analytics guide.
\nA governed query returns rows. The agent usually needs to show the user a chart, not a wall of numbers. Leaving the model to draw HTML puts the most important part of the answer in its hands to improvise.
\n@bonnard/mcp-charts fixes that. It adds a visualize tool to your MCP server in a few lines:
npm install @bonnard/mcp-chartsimport { addCharts } from \"@bonnard/mcp-charts\";\n\n// your data, your connection. Bonnard never touches the database\naddCharts(server, { runSql });The agent calls visualize with a query, your runSql returns the rows, and Bonnard infers the chart from the typed result, then renders an interactive widget in Claude or ChatGPT. It renders line, bar, area, pie, scatter, funnel, waterfall, and table, with bar variants for stacked, grouped, horizontal, and 100% stacked. The chart comes from your query result, not from tokens the model invents. Same data, same chart, every time. Full walkthrough: MCP Charts.
You started with a warehouse and an AI agent that writes its own SQL. Now you have governed metrics defined in YAML, exposed via MCP, queryable from any AI tool your team or customers use. Setup took under 30 minutes.
\nThe shift from raw SQL to governed metrics pays off immediately: consistent numbers across every consumer, row-level access control per tenant, and a full audit trail for every query. As your team adds more agents and surfaces, the semantic layer scales with you. No duplicate logic. No drift between dashboards and AI answers.
\nGive the agent a way to chart what it queries: npm install @bonnard/mcp-charts, call addCharts(server, { runSql }), and interactive charts render in any MCP Apps client. The repo is on GitHub. Read the MCP Charts guide to go deeper.
visualize tool so agents chart query results in any MCP Apps clientNo. A semantic layer with MCP support works with any MCP-compatible AI agent out of the box. Your agent discovers available metrics through the MCP protocol at runtime. There is no fine-tuning, prompt engineering, or model modification required.
\nA semantic layer connects to BigQuery, Snowflake, Redshift, Databricks, PostgreSQL (including Supabase, Neon, and RDS), and DuckDB (including MotherDuck). For charting the agent’s results, @bonnard/mcp-charts ships native adapters for Postgres, BigQuery, Snowflake, Databricks, and DuckDB, or you pass your own runSql. Bonnard never touches your database.
Text-to-SQL lets an AI agent generate arbitrary SQL from natural language. It has no governance, no consistency guarantees, and no access control. A semantic layer defines metrics once in YAML and exposes them as governed APIs. Every consumer gets the same answer because the calculation is fixed, not interpreted per query. And when the agent charts the result, @bonnard/mcp-charts renders from the query result, not from tokens the model invents.
Install @bonnard/mcp-charts and call addCharts(server, { runSql }) on your MCP server. That registers a visualize tool. The agent calls it with a query, your callback returns the rows, and an interactive chart renders in Claude or ChatGPT. No frontend code.
Under 30 minutes for most teams. Stand up a semantic layer, connect your warehouse, define a few metrics in YAML, and deploy it over MCP. Add charts with npm install @bonnard/mcp-charts and one addCharts call. The tutorial above walks through each step with working code examples.