Product
Find recurring requests and the tools people actually reach for before prioritizing the next capability.
MCP server analytics Your server is live. What are people doing with it?
MCP server analytics connects tool calls to users, clients, sessions and use cases. Flowlines helps you see who comes back, what people try to accomplish and where their observed workflows get stuck.
100 analyzed MCP sessions per month, free. No credit card. Connect your assistant, then instrument your server.
From server activity to a product decision.
Explore the overview, users and use cases of an example customer-operations server.
Customer operations
Last 7 daysTool calls840
Sessions84
Identified users24
Tools used4
Most used tools
Which capabilities get called?
Top use case
Prepare a customer brief
38 sessionsThe useful question is not just which tool ran. It is what people wanted to get done.
What is MCP server analytics?
MCP server analytics measures how people and AI clients use the tools exposed by a Model Context Protocol server. It connects activity to product questions: which capabilities get adopted, which users return and which workflows need attention.
Infrastructure monitoring tells you whether the service is available. Tool-call telemetry tells you which operation ran and whether it failed. Product analytics adds adoption and repeat usage. Session analytics connects related calls to the job being attempted. These views complement one another.
What should you track after launch?
Start with users, sessions and tool usage, then add the context needed to interpret them. Keep missing identity and unknown outcomes visible so incomplete telemetry does not look like a healthy product.
| Measure | The question it answers | Read it with |
|---|---|---|
| Users and repeat usage | Is adoption spreading beyond the first few testers? | Identity coverage; shared accounts are not individual people. |
| Clients | Where does usage come from? | The client information supplied by the integration. |
| Tools and calls | Which capabilities are used? | Users, sessions and repeated calls, not volume alone. |
| Errors and latency | Which operations need engineering attention? | The affected workflow and the result returned to the caller. |
| Sessions and use cases | What jobs do people give the server? | Available context and whether the session was inferred. |
| Reported outcomes | How did the agent say the work ended? | Observed call evidence and missing reports. |
More calls. More value? Not necessarily.
A rise in MCP traffic can mean new adoption, more work from existing users, or more attempts to finish the same job. The useful next step is to break the increase down by user, tool, client and session.
Suppose a customer-brief workflow moves from three calls to nine. If the same users repeat a search and report that they cannot finish, the extra traffic is friction, not growth. If new teams run more completed briefs, it may be useful adoption. Inspect representative sessions before choosing an explanation.
Engineering
Follow a failing path from the affected session to the calls behind it, rather than starting with a global error count.
Customer teams
Filter users by tool or client to see who returns and who repeatedly encounters issues.
How Flowlines connects the pieces.
Instrument the MCP server with compatible OpenTelemetry telemetry. Flowlines organizes the observed calls by server, tool and available identity, then connects them into sessions where the context supports it.
The server overview brings together tool usage, clients, users, sessions and request categories. From there, open a tool to see what people use it for, or a session to follow the sequence and its reported outcome. Period comparisons help you investigate changes; they do not prove a release caused them.
A server does not automatically receive the assistant's complete conversation or final answer. What you can analyze depends on what the integration sends. Keep inferred sessions and agent-reported outcomes distinct from directly observed events.
Follow related calls in MCP session analytics ↗Investigate adoption with MCP tool analytics ↗
MCP analytics and observability work together.
MCP observability asks what happened and where a problem occurred. MCP analytics asks how the server is used and what to improve. Both can use the same telemetry, but a healthy request is not the same thing as a useful workflow.
Keep your infrastructure and trace tools. Use Flowlines for the product and behavioral questions that cross calls, users and sessions. Review failures alongside use cases, adoption and the information you still cannot observe.
Connect your assistant. Instrument your MCP.
The Flowlines plugin gives your assistant the setup workflow. Connecting the assistant does not automatically instrument your MCP server.
- Connect FlowlinesUse the button to open the supported setup path in your assistant.
- Instrument the serverUse the plugin's MCP observability workflow. Review what will be captured before sending production data.
- Verify the first callsCheck tools, identity and session coverage. Add outcome context where supported and keep missing data visible.
MCP OpenTelemetry instrumentation guide ↗MCP observability product overview ↗The MCP analytics measurement guide ↗
MCP server analytics: common questions
Is there product analytics for MCP servers?
Yes. Flowlines provides server, tool, user and session views for compatible MCP telemetry. Identity, intent and outcome coverage depend on what the integration supplies.
Can I track who uses my MCP server?
When calls include a stable, permitted user identity, Flowlines can group activity by that identity and show new or returning users. Anonymous calls do not identify a person, and a client application is not an end user.
Can I use my existing OpenTelemetry setup?
Yes, if it emits the compatible MCP telemetry Flowlines needs. The Flowlines plugin can guide the instrumentation and verification. Installing the plugin alone does not instrument a server.
What is the difference between a successful call and a successful workflow?
A call can return without an error while the user's job remains unfinished. Review the related calls and any reported outcome together. No outcome report means the result is unknown, not automatically successful.
Start with the traffic you already have
See the work behind the calls.
Connect Flowlines and take the next step with your assistant.