Dashboards Answer Known Questions. MCP Answers the Rest

We still get asked a lot of questions about analytics. How customizable are the dashboards? Can we build our own reports? Can we add new charts? How much flexibility do we have to analyze the data in different ways? Increasingly, however, some of the same companies are asking another question: do you have an MCP (Model Context Protocol) server?

At first glance, these seem like two separate requirements. One is about analytics, while the other is about how LLMs (large language models) interact with enterprise software. I think they are actually closely connected, and potentially represent different generations of thinking about pricing analytics and enterprise analytics. Dashboards answer the questions you know you’ll ask. AI agents, connected to your systems through MCP, answer the ones you didn’t see coming. 

Key takeaways

• Dashboards answer the questions you know you’ll ask. AI agents connected through MCP answer the ones you didn’t see coming.
• Generation 1 pricing analytics built dashboards around the questions teams expected to ask. They work best for recurring questions, while new questions often fall outside them.
• Generation 2 uses self-service BI, LLMs and AI agents to build the same dashboards faster, but someone still has to predict the question and interpret the chart.
• Generation 3 starts with the business question. An AI agent connected through MCP investigates it and returns an answer, giving teams a faster route to answers for the questions no dashboard was built for.
• The key question for enterprise software expands from “how good are your analytics?” to “how good are your analytics, and how easily can my organization interrogate everything your platform knows?”

Generation 1: Build me the analytics

For years, the standard approach to enterprise analytics has been relatively straightforward. We try to understand what people need to know, build reports and dashboards that answer those questions, and give users the ability to filter, drill down and explore the results.

A few years ago, I worked with a very smart colleague who changed the way I thought about this. She was redesigning the analytics for a pricing solution and, rather than starting with the available data or debating which charts should go on the dashboard, she started by asking what business questions users actually needed to answer. What does a pricing manager repeatedly need to understand? Which products aren’t performing as expected? Where are we losing margin? Where are we out of position against competitors? What happened after the last price change?

Once those common questions had been identified, they drove the design of the analytics. It sounds obvious, but it is an important distinction. Don’t create analytics simply because you have data available; create analytics because somebody needs to answer a business question. It is a philosophy I have followed ever since, but even this better approach has a fundamental limitation: you still have to know the questions in advance.

I saw the consequences of that on another project. A large global organization had invested heavily in a new pricing platform and, as part of the implementation, considerable time and money went into creating analytics for the pricing team. If I remember correctly, they eventually had something like 60 different dashboards and reports. The logic was perfectly reasonable: identify all the questions a pricing team might regularly need to answer and create the analytics required to support them.

Around 12 to 18 months after the system went live, we looked at how many of those dashboards were being regularly used. The answer was a remarkably easy number to remember: zero.

There was nothing inherently wrong with the dashboards, and the people who had designed them had put considerable thought into what the business might need. The problem was the underlying model. We were trying to anticipate future questions and then creating permanent analytics to answer them. In reality, business questions change. Priorities change, market conditions change and, very often, the question someone needs answered today isn’t one that anybody thought to build a dashboard for 18 months ago. The dashboards weren’t the problem. The questions had simply moved on.

Generation 2: Help me build the analytics

Technology has progressively made this model more flexible. Self-service BI gave business users more control, configurable enterprise applications allowed them to create their own views, and now LLMs and AI agents are taking this much further. Instead of waiting for an analyst, consultant or IT team to build something, a user can increasingly describe the analysis they want and have the technology create it for them.

A pricing manager might ask for a chart showing margin development by category over the last 12 weeks compared with competitor price position. An LLM or agent can potentially create that analysis in seconds. This is genuinely useful because it removes one of the biggest problems with traditional analytics: the time and cost involved in creating a report that might only ever be used once or twice.

However, there is another way of looking at this. We have used 2026 technology to make a 2016 process faster.

The underlying process hasn’t fundamentally changed. The user still has to decide which analysis they need, determine what data they should look at and ask the technology to create the appropriate chart. They then have to interpret what the chart is telling them and decide what to do next. We have dramatically reduced the cost and time involved in producing analytics, but if the result is simply that we can create more dashboards more quickly, have we really transformed the way decisions are made?

This is one of the traps organizations need to be conscious of as they adopt LLMs. It is very easy to take an existing process, add an LLM or an agent, make that process considerably faster and call it transformation. The productivity improvement may be real, but sometimes all we have done is automate the old way of working.

Generation 3: Answer my business question

The more interesting opportunity appears when we go back to the lesson I learned years ago: start with the business question. The difference today is that we no longer necessarily need to predict that question in advance or build the analytics required to answer it. This is where the questions that fall between the dashboards finally get an answer.

Imagine a pricing manager notices something unexpected and asks, “Why did our margin fall last week?” They don’t need to ask for a particular dashboard, specify which dimensions should be analyzed or determine which datasets need to be joined together. They simply describe the business problem they are trying to understand.

An AI agent, connected through MCP servers to the relevant enterprise systems, can potentially investigate that question. It might discover that most of the margin deterioration came from one category and then investigate further to find that a small group of products accounted for the majority of the decline. Those products had been repriced in response to a competitor promotion, but while the competitor had since ended its promotion, our prices had remained unchanged.

Rather than leaving the user to work out what happened across several views, the system can explain how far margin fell and how much of the decline came from those products. The analytics haven’t disappeared; they have become part of the investigation that produced the answer.

That distinction matters because we have moved from analytics to insight. The user can then continue the conversation by asking what would happen if those products returned to their previous prices, which products should actually change, or what the expected commercial impact would be. Eventually, assuming the appropriate controls and governance are in place, the next instruction could simply be to make the change. This is the idea behind agentic pricing: AI that can investigate, recommend and, within agreed guardrails, act.

The traditional process moves from data, to analytics, to human interpretation, to decision and finally to action. This approach starts with the business question and moves through investigation and insight towards a decision and action, with the technology increasingly able to support each stage. The distance between identifying a problem and doing something about it becomes much smaller.

Dashboards and questions work side by side

Dashboards remain the right tool for the questions teams ask every day. There are things businesses need to monitor continuously, whether that is revenue, margin, price position, exceptions, execution or other important KPIs. The pricing platform also remains where strategy is set, rules are managed and changes are approved. AI agents take the questions that fall outside those views. Sometimes a chart is also simply the clearest way to communicate an answer.

An AI agent investigating a margin decline might decide that a visualization showing the relationship between margin and competitor price position is useful. In that situation, it should generate one. The chart becomes supporting evidence for the answer. Instead of always asking the user what chart they would like to see, we can start by asking what they are trying to understand and allow the technology to determine the best way to answer it.

Each tool does the job it is best at: dashboards for the questions you can predict, agents for the ones you can’t.

MCP changes what we should expect from enterprise software

This is why I find it interesting that conversations about customizable analytics and MCP are happening at the same time. For years, one of the ways companies evaluated enterprise software was by asking how good its analytics were. How many reports are available? How configurable are they? Can we build our own? Can we add another dimension, create another view or build another dashboard?

Those questions still matter, and they made complete sense when the application itself had to anticipate most of the ways users would interact with its data. In an LLM-first world, perhaps an equally important question becomes: how easily can my organization interrogate everything your platform knows?

That changes what matters. Can the organization’s chosen LLM securely access the relevant data and understand the context behind it? Can it investigate what happened rather than simply retrieve a number? Can it explain why a recommendation or decision was made? Can information from the pricing platform be combined with authorized information elsewhere in the organization? Most importantly, can the technology help someone move from understanding what happened to deciding what they should do next?

This is where MCP becomes particularly interesting. The Model Context Protocol is an open standard, originally created by Anthropic and now governed by the Linux Foundation’s Agentic AI Foundation, that lets AI applications connect to external data sources and tools. MCP isn’t the analytics itself; it is part of the infrastructure that allows an LLM to reach beyond its own knowledge and interact with the systems and capabilities required to investigate a real business question. That potentially changes the role of the analytics layer within enterprise applications.

Match the question to the right tool

There is a broader lesson here that goes well beyond pricing or analytics. LLMs give organizations an opportunity to rethink how work gets done, but we will only unlock part of that value if we simply bolt an LLM onto every existing workflow. If a process previously took five days and an LLM reduces it to five minutes, that is clearly useful. But it is still worth asking a more fundamental question: why does that process exist in the first place?

Analytics provides a useful illustration of that evolution. Generation 1 gave us dashboards designed around the questions we thought people would ask. Generation 2 made those dashboards increasingly flexible and, with the arrival of LLMs and agents, dramatically faster to create. Generation 3 starts somewhere different. It starts with the business question and uses technology to determine how best to investigate and answer it. Each still has a place. What’s new is being able to choose.

In Generation 1, somebody builds the dashboard for you. In Generation 2, technology helps you build the dashboard. In Generation 3, the first question becomes: does this question need a dashboard, or an answer?

The next generation of enterprise software won’t be defined simply by whether it contains an LLM. Sometimes adding AI just makes the previous generation faster. The bigger opportunity is to use the technology to rethink how questions get answered, not just how quickly dashboards get built.

How Quicklizard approaches pricing analytics and MCP

At Quicklizard, we see dashboards and AI agents as complementary. The Quicklizard UI gives pricing teams a structured environment to monitor performance, manage strategy and make everyday pricing decisions. MCP extends that environment by allowing AI agents, including Quicklizard’s Pricing Guru or a company’s own agents, to access pricing intelligence and investigate questions that fall outside those standard workflows.

The goal isn’t to replace the pricing platform or its analytics. It’s to give teams another way to interact with the intelligence behind them, especially when the question wasn’t anticipated in advance. For a closer look at how this works, see how Quicklizard connects AI agents to pricing intelligence.

Frequently Asked Questions