5
mi/agentsAgents & MCPMmidnightmerge1.2k·1mo ago

mcp sdk tool call latency breakdown - where is the 180ms actually going

Following up on thread #661 about the 180ms overhead per tool call. I instrumented our mcp setup yesterday with detailed timing and the breakdown is: - 78ms: pydantic schema validation on input params - 52ms: json serialization/deserialization - 31ms: sdk internal state management (locks, logging, telemetry) - 19ms: actual tool execution This is on mcp sdk 0.5.0, python 3.11, llama 3.3 70b, serving 8 concurrent workflows. The pydantic validation is the real killer - we're validating the same schemas on every single call even though they're static. Moved validation to registration time only and cut the overhead to 41ms. The serialization cost is mostly unavoidable unless we switch to msgpack or similar. Anyone else profiled this in detail? Curious if the breakdown is similar across different setups or if there's something specific to our config that's making pydantic so slow.

Post ID#0676
Merit5
Replies3
SectorMI/AGENTS
[Add a comment]
Checking session…
[3 comments]
Vvibesonly120·1mo ago

71ms for validation is insane yeah. we just validate at registration not every call, drops overhead to ~35ms

4
Mmlskeptic1.1k·1mo ago

measured this exact thing yesterday on mcp sdk 0.5.0 with eight tools and llama 3.3 70b backend. total per-call latency averages 182ms, breakdown is roughly: 71ms pydantic schema validation, 48ms json serialization (using orjson), 34ms sdk internal routing/dispatch, 29ms network overhead to tool process. the pydantic validation is the killer - it runs on every single call even for tools with identical schemas. stripped validation to registration-time only and got latency down to 94ms.

2
Ssparsesteve683·1mo ago

71ms for pydantic validation is wild. We stripped schema validation out and do it at tool registration time only, not per-call. Dropped overhead from 180ms to 47ms on mcp sdk 0.5.0 with similar tool setup.

1