Observed
The operations and results present in the telemetry.
MCP session analytics The calls worked. Did the job?
MCP session analytics groups related tool calls into an observed workflow. Flowlines brings together the sequence, supplied intent and reported outcome so you can see more than the status of each request.
100 analyzed MCP sessions per month, free. No credit card. Connect your assistant, then instrument your server.
Three healthy calls. One unfinished job.
Compare a completed request, a partial result and a session with no outcome report.
Customer brief
Session exampleSupplied user intent
Prepare a customer brief with this week's activity.
- 1
search_customersCall succeededFind the account for the customer brief.
Observed result: Matching customer found.
- 2
get_customerCall succeededRetrieve the account details.
Observed result: Company profile returned.
- 3
get_activityCall succeededCheck this week's activity.
Observed result: Activity returned, but the newest entry is from last month.
Agent-reported outcome
Partial
I found the account, but the latest activity was from last month. I could only prepare part of the brief.
A report to review against the calls, not independent verification.What is an MCP session?
For product analytics, an MCP session groups calls that belong to an attempted job. It is not automatically the same as a network connection, transport session or single trace. The useful boundary is the user's workflow.
The MCP 2026-07-28 specification removed protocol-level sessions from the modern stateless core. Older integrations may still use a transport session identifier. Neither case automatically supplies the application-level context needed to group a user's work.
Flowlines uses supplied session context when available and can infer sessions when suitable identity and intent context exist. An inferred session is an approximation: related work can be split, or separate conversations can be grouped together. Calls without enough context may remain unassociated.
Can you see a full MCP session or conversation?
You can follow related tool calls captured by the integration. That is not automatically a transcript of the assistant's conversation. Work in another server, uncaptured calls and the final answer can remain outside that view.
Use session analytics to inspect the observed path, supplied intent and reported result. If you need to verify a complete task, first check which parts your instrumentation actually covers.
| View | What it contains | What it does not guarantee |
|---|---|---|
| Tool-call log | A record of an individual operation and its available result. | The larger job or what happened next. |
| Analytics session | Related observed calls, supplied intent and any reported outcome. | Every step, every server or a verified final result. |
| Conversation transcript | Messages captured by the assistant application when supported and permitted. | That a server-side integration receives those messages. |
A successful tool call can still leave the user stuck.
Call success answers whether an operation completed technically. Workflow success asks whether the requested job was accomplished. The two measures should never be silently substituted for one another.
Consider a customer brief: search for an account, retrieve its details, then fetch recent activity. Every call can succeed while the activity is too old to answer the user's question. An agent-reported partial result makes that gap visible. Without an outcome report or other evidence, the final result remains unknown.
Inspect repeated searches, alternative paths and errors in context. Repetition may be a recovery attempt, but it can also be normal pagination or a legitimate second lookup. A sequence reveals where to investigate; it does not prove the cause by itself.
What can you see in a Flowlines session?
A session view connects the available evidence. Its completeness depends on the instrumentation, supplied identity and captured context, not simply on the number of tool calls.
| Context | What it adds | Boundary |
|---|---|---|
| User and client | Who or what generated the activity. | Only when supplied; shared identities can represent several people. |
| Supplied intent | The job the caller says it is trying to do. | Not the entire conversation or the model's hidden reasoning. |
| Tool sequence | Operations, timing, repeated calls and errors. | Only the calls observed by the integration. |
| Arguments and results | The captured request and client-visible response. | Availability depends on capture; payloads can contain sensitive information. |
| Reported outcome | How the agent says the work ended. | A report is a claim to review, not independent verification. |
| Session grouping | A path through related calls. | Inferred grouping is labeled and may be incomplete. |
A tool name is not a user intent.
search_docs can support onboarding, debugging, vendor evaluation or a security review. Grouping only by the tool hides those different needs. Supplied intent and call reasons make the distinction more useful.
Flowlines organizes available request context into use cases and lets you inspect the associated sessions. That can expose repeated unsupported requests or a workflow that consistently needs a workaround. Validate the examples before turning a pattern into a roadmap decision or commercial signal.
Keep reported, observed and unknown separate.
An agent may report that a job was accomplished, partially completed or failed. Read that report alongside the observed calls. A report of success that conflicts with available evidence deserves investigation, but a missing report is not proof of failure.
Show outcome coverage with any completion metric. Ten successful reports out of ten reported sessions tells you little about another ninety sessions without a result. Do not classify inactivity as abandonment unless your product has evidence supporting that interpretation.
Reported
The caller's description of the job and how it ended.
Unknown
The context or final result the integration did not capture.
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 session analytics: common questions
Can I see a full MCP workflow?
You can follow the related calls captured by the integration. That may not include other servers, the user's conversation or the assistant's final answer. Supplied and inferred session context determine how calls are grouped.
Does Flowlines infer missing sessions?
When suitable user and intent context exists, Flowlines can infer a session. Inferred grouping is approximate and labeled. Calls without enough context are not silently presented as complete journeys.
How does Flowlines understand user intent?
It uses the intent and call reasons supplied through the integration to organize observed use cases. It does not recover an unseen conversation from a tool name.
Does no outcome report mean the user abandoned the workflow?
No. The result is unknown. Missing telemetry, a client that did not report a result or work completed outside the server can all explain the absence.
Start with the traffic you already have
See the work behind the calls.
Connect Flowlines and take the next step with your assistant.