MCP latency by backend, with real numbers per call

Persistent osascript wins on raw per-call latency: about 5ms once the osascript process is kept alive between commands, against roughly 80ms when each call spawns a fresh osascript. The catch is that AppleScript only fully covers apps with a scripting dictionary; for native apps that do not expose one, you need the Accessibility API instead, and that backend pays a much larger walk-the-tree cost (median 575ms in our 50-call sample). Screenshot + VLM backends are the slowest, dominated by the vision model round trip (1 to 4 seconds), not by the macOS side.

Different unit of work. osascript runs one targeted command and returns; the Accessibility API call in an MCP server walks the entire AX tree of the focused window so the model has something to grep. On a Fazm Dev window with 387 elements the median walk was 575ms (n=50), p90 was about 1.1s, max was 5.2s when the window was still hydrating. The walk dwarfs the actual click. macos-use exposes the walk result via the 'file:' line in the JSON-RPC response so the model can grep the tree instead of re-walking it.

It is an activation grace period. Sources/MCPServer/main.swift:1659 calls NSRunningApplication(processIdentifier:).activate() and then sleeps 200_000_000 nanoseconds (200ms) before posting the CGEvent. Without that pause, the click sometimes lands while the previous frontmost app still owns the input focus, the event hits the wrong window, and the AX tree the server walks afterward does not match what the user sees. 200ms is empirical; we landed on it because shorter values still produce focus races on slower Macs.

click + type + Return is the common composed call, and the gap at main.swift:1866 (100_000_000 nanoseconds = 100ms) gives the target app a chance to actually update its focused element before the next synthetic event lands. Without that pause, typed characters sometimes get eaten by the previous focus owner, or Return fires before the text field finishes processing the keystrokes. The 100ms is the lower bound that worked across the apps we tested; you can tune it down in your fork if you only drive Cocoa-pure apps.

macos-use already writes the timing to disk on every call. Look at the header of any file in /tmp/macos-use/, e.g. '# Fazm Dev — 387 elements (0.55s)'. The 0.55s is the AX walk; the file's mtime against the previous file in the directory is the per-call wall time including activation, click, walk, and PNG capture. A one-liner: cd /tmp/macos-use && for f in *.txt; do head -1 "$f"; done | awk '/elements/ {print $NF}'. That gives you a real distribution from your own usage, not a benchmark slide.

Yes, roughly linearly with element count for the AX walk. A 41-element Fazm dialog walked in 5.09s (a cold launch outlier), but on a hot run a 41-element window walks in ~100ms. A 547-element main window walks in ~650ms on average, 1.57s p90. Catalyst apps with deep nested AXGroup hierarchies are the worst case: each AXUIElementCopyAttributeValue is a synchronous IPC call to the target process, and a deep tree means thousands of round trips. The fix is not faster code, it is fewer attributes per node, which macos-use already does (it reads role, value, frame, and a small attribute set per node, not every AX attribute).

It is out of the critical path. captureWindowScreenshot at main.swift:386 forks a subprocess (screenshot-helper) so the ReplayKit framework loaded as a side effect dies with the child instead of pinning the parent at ~19% CPU forever. The parent gives the helper a 5s timeout (deadline = DispatchTime.now() + 5.0 at main.swift:476-477) and waits with group.wait. In normal operation the PNG lands in 100-300ms. If the helper times out, the .txt and the JSON-RPC reply still go through; you get a degraded but not-broken response.

Yes, but you give up state observability. macos-use deliberately fuses every input tool with a traversal so the diff (+/-/~ in the .txt) is part of the response the model reads. If you only want to click, fork the server and skip options.showDiff and options.traverseAfter for clickTool; you save the 575ms walk on the back half and the call drops to ~250ms (200ms activation + ~10ms CGEvent post + ~40ms response build). The trade-off is that the model now has no idea whether the click did anything, so it usually issues a follow-up refresh_traversal anyway and you end up paying the walk on the next turn instead of this one.

Not in a way you can see. MCP over stdio is framing JSON-RPC on a local pipe between the client and the server process. Round-trip overhead is sub-millisecond. The dominant transport cost in a Claude Code session is the model RTT to Anthropic, not the MCP stdio. When people quote 'MCP latency' numbers in the 200ms to 5s range, they are quoting the backend the server is wrapping, not the protocol. The protocol is free; the backend you picked is what you are paying for.