Skip to main content
Every metric on the analytics dashboard is computed from the MCP requests Alpic records as they reach your server. This page defines each one precisely, so you always know what you are looking at.

​
Sessions and conversations

Two concepts matter before reading any session number, because they are easy to confuse: A session is an MCP protocol session. When an MCP client connects to your server, it sends an initialize request that starts a new session. This handshake announces the client’s name and capabilities, which is how Alpic knows whether traffic comes from ChatGPT, Claude, Cursor, or another client. The session then carries every request from that client until the connection ends or expires. A conversation is a chat thread in the end user’s client. The MCP protocol itself has no notion of a conversation: your server never sees the chat. Some clients choose to share a conversation identifier with each request. Today only ChatGPT does this, so for ChatGPT traffic Alpic knows which chat thread each session belongs to. The two do not map one to one. A single conversation can create several MCP sessions: clients reconnect, users return to an older chat, sessions expire and new ones open. This is normal protocol behavior, not a sign of anything wrong. How it’s measured:
  • The Sessions metric counts initialize requests received from recognized MCP clients over the selected period. Think of it as how many times your app was opened or reconnected to.
  • Session-level metrics (Sessions with errors and Session error rate) group by conversation when the client provides one, and by MCP session otherwise. For ChatGPT traffic this means a conversation counts once, even if it opened several sessions along the way.
Because one conversation can span several sessions, the Sessions count for ChatGPT traffic can be higher than the number of actual conversations. That gap is expected.

​
Requests

A request is any MCP request received by your server: tool calls, but also protocol traffic such as initialize, tools/list, prompts/get, or resources/read. Request charts can be scoped to tool calls only, to protocol requests only (excluding ‘initialize’), or to everything.
Protocol requests don’t necessarily reflect active usage. MCP clients send them frequently just by being configured to connect to your server, so look at tool calls when you want to measure real engagement.

​
Tool calls

The number of tools/call requests received. This is the best proxy for actual usage of your server: each tool call means an LLM decided to use one of your tools. The tool performance table breaks this down per tool, with:
  • Requests: the number of calls to that tool
  • p50 / p95 latency: median and 95th percentile response time
  • Success rate: the share of calls that completed without any error

​
Users

The number of distinct identified people who used your server over the period. This metric has enough subtlety to deserve its own page: see How users are counted.

​
Output tokens

An estimate of how many tokens your server’s responses add to the LLM’s context window, shown as an average per call. Alpic estimates the token equivalent of each response part that gets passed to the model: tool call results, tool lists and descriptions, prompt contents, resource contents, and server instructions sent during initialize. Use this to spot tools that flood the context window with oversized responses.
These are estimates of context usage, not billed tokens from any LLM provider.

​
Latency

The time between a request reaching Alpic and your server’s response, measured at the platform level. Charts show p50, p95, and p99 percentiles rather than averages, so slow outliers stay visible.

​
Errors

Alpic separates two kinds of errors, because they mean very different things:
  • Tool errors: a tool call returned a result with isError set to true. These are common and by design: the error is passed back to the LLM so it can recover, retry, or rephrase. A baseline of tool errors is normal. If you want to design recoverable errors well, check out this article.
  • MCP errors: protocol-level errors that are not passed to the LLM and usually surface as error messages in the user’s client. These deserve your attention. Check your logs if you see a spike.
MCP errors are further classified by type:
Protocol implementation quality varies across MCP clients and can generate more errors than expected. For instance, Claude requests the list of resources and prompts even when your server doesn’t advertise any, which produces MCP errors you can safely ignore.

​
Session error rate

The share of sessions that contained at least one error, whether a tool error or an MCP error. As explained above, sessions are grouped by conversation when the client provides one. This is a good health metric to watch over time: a rising session error rate means a growing share of your users are hitting problems.