“I Rarely Go to Your Dashboard Anymore.”

“I rarely go to your dashboard anymore.”

That is what we keep hearing from users.

The strange part is that they are not using the product less. Some are using it more. They ask an AI assistant to find the account, pull the history, update the record, and prepare the next step. The work still runs through the product. The browser tab never opens.

For a software company, that can look like lost engagement. We spent years training ourselves to watch logins, sessions, and clicks. If those numbers fall, something must be wrong.

That assumption is now dangerous.

The day you launch an MCP server may be the last day some customers regularly log into your user interface. It may also be the day your product becomes useful in far more of their work.

The text-only objection

It is easy to dismiss this change. How many people really want to live in a text-only world?

Probably not everyone. That is beside the point.

People do not need to prefer text over visual software. They only need to prefer finishing a task in the place where they already started it. If someone is planning a project with an AI assistant, leaving that conversation to open another product, find the right page, copy several fields, and return with the result feels slow.

An MCP connection lets the assistant reach the product on the user’s behalf. The user asks for the outcome. The product supplies the data or performs the approved action.

This is why MCP matters to product teams. It shortens the distance between wanting something done and getting it done.

The product is still being used

Dashboard activity used to be a decent proxy for product activity. The two are starting to separate.

Consider a customer who once logged in every morning to review new accounts. Now the customer asks an assistant for the five accounts that need attention and why. Your product still holds the records, permissions, and business rules behind the answer. It may handle more requests than it did before. Yet the customer appears less active if you only count page views.

This creates an uncomfortable possibility: a falling login rate can sit beside rising product use.

Product teams need to measure both. Dashboard sessions tell you how people use the visual interface. MCP activity tells you how often the product contributes to work done somewhere else. Neither number is complete on its own.

MCP has moved past the side-project stage

Anthropic introduced the Model Context Protocol in November 2024 as an open way for AI assistants to connect to data and software. A year later, MCP had been adopted across major AI products and was placed under the Agentic AI Foundation, part of the Linux Foundation.

The technical details matter to the people building it. Customers care about something simpler: can their assistant use your product?

That question is beginning to sit beside familiar buying questions about integrations, exports, and APIs. A missing MCP connection can mean more manual work. A poor one can make a good product seem unreliable.

Treating the MCP server as a weekend experiment is no longer enough.

Two groups of users

We are entering a split world.

One group will keep using the dashboard. They want to explore, compare, configure, and see the state of the system. Visual software is better for that work.

The other group will stay inside an AI assistant for most routine tasks. They may visit the dashboard only to connect an account, change permissions, or investigate something unusual.

Trying to force both groups through the same interface is a mistake. Build for both.

The dashboard should make complex information easy to see and control. The MCP should make common tasks easy to request and safe to complete. Both should use the same permissions and business rules. A customer should get the same answer regardless of which door they use.

Your MCP is not a copy of your API

An API is built for software developers. It often mirrors the way data is stored: accounts, contacts, invoices, events.

Users think about work instead. They want to know which customers need attention, whether an invoice is unusual, or what changed since yesterday.

If an MCP server simply exposes every API action with a new label, the AI assistant has to reconstruct your product logic from scratch. It may make too many requests, choose the wrong action, or return a technically correct answer that misses the point.

A good MCP starts with the jobs customers already do. Its names should be plain. Its instructions should explain when an action is appropriate. Its answers should include enough context to help the user decide what to do next.

This is product writing. A vague tool name is the machine-readable version of a button labeled “Submit.” A useless error is still a useless error, even when an AI assistant receives it.

Trust shows up in the small moments

People hesitate when an assistant can change business data, send a message, approve a payment, or publish something under their name. They should.

The MCP experience has to make boundaries obvious. A user should know what the assistant can see, what it can change, and which actions need approval. Administrators need a record of what happened. Removing access should be quick.

The MCP specification calls for clear user consent, control over data sharing, and care around tools that take action. Those are product requirements as much as security requirements.

Start with actions that are easy to reverse. Let users preview work before it is submitted. Ask for confirmation when the consequence is serious. Keep sensitive information out of the conversation when it does not need to be there.

Trust is built one uneventful request at a time.

Watch what users do after launch

The first version will be wrong in ways a planning meeting cannot predict.

Users will ask for the same thing using different words. An assistant will choose a tool that sounded right but was not. A response will contain too much detail, then bury the one fact the user needed. Someone will return to the dashboard because the MCP stops one step short of finishing the job.

Those moments are the roadmap.

Track the requests that succeed, the ones that need correction, and the points where users leave the assistant. Repeated workarounds often point to a missing feature. A tool that is available but rarely chosen may have a naming problem rather than a demand problem.

And talk to the users. Ask them to show you the last task they completed, starting from the first message or click. The place where the task begins is now more revealing than the page they visit most.

The dashboard has a new job

The dashboard is not going away. Its job is changing.

It is where people set up the product, manage access, inspect details, handle exceptions, and review what an agent has done. For many customers, it will become the control room rather than the workshop.

That should change the product roadmap. A team may need fewer clicks in a routine dashboard flow and better controls for permissions, history, and review. At the same time, the MCP needs the attention once reserved for the most-used screens.

We spent years polishing the dashboard because that was where users touched the product.

Ask them where they touch it now.