MCP analytics is customer analytics
Server metrics answer "is it up?". An MCP serving your customers' AI agents has a sharper question: who is using what, and is it working for them? The unit of analysis isn't the request — it's the customer.
Requests (30d)
5,368
Failures (30d)
95
p95 latency
870 ms
Daily requests — last 30 days Successful Failed
The four layers worth building
- Adoption. Connected customers, calls per customer per month, last activity. This is your "are AI features landing?" dashboard — and your expansion signal.
- Reliability. Success rate on tool calls (not handshakes), p95 latency windowed over 24h/7d/30d. Tool errors ride inside HTTP 200 in MCP — count outcomes, not status codes.
- Per-tool health. Which tools get used (curation feedback) and which fail (often a schema drift signal from your upstream API).
- Protection headroom. Usage against quotas, caps and rate limits — the difference between "we throttled a runaway agent" and "we found out from a customer email".
Logs: the request level still matters
Aggregates say something is wrong; logs say what. The log schema that has paid for itself, line by line: timestamp, event (including auth failures and gateway rejections — absence of evidence is undiagnosable), tool, customer, outcome, latency, client IP and user agent (which is how you catch CDN-level blocking of AI clients).
| At | Event | Tool | Customer | Outcome |
|---|---|---|---|---|
| 9:20 PM | tools/list | — | admin@commandplusk.com | Success 363 ms |
| 8:57 PM | tools/call | post | ada@loopwork.io | Success 867 ms |
| 8:45 PM | tools/call | labels | ada@loopwork.io | Success 295 ms |
| 8:33 PM | tools/call | activities | felix@brightpath.app | Success 843 ms |
| 8:21 PM | tools/call | get_latest_activities | felix@brightpath.app | Success 891 ms |
| 8:03 PM | tools/call | posts | ada@loopwork.io | Failed 593 ms |
| 7:48 PM | tools/call | me | felix@brightpath.app | Success 488 ms |
Per-request logs kept 30 days · daily aggregates forever · system events filterable
Two pitfalls we hit so you don't
- System events polluting usage. Discovery probes and 401s counted as traffic inflate error rates and even consume quotas. Log them, but keep them out of usage rollups and headline KPIs.
- Status-code truthiness. A failed MCP tool call is usually HTTP 200 with an error payload. Dashboards keyed on status codes will show a green wall while customers suffer — key on the outcome flag.
All of this ships with the gateway
Per-customer usage, windowed reliability, request logs with auth failures and client signatures, 30-day retention — it's the standard dashboard on every Command+K MCP deployment.
FAQ
- What metrics should I track for an MCP server?
- Four layers: adoption (connected customers, calls per customer per month), reliability (success rate on tool calls, p95 latency over 24h/7d/30d), per-tool health (which tools are used, which fail), and protection headroom (usage against quotas and rate limits). Aggregate counters alone hide who is affected — per-customer attribution is the key dimension.
- Why should system events be separated from usage metrics?
- Auth probes, discovery requests, and rejected calls are diagnostics, not product usage. If they land in the same counters, a bot hammering 401s reads as a 90% error rate, consumes quota, and pollutes top-tools — we hit exactly this and now log system events separately from usage rollups.
- How long should MCP request logs be retained?
- A workable default: per-request logs for 30 days (enough for debugging and support), daily aggregates forever (enough for trends and billing history). State the policy in the UI so owners aren't guessing.