Product
Dashboards, APIs, and Now MCP
Harry Yu
Every SaaS platform typically gives you two ways to analyse data: dashboards for business users to monitor trends, and APIs for data analysts to explore the data and conduct deeper analysis. The limitation is that dashboards can only answer the questions they were designed for, while API-based analysis often requires building data pipelines before you can get to the answer.
MCP, along with your AI assistant, brings together the best of both worlds. The platform keeps its important metrics clearly defined and consistently calculated, while MCP gives you the flexibility to investigate beyond them through an AI assistant, without the cost of a data analyst.
Within two months of launch, Emily MCP Server enables brands' AgentOps teams to conduct more than 4X as many investigations as they did before. The data didn't change. The way people access it did.
“
Before MCP, finding out why something failed meant going through tickets one by one. Now we query the data directly and the patterns show up on their own. We've caught errors after a playbook update that we'd otherwise have found much later, if at all. The same applies to reporting: we set the structure we want once, and the report gets generated and refined from there. It's taken a lot of manual work out of our week.
AgentOps Manager at a car-sharing operator
Per-turn Observability is the backbone of MCP
An AI assistant reasoning over MCP inherits the quality of the record underneath it. Level3AI's Observability captures every turn of that record, including the reasoning and actions behind it, not just the final reply from the AI agent. That turn-level data is what the Emily MCP Server makes available, so a metric, a trend or an investigation are all traceable back to the turns that produced it.
Completeness of data sets the ceiling on what you can investigate. Most AI agent platforms integrate with a helpdesk, so once the AI agent hands off a conversation, the subsequent messages between the customer and the human agent disappear from the platform. A good MCP server keeps that part of the record too, rather than leaving it stranded in the helpdesk.
With data this granular and complete, your AI assistant can become the best data analyst you have ever worked with.
Here is an example of a blind spot it can uncover. An AgentOps team's daily analysis focuses on two populations: tickets a human ended up handling, where the human knew something the AI didn't, and tickets the AI contained poorly, where the customer grew frustrated and left. Working through them, the assistant noticed a third group that belonged to neither. The AI had escalated. The customer had started the handover form, stopped partway, and never reached a human at all.
Both sides of the system were behaving correctly. The AI agent had recognised its limits and escalated, exactly as designed. The human agents never saw the ticket, so from their queue nothing had gone wrong. The friction sat in the gap between them, where no one was looking.
Requiring mandatory information before a handover is a common design, and most teams sense that it costs them something. You did too. What you hadn't done was measure it until the assistant put a number on it, and the number was larger than anyone had assumed.
Everyone analyses independently. Nobody argues about the number.
Open analysis has an obvious failure mode. If every team defines its own metrics, two people arrive at the same meeting with two different resolution rates and spend the first ten minutes working out who is right.
The fix is a canonical set: the metrics that matter, defined once and computed by the platform rather than reassembled by each assistant on the fly. Precomputing them means the number comes back fast, and comes back the same every time it's asked by anyone, in any session.
Definitions have to be stated rather than inferred. An assistant asked what timezone a daily metric uses will pick one, confidently, and the answer looks identical whether it guessed right or wrong. So the day boundary is written down. So is what sits in the denominator and which population a rate is measured over. Ambiguity doesn't produce an error message. It produces a plausible number.
None of this limits what anyone can investigate. The raw turn-level record stays underneath, and the questions nobody anticipated are exactly what MCP is for. What the canonical set adds is a reference point. When someone creates a new metric, they can first check whether an equivalent already exists and use the established definition instead of reinventing it, or ensure their new metric doesn't contradict something the team already reports.
This makes analytical results easier to share and trust. A CX leader can investigate why first-contact resolution dropped in a particular market without creating a definition that differs from the one in the monthly report. Everyone works from the same vocabulary, so findings can be compared, reported and acted on without anyone relitigating the arithmetic.
From analysis to action
MCP has made customer data easier to access and analyse. The next step is to let you write back to the platform through MCP.
Feedback collected as you work. Every analysis session is a test of the MCP server. The assistant hits a question no tool can answer, a figure that contradicts the portal, a definition ambiguous enough that it had to guess, a metric people keep recomputing by hand because the canonical one doesn't exist yet. Today that friction is invisible to the platform team. The user works around it and moves on. With write access, the AI assistant reports it as it happens, with the question and the calls that exposed it attached. That is how the data layer improves: not through a quarterly feedback survey, but from the accumulated record of where real analysis ran into a wall.
Suggestions tested before they are applied. Identifying what should change is the easy half. An AI assistant that reads a hundred escalated tickets will have opinions about the playbook, and some of them will be wrong in ways that are not obvious from reading. Through MCP, you can customise Eval simulations around real customer scenarios and personas, run the proposed change against them, and see whether the agent's behaviour actually improves and whether anything else broke. A suggestion that survives this is no longer a suggestion. It is a tested change.
Configuration managed as software. The final step is the one most teams underestimate. An AI agent's configuration is production software: it decides what customers are told and what actions are taken on their accounts. It deserves the same discipline: separate Development, UAT and Production environments, changes reviewed before they move between them, and a person approving what reaches customers. MCP write access belongs in the early environments, where drafting and testing happen. The release gate stays where it is. What changes is how much better-prepared a change is by the time it arrives there.
The interface you already use
Easier access alone is not enough. MCP is only as powerful as the data and controls behind it. Turn-level observability gives the AI assistant the granularity to investigate what actually happened. A complete interaction record ensures it can see the entire customer experience, including what happens after handover. A canonical metric set gives everyone the same definitions, so analysis done independently can still be compared and reported. And a path back into the platform, from draft to simulation to review to release, turns a finding into a change that has been tested before it reaches a customer.
The power of MCP is that it brings this data capability into the AI assistant, an interface you already use every day. When that interface can help you investigate, diagnose, and improve the AI agent as part of your daily workflow, managing it stops being a project and starts being a habit.
