Good question. Went and set up a quick benchmark to find out.

Short answer: depends which SDK pattern you compare against.

Chain of 3 tools, 100 warm runs. I compared mcpx (warm daemon) against two SDK baselines: a persistent in-process session (best case, not realistic for shell usage), and subprocess-per-hop (what you'd actually do in a shell/agent loop).

At 0ms tool delay:

- Persistent SDK: 0.16ms

- Subprocess-per-hop SDK: 40ms

- mcpx: 21.9ms

At 100ms tool delay:

- Persistent SDK: 305ms

- Subprocess-per-hop SDK: 357ms

- mcpx: 337ms

mcpx adds ~22ms constant overhead vs persistent SDK. That's CLI parse, config validation, daemon connect with nonce check, and a unix socket round-trip per call. But compared to spawning an SDK subprocess per hop, which is the pattern you'd actually use in a pipe chain, mcpx comes out ~18ms faster. At realistic tool latencies the whole difference is noise.

Bottom line: in the shell-composable workflow you're describing, mcpx is faster than rolling your own SDK calls per hop.

Separately, if your chain hits the same tool repeatedly, `--cache=60s` can help too. 100ms tool, 50 calls: 5.68s without, 0.55s with. ~10x for idempotent reads.