How does this differ from using a generic proxy/logging approach (e.g., mitmproxy/Charles) or just instrumenting the MCP server logs? Is the main value correlation + session capture + tool-call semantics?
mitmproxy/Charles are great when the traffic is HTTP and on the network path. A lot of MCP usage isn’t: it’s a local process talking JSON-RPC over stdin/stdout.
In that setup:
Generic proxies don’t see it (no HTTP, no socket to intercept)
Server-side logging only shows half the story (you don’t see what the client actually sent, retries/cancels, malformed params, timing from the client POV)
Reticle’s main value is MCP-aware debugging on that stdio channel:
req/resp correlation (JSON-RPC ids), latency per call, and error surfacing
client + server + stderr in one place (so crashes/debug prints don’t get lost)
session capture/export so you can reproduce/share a trace instead of “turn on logs and try again”
basic MCP semantics/filtering (method, errors, slow calls, payload size) instead of a raw byte stream
So yes: correlation + session capture + tool-call semantics, but specifically for the common “local MCP tool over stdio” case where generic network proxies and server logs fall short.
Curious about the design: how are you proxying stdio without adding noticeable latency? Are you doing async read/write loops with backpressure, or buffering and flushing line-delimited JSON? Any benchmarks?
Async read/write with tokio::select!, line-delimited JSON, no buffering beyond what BufReader gives you. The proxy is a single loop that races on stdin, stdout, stderr, signals, and GUI commands simultaneously. Whichever is ready first wins, gets forwarded immediately with flush(). No batching, no artificial delays.
Latency: <10μs per message in practice. The JSON parsing for telemetry (serde_json) is the bottleneck, not I/O. A typical MCP message parses in ~5μs on my M3.
Backpressure: Natural - if the child can't accept stdin, the proxy blocks on write_all(). If the telemetry socket fills up, logs get dropped (fail-open design - proxy never blocks on observability). No formal benchmarks yet, but "agent doesn't notice it's there" has been the bar. Happy to add proper measurements if there's interest.
When agents call tools, debugging is weirdly blind: the client UI often hides the raw request/response, errors get swallowed, and you can’t correlate “why did it do that?” with the actual tool traffic.
Reticle is a local proxy + UI that shows the raw MCP JSON-RPC traffic (requests/responses), correlates calls, and makes it easy to spot slow/failing tools.
---
Try it:
Install:
# npm
npm install -g mcp-reticle
# pip
pip install mcp-reticle
# homebrew
brew install labterminal/tap/mcp-reticle
Run with a demo MCP server:
# Start the dashboard
mcp-reticle
# In another terminal, wrap any MCP server
mcp-reticle run --name demo -- npx -y @modelcontextprotocol/server-filesystem /tmp
---
What I'd love feedback on:
Which MCP clients should I support next? (Cline? Continue? OpenAI Agents SDK?)
Do you want "replay tool call" / "redaction rules" / "session export" first?
Anyone else frustrated by the lack of observability in this space, or am I yelling into the void?
How does this differ from using a generic proxy/logging approach (e.g., mitmproxy/Charles) or just instrumenting the MCP server logs? Is the main value correlation + session capture + tool-call semantics?
mitmproxy/Charles are great when the traffic is HTTP and on the network path. A lot of MCP usage isn’t: it’s a local process talking JSON-RPC over stdin/stdout. In that setup:
Generic proxies don’t see it (no HTTP, no socket to intercept)
Server-side logging only shows half the story (you don’t see what the client actually sent, retries/cancels, malformed params, timing from the client POV)
Reticle’s main value is MCP-aware debugging on that stdio channel:
req/resp correlation (JSON-RPC ids), latency per call, and error surfacing
client + server + stderr in one place (so crashes/debug prints don’t get lost)
session capture/export so you can reproduce/share a trace instead of “turn on logs and try again”
basic MCP semantics/filtering (method, errors, slow calls, payload size) instead of a raw byte stream
So yes: correlation + session capture + tool-call semantics, but specifically for the common “local MCP tool over stdio” case where generic network proxies and server logs fall short.
Curious about the design: how are you proxying stdio without adding noticeable latency? Are you doing async read/write loops with backpressure, or buffering and flushing line-delimited JSON? Any benchmarks?
Async read/write with tokio::select!, line-delimited JSON, no buffering beyond what BufReader gives you. The proxy is a single loop that races on stdin, stdout, stderr, signals, and GUI commands simultaneously. Whichever is ready first wins, gets forwarded immediately with flush(). No batching, no artificial delays.
Latency: <10μs per message in practice. The JSON parsing for telemetry (serde_json) is the bottleneck, not I/O. A typical MCP message parses in ~5μs on my M3.
Backpressure: Natural - if the child can't accept stdin, the proxy blocks on write_all(). If the telemetry socket fills up, logs get dropped (fail-open design - proxy never blocks on observability). No formal benchmarks yet, but "agent doesn't notice it's there" has been the bar. Happy to add proper measurements if there's interest.
When agents call tools, debugging is weirdly blind: the client UI often hides the raw request/response, errors get swallowed, and you can’t correlate “why did it do that?” with the actual tool traffic.
Reticle is a local proxy + UI that shows the raw MCP JSON-RPC traffic (requests/responses), correlates calls, and makes it easy to spot slow/failing tools.
---
Try it: Install:
# npm npm install -g mcp-reticle
# pip pip install mcp-reticle
# homebrew brew install labterminal/tap/mcp-reticle Run with a demo MCP server:
# Start the dashboard mcp-reticle
# In another terminal, wrap any MCP server mcp-reticle run --name demo -- npx -y @modelcontextprotocol/server-filesystem /tmp
---
What I'd love feedback on: Which MCP clients should I support next? (Cline? Continue? OpenAI Agents SDK?)
Do you want "replay tool call" / "redaction rules" / "session export" first?
Anyone else frustrated by the lack of observability in this space, or am I yelling into the void?