MCP (Model Context Protocol) is changing how people interact with software.
Instead of opening an application, navigating through menus, and clicking buttons, users can now interact with products directly through AI assistants like ChatGPT, Claude, and Cursor.
For developers, that's exciting. You can expose your product's capabilities through an MCP server and make them accessible wherever your users already work.
But once you've shipped your MCP, a new set of questions emerges.
Who's actually using it? What are they trying to accomplish? Which use cases are becoming popular? What features are they asking for? And where are they getting stuck?
These are questions that traditional product analytics have helped answer for websites and applications.
But what happens when the user interface belongs to someone else?
MCP is becoming a new product distribution channel
Imagine you're building a CRM.
Historically, your users would log into your application to search for contacts, manage deals, or build reports.
You could measure adoption through pageviews, feature usage, funnels, and user journeys.
Now imagine you've released an MCP server.
Your customers can ask ChatGPT to find promising leads, update opportunities, or summarize their pipeline without ever opening your application.
That's a powerful new way to distribute your product.
But there's a catch.
You no longer control the entire user experience.
The conversation happens inside ChatGPT or Claude. Your MCP server receives tool calls and returns results, but it doesn't necessarily have visibility into everything surrounding those interactions.
You might know that search_contacts was called 5,000 times last week.
But that doesn't tell you whether people were prospecting, preparing for meetings, cleaning their CRM, or trying to accomplish something your product doesn't support.
Tool usage isn't the same thing as understanding product usage.
What should you actually measure?
When we started building Flowlines, we kept coming back to five questions that we believe every team running an MCP server should be able to answer.
1. Who's using your MCP?
The first question sounds simple.
How many users do you have? Are they new or returning? Which organizations are adopting your MCP? Are people accessing it through ChatGPT, Claude, Cursor, or another client?
These metrics give you a starting point for understanding adoption.
But there's an important difference between someone connecting your MCP and someone finding it useful.
A thousand installations don't necessarily mean a thousand active users.
Similarly, a handful of users generating thousands of tool calls doesn't necessarily indicate broad adoption.
Understanding usage at the user, account, and session level gives you a more meaningful picture of how your MCP is growing.
2. What are people actually trying to accomplish?
This is where things get interesting.
Let's say your MCP exposes these tools:
search_contacts, get_company, create_note, and update_deal.
Looking at tool-call metrics, you can see which tools are popular.
But several different workflows might use those same tools.
One user might be preparing for a sales meeting. Another might be qualifying prospects. A third might be trying to enrich their CRM.
The tools are the same. The underlying intentions are completely different.
If you can identify and group those intentions across sessions, you start answering much more valuable questions:
What are the most common use cases? Which workflows are growing? Are people using your MCP in ways you hadn't anticipated?
Instead of optimizing individual tools in isolation, you can understand how people actually use your product through AI assistants.
3. What are users asking for that you haven't built?
One of the most valuable sources of product feedback is what customers try to accomplish but can't.
In a traditional application, this information might come from support tickets, customer interviews, feature requests, or user research.
With an MCP, users may simply ask their AI assistant to do something your product doesn't support.
Perhaps they want to generate a report that requires data you don't expose.
Maybe they're trying to combine several operations into a workflow that your current tools make difficult.
Or perhaps they're repeatedly looking for a capability that doesn't exist.
These requests can reveal unmet demand.
And when similar requests appear across multiple users and sessions, they become particularly useful signals for deciding what to build next.
Rather than relying exclusively on explicit feedback, you can learn from how people interact with your MCP.
4. Where are users getting stuck?
Of course, technical observability still matters.
You need to monitor errors, latency, availability, and individual tool calls.
But not every unsuccessful experience produces an error.
A user might repeatedly reformulate a request because the results aren't useful.
An agent might call several tools without reaching the intended outcome.
Someone might struggle with the same workflow across multiple sessions.
Each tool call could be technically successful, while the overall experience remains frustrating.
Understanding these patterns helps you identify friction that isn't obvious from infrastructure metrics alone.
The goal isn't to replace traditional monitoring.
It's to complement it with a better understanding of the workflows happening on top of your MCP.
5. When should your team take action?
Analytics become particularly valuable when they lead to action.
Imagine a prospect exploring your product through ChatGPT and asking about enterprise features.
Or an important customer repeatedly encountering difficulties with a specific workflow.
Or dozens of users requesting a capability your product doesn't currently support.
Those aren't just interesting metrics.
They're potentially useful signals for your sales, product, and customer success teams.
Instead of requiring someone to inspect a dashboard every morning, these events can trigger notifications when something important happens.
Your MCP is no longer just an integration.
It becomes another source of customer and product intelligence.
From MCP observability to actionable insights
This is the problem we're working on at Flowlines.
We built MCP analytics and observability to help developers understand what's happening after they launch their MCP servers.
Flowlines uses OpenTelemetry-based instrumentation to collect MCP interactions and reconstruct sessions.
From there, it analyzes activity across users and sessions to surface recurring patterns, including:
- User intents and use cases: Understand what people are trying to accomplish, not just which tools they're calling.
- Adoption and user journeys: See how users interact with your MCP across different AI clients.
- Errors and friction: Identify recurring issues and workflows that deserve attention.
- Unmet demand: Discover capabilities and product improvements users are looking for.
- Business signals: Surface relevant customer activity and trigger notifications when something important happens.
The important part is connecting individual interactions to the bigger picture.
A single trace can help you understand what happened in one session.
Analyzing patterns across sessions helps you understand what's happening across your product.
Getting started shouldn't require rebuilding your MCP
Observability shouldn't become another infrastructure project.
We built an onboarding tool that works with coding agents to help instrument existing MCP servers.
You can create an account, follow the onboarding, and have your coding agent handle most of the instrumentation.
Under the hood, Flowlines uses OpenTelemetry, so developers can build on an established observability standard.
Once your MCP starts receiving traffic, you can explore sessions, understand usage patterns, and identify opportunities to improve the experience.
You can try it here: Get started with Flowlines.
Shipping your MCP is just the beginning
MCP makes it easier for software products to reach users directly inside AI assistants.
But distribution is only the first step.
Once people start using your MCP, you need to understand whether they're adopting it, which workflows matter to them, where they struggle, and what they want next.
The same principles that made product analytics essential for websites and applications are becoming increasingly relevant for MCP servers.
The difference is that much of the user experience now happens outside your own interface.
Your MCP might be getting thousands of tool calls. The real question is what those calls are telling you about your users and your product.
That's what we're building at Flowlines.
If you're running an MCP server, I'd love to hear how you're measuring adoption and understanding what users actually do with it.
Top comments (0)