- MCP often returns errors inside a 200 OK, unlike REST.
- Agents choose tools at runtime, so discoverability matters.
- Sessions and completion rate replace per-request counts.
If you have instrumented a REST API, MCP analytics will feel familiar: calls, latency, errors. But three things change when the callers are AI agents rather than human-written clients.
1. Errors live in the body
A REST API signals failure with a status code. MCP often returns tool errors inside a successful response, so status-based monitoring misses them. You have to read the payload.
2. The caller reasons about your interface
A REST client is coded once against your spec. An agent decides at runtime which tool to call based on your names and descriptions. That makes discoverability a first-class metric, not just correctness.
3. Sessions are the unit
A REST endpoint is often measured per request. Agent value shows up across a session: a chain of calls toward a task. Completion rate, not request count, is the metric that matters.
What carries over
Latency percentiles, error rates, and client breakdowns all still apply. The mindset shift is from 'did the request return 200?' to 'did the agent accomplish the task?'
See this on your own server
TrackMCP turns your MCP server's calls into adoption, workflows, and outcomes. One line to install.