Sessions

Where a session id comes from

Up to MCP revision 2025-11-25, a client opened a session with an initialize handshake, then carried the resulting Mcp-Session-Id header on every later request. A call that still arrives with that header keeps it. The grouping is your server's, and foro only reads it.

Revision 2026-07-28 removed the handshake and the session with it. A client on that revision identifies itself once per message and sends no session id at all, so there is nothing left to read. That is where MCP is heading, and it would leave this table empty.

How an inferred session is built

When a call carries no session id, the gate in front of your container mints one. It has two facts to work with: the caller's name and version, read from the clientInfo on the message, or from the User-Agent header when the client sends no clientInfo.

Calls that share a name and version stay in one session until 30 minutes pass with no call. The next one after that gap opens a new session. It's the same rule web analytics uses to cut stateless traffic into visits. MCP itself defines nothing here.

A minted id starts with syn_ and the dashboard tags its row Inferred, so you can always tell foro's grouping from your client's.

Where it is approximate

A name and a version don't identify anyone. Two people on the same client app, same version, calling the same public server inside one 30-minute window land in a single session. Nothing in those requests tells them apart, so foro doesn't pretend otherwise.

It splits things too. An agent that sits idle for over half an hour comes back as a second session, even though nothing about it changed. The same goes for a restart: the grouping lives in the gate's memory, so a redeploy or a container restart starts fresh, and two calls seconds apart end up in different sessions if a restart fell between them.

A call with no name and no User-Agent gets no session at all. It still counts everywhere else in Metrics. It just can't be tied to a run, so it never reaches this table.

What sessions are good for

Use them for debugging. They put one client's calls in order, which is what you want when a tool failed and the question is what ran before it. A guessed grouping is good enough for that, and you didn't have to instrument anything to get it.

Don't use them as an identity or an audit record. Two sessions aren't two people, one session isn't one person, and neither number is something to bill on. For a figure you have to defend, count it inside your own server, where you know who called.

Nothing stores a session on its own. Each one is rebuilt on demand from the per-call rows your plan keeps, so it disappears the day those rows fall out of your metrics window.