[← All posts](/blog)
For the last decade, the way a SaaS product delivered data to its customers was settled: you embedded a dashboard. Charts, filters, a date picker, maybe a self-serve report builder if you were ambitious. The whole category of embedded analytics exists to make that dashboard look native, load fast, and stay secure across thousands of tenants.
That model assumes the person consuming your data is a human, looking at a screen, clicking.
That assumption is breaking. Your customers are building AI agents, and those agents want to ask questions of your product’s data directly, not stare at a chart you designed for them. The interface that matters next isn’t a dashboard you render. It’s an endpoint their agent can call.
That endpoint is a customer-facing MCP server. And we think it becomes the thing SaaS products embed next.
What changed #
The Model Context Protocol (MCP) gave AI agents a standard way to reach tools and data. Instead of every application inventing its own agent integration, a product exposes an MCP server, and any MCP-capable agent (Claude, an internal copilot, a customer’s homegrown workflow) can discover what’s available and query it.
Most of the early attention went to internal MCP servers: connect your own agent to your own database, your own Slack, your own repo. Useful, but it’s a single-tenant problem. You control the data, the identity, and the blast radius.
The interesting shift is external. Your customers now expect that the products they pay for can be reached by their agents. A finance platform’s customer wants their agent to pull their own transaction history. A logistics product’s customer wants their agent to reason over their own shipments. They don’t want to export a CSV and paste it into a chat window. They want their agent to query your product, live, and get an answer that respects exactly what that customer is allowed to see.
That is a fundamentally different job than embedding a dashboard. And it’s a fundamentally harder one.
Why this is harder than it looks #
Standing up an MCP server over one database is a weekend project. Standing up one that serves your customers’ agents, safely and at scale, is not. The moment the caller is an external agent acting on behalf of one of your tenants, four problems show up at once:
Tenant isolation. Every query has to be scoped to the customer whose agent is asking. Row-level security can’t be a filter the agent is politely asked to include. It has to be enforced at the boundary, identically, every time, or one customer’s agent sees another customer’s data.
Identity propagation. The agent is acting for a specific end customer. That identity has to travel from the agent, through the MCP layer, into the query, and be trusted. Getting auth wrong here isn’t a bug; it’s a breach.
Governed answers. An agent turned loose on raw tables will invent metrics, misjoin, and confidently return numbers that don’t match what your product shows in its own UI. If your customer’s agent says revenue is one number and your dashboard says another, you have a trust problem you can’t debug after the fact. Agents need a governed semantic layer (defined metrics, one source of truth), not free-text SQL against production.
Cost, rate, and audit. Agents are tireless. They’ll issue far more queries than a human ever would, at unpredictable times. You need rate limiting, query-cost controls, and a full audit trail of every tool call and result: for debugging, for abuse detection, and for the compliance questions your enterprise customers will absolutely ask.
None of these are optional. All of them are the difference between a demo and something you’d put in front of paying customers.
The parallel to embedded analytics is exact #
If this sounds familiar, it should. Embedded analytics became a category precisely because “just show the customer a chart” turned out to hide the same hard problems: multi-tenant security, consistent metrics, performance at scale, and a native experience that didn’t leak your architecture. Teams tried to build it themselves, discovered the long tail of edge cases, and bought a platform instead. Customer-facing MCP is the same story, one layer up. The consumption surface moved from a rendered dashboard to a queryable endpoint, but the underlying requirements (isolation, governance, performance, auditability) didn’t go away. They got sharper, because now an autonomous agent is doing the asking.
Where Motley fits #
This is the layer we build at Motley. SLayer, our open-source semantic layer, lets you define your metrics, dimensions, and business context once on top of your warehouse, so every consumer sees the same governed numbers. Motley is the hosted platform on top: it runs the MCP endpoint your customers’ agents call, with per-tenant scoping, governed metrics so answers match your product’s own UI, and observability over every query.
The agent is whatever your customer is already using. Our job is to make it trustworthy on your data, so you can say yes when a customer asks “can our agent connect to your product?” without turning it into a quarter of platform engineering.
The dashboard isn’t going away. But the next thing your customers ask you to embed won’t be a chart. It’ll be an endpoint their agent can trust.
Want to see a customer-facing MCP server running on your own data? Book a demo.