- Logs prove a request happened; they can't explain behavior or outcomes.
- MCP servers are where websites were before analytics existed.
- Capture at the protocol layer to see clients, tools, and completions from day one.
You shipped an MCP server. Agents can connect, tools resolve, requests return 200. By every signal your infrastructure gives you, it works. And yet you cannot answer the questions that actually decide whether it is worth maintaining.
Who is using it? Which tools do they rely on? Where do sessions stall? Which calls fail in a way your logs never surfaced? These are product questions, and logs were never built to answer them.
Logs record events, not behavior
A log line proves a request occurred. It does not tell you that Claude called search_docs, got a result, then tried run_query three times and gave up. Behavior lives in the sequence and the outcome, not in any single line.
The gap is the same one websites had
Every click sat in raw web server logs long before Google Analytics existed. The logs were complete and useless for understanding people. Analytics turned that stream into sessions, sources, and funnels. MCP servers are at exactly that moment now.
What to measure instead
- Who connects: which clients and how usage grows
- What they use: tool adoption and the tools nobody touches
- Whether work completes: sessions that reach a useful result
- Where it breaks: failures hidden inside successful responses
You do not need to instrument each tool by hand. Because MCP is a protocol, you can capture all of this at the transport layer with a single wrapper, and start answering the questions that matter the day you launch.
See this on your own server
TrackMCP turns your MCP server's calls into adoption, workflows, and outcomes. One line to install.