The answer
MCP tool latency is the time between your server receiving a tool call and returning its result. Record it at the tool boundary, then break it into the downstream calls the tool makes, so a slow call points to the dependency that caused it.
| Measure | What it tells you | Watch out for |
|---|---|---|
| p50 duration | The typical call. | A stable median can hide a slow tail. |
| p95 and p99 duration | The calls users notice. | Small samples make high percentiles unstable. |
| Latency by dependency | Which API or database is slow. | Duplicate spans inflate counts and timing. |
| Timeouts and cancellations | Calls the client gave up on. | Report them separately from errors. |
Compare the same tool on the same server and environment. A tool that searches across many records can be slower for good reasons, and a different mix of jobs changes the distribution. In Flowlines, read a slow tool alongside its use cases and affected sessions to decide whether the latency actually stops people from finishing their work.
How should I set latency alerts for MCP tools?
- Alert on p95 per tool over 5 to 10 minutes, and only above a minimum number of calls.
- Report timeouts and cancellations separately from slow successful calls.
- Compare against the same hour last week, since MCP traffic often follows working hours.
- Break a slow tool down by its dependency spans before changing the tool itself.
- Watch response size too: large results slow the client and cost context, even when the server is fast.
- Track initialize and tools/list latency separately from tool calls, because they affect every session.
Published