Glossary
Plain definitions grounded in the real product: MCP sessions, tool call success rate, adoption, clients and returning users, followed by earlier agent observability terms.
It is not the same as a network connection or transport session: the MCP 2026-07-28 specification removed protocol-level sessions from its stateless core. Flowlines uses supplied session context when available and labels sessions it infers, which can split related work or group separate requests.
Can I see a full MCP session? ›Divide successful calls by calls with a known result and report unknown results separately. In a synthetic example, 348 successful calls out of 360 is a 96.7% call success rate. A successful call does not prove the user's job was done, so read it next to session outcomes.
What is my tool call success rate? ›Call volume is not adoption: one script can generate hundreds of calls. Count distinct users and sessions, exclude internal and test traffic, and read the result with identity coverage and the returning share.
Is anyone using my MCP server? ›Returning users divided by active users gives the returning share, the clearest early sign that a server became part of someone's workflow. It needs a stable, permitted user identifier; anonymous calls cannot be counted as returning.
How many users come back? ›In MCP analytics, the client is usually the application name reported with each request. It is self-reported and identifies the application, not the person, so recognizing one user across clients needs a stable user identifier. Keep calls without a client name in an unknown group.
Which AI clients call my server? ›Flowlines shows calls per session, repeated-call loops, failed sessions, and typical tool paths for each intent cluster. It distinguishes a technically successful call from a journey that actually helped the user.
See MCP observability ›A successful tool status does not prove that the agent completed the task. Outcome coverage makes that gap visible and helps teams find where additional context is needed to judge success.
See MCP journey evidence ›The standard live path accepts OTLP/JSON or protobuf at the Flowlines traces endpoint and routes data using a namespace API key. Provider connectors can poll existing traces without replacing the source trace store.
How do I connect Flowlines to my agent? ›Where execution observability inspects one LLM call, behavioral observability looks across sessions: which issues recur, who is affected, what users intended, and which original sessions show the pattern. It turns trace data into operating answers.
How do I know if my agent is working in production? ›Flowlines separates behavior issues from reliability errors. Each issue includes what happened, why it matters, the next step, technical detection details, where it fires, and the affected production sessions.
What signals does Flowlines detect out of the box? ›The Flowlines Home view includes user cohorts alongside active users, intents, issues, and sessions that need attention. Cohort context helps teams see whether a recurring issue is broad or concentrated among a particular group of users.
How do I segment my users by behavior? ›It appears on the Flowlines Home view next to analyzed chats, active users, and negative feedback. It gives operators a fast health read while the Issues and Search views provide the evidence behind the aggregate.
How do I know if my agent is working in production? ›Issue details in Flowlines connect the summary and next step to the exact sessions where the pattern occurred. This keeps a conclusion inspectable and gives engineering a concrete starting point for diagnosis.
How do I find the failure modes my logs don't show? ›Drift often does not crash. It appears as a behavior issue that recurs across sessions, users, intents, or tool journeys. The useful unit of investigation is the pattern plus the original sessions, not an isolated response.
How do I detect agent drift over time? ›100 MCP sessions a month, free