Debugging in the AI Era: Inspect MCP, Agent, and Local LLM Traffic from One Native macOS App

How does Rockxy help developers debug in the AI era?

Rockxy is a free, open-source (AGPL-3.0) native macOS app that captures HTTP, HTTPS, WebSocket, GraphQL, and Protobuf traffic locally, so you can read exactly what your AI agents, MCP servers, and local LLMs send and receive. It runs entirely on your Mac — no cloud account, no telemetry — and it can hand captured flows back to an AI assistant over its own MCP server. The reasoning inside a model is opaque; the network calls around it are not.

The modern developer no longer debugs one app talking to one backend. You debug AI agents, MCP workflows, local LLM infrastructure, WebSockets, Protobuf payloads, mobile apps, and distributed APIs — often in a single session. Most of that surface is invisible in application logs but fully visible on the wire.

Rockxy is built with SwiftUI, AppKit, and SwiftNIO. It's a macOS-first tool today; Windows and Linux are planned, and a paid Pro tier is planned alongside the free open-source app.

What modern developers actually debug now (and why app logs aren't enough)

An AI agent run is not one request — it's a loop of real HTTP(S) calls. The agent POSTs to a model API carrying a tool schema, the model answers with tool calls, your code executes those tools (each its own network request), and the results go back to the model for another turn. Application logs show you the parts you remembered to log. The wire shows you everything.

Here is what stays hidden in logs versus what shows up when you watch the actual bytes:

These are not exotic failures. Retry storms, context-window blowups, malformed tool-argument JSON, and schema rejections (for example, a model API refusing a tool schema that's missing additionalProperties: false) all surface immediately when you can see the request body. The LangChain.js project has tracked real cases where tool-call arguments arrived stringified and broke downstream parsing — a class of bug you diagnose in seconds with the raw payload in front of you. The "black box" is mostly just unopened HTTP.

How do I see the network requests my AI coding assistant makes?

Scope capture to a single app, and the requests from Cursor, Claude, ChatGPT's desktop app, or a Codex CLI show up in the flow list. Calls to anthropic.com and openai.com appear as ordinary flows you can open and read. There's no SDK to wrap, no logging shim to install — you read the bytes the tool already sends.

A small detail that tells you it's the real traffic: Claude's coding tools hit the native /v1/messages endpoint, not /v1/chat/completions. Both Anthropic and OpenAI stream responses as Server-Sent Events (Content-Type: text/event-stream), with data:-prefixed JSON chunks; tool-call arguments arrive as partial-JSON deltas that assemble over the stream. Rockxy renders that stream so you can watch a tool call take shape token by token.

One honest caveat. Decrypting HTTPS bodies requires installing and trusting Rockxy's root certificate, and it works only when the client does not enforce certificate pinning. Rockxy does not magically read pinned or unconfigured connections — it reads what a trusted local proxy is allowed to read.

What's the difference between MCP Inspector and a traffic proxy like Rockxy?

This is the question most people get wrong, so it's worth being precise. MCP Inspector connects to your MCP server and validates what it declares — its tools, prompts, and resource schemas. It acts as its own test client. What it shows you is Inspector talking to the server, not Claude Desktop or Cursor talking to the server, and not the upstream HTTP a tool fires when it runs.

The transport reality matters here. The current MCP specification (revision 2025-11-25) defines two standard transports: stdio and Streamable HTTP. Server-Sent Events is an optional streaming mechanism within Streamable HTTP — not a co-equal transport — and the older standalone HTTP+SSE transport was deprecated when Streamable HTTP replaced it in the 2025-03-26 revision. A stdio server exchanges newline-delimited JSON-RPC over the operating system's pipes (stdin and stdout). There is no network socket on the stdio channel, so an HTTP proxy cannot attach to it directly.

That's exactly where Rockxy earns its place. It captures the Streamable HTTP MCP traffic that does cross the network (carrying an MCP-Session-Id header), plus all the downstream model-API and REST calls that stdio tools make outward — including what a closed-source, third-party MCP server actually sends on your behalf. Inspector tells you what your tools declare; Rockxy shows you what they do on the wire. The two are complements, not substitutes.

New to the protocol? Start with What Is an MCP Server? and the developer's shortlist of MCP servers for API debugging.

How do I debug Ollama, LM Studio, or vLLM traffic on macOS?

Local LLM servers speak an OpenAI-compatible HTTP API, which is the good news — and a loopback gotcha, which is the catch. The defaults:

• Ollama binds 127.0.0.1:11434 and serves an OpenAI-compatible API under /v1 (for example /v1/chat/completions). Change the bind address with OLLAMA_HOST.
• LM Studio defaults to http://localhost:1234/v1 (port configurable, the server is off until you start it, and it ignores the API key on localhost).
• vLLM defaults to http://localhost:8000/v1.

The sharp edge isn't Rockxy-specific: most HTTP clients bypass the proxy for loopback addresses by default. Traffic to localhost, 127.0.0.1, and ::1 is treated as "never proxy this," so a proxy pointed at a local endpoint can see nothing until you account for it. Chromium-based clients, for instance, override the implicit bypass with --proxy-bypass-list="<-loopback>". The general fix is to either disable the loopback bypass or address the local service through a non-loopback alias or IP.

Two settings people conflate: base_url chooses the destination, while a transport-level forward proxy is set separately on the HTTP client (or via the HTTP_PROXY / HTTPS_PROXY environment variables). Trust Rockxy's root certificate to decrypt the TLS. Once the bytes route through, you can read the real prompt, the sampling options, and the streamed completion — then use Compose to edit and replay a call against your local server.

This is deliberately not another mitmproxy terminal recipe. There's no Python virtualenv, no debug-flag script, no command to memorize — it's a GUI with replay, diff, and throttling built in.

How does Rockxy decode WebSocket and Protobuf frames from AI traffic?

Streaming agent connections and binary RPC are where a normal capture gives up. A WebSocket is bidirectional and long-lived, so it never resolves into tidy request/response pairs — Rockxy renders each frame individually, in both directions, with timing, so you can follow a single message through a live socket. Protobuf bodies show up as unreadable hex in any plain capture; point Rockxy at your .proto files and it decodes Protobuf (and gRPC) into JSON with the real field names.

From there, Compose and Diff Compare let you change one request and see exactly what moved between two runs, and Network Conditions throttling (3G, EDGE, LTE, Very Bad Network) reproduces the flaky timeouts that only happen on a bad connection — the ones an agent hits in the field but never on your fiber line.

For a deeper walkthrough of binary frames and upstream routing, see how to decode WebSocket and Protobuf frames in Rockxy.

How do I capture mobile and distributed API traffic the AI stack depends on?

Phone and simulator traffic doesn't pass through your Mac on its own, and the HTTPS is encrypted, so two things have to happen: the device points at your Mac's proxy address, and it trusts Rockxy's root certificate. The Developer Setup Hub does that wiring for you with one-click scoped setup for Python, iOS devices, React Native, Node.js, Ruby, Golang, Rust, Java VMs, and cURL — each with the right device proxy address and the trusted certificate already in place.

Distributed APIs are the other half of the modern stack. A single user action fans out across many services, and the failure is usually in the seam between two of them. Rockxy captures the full multi-host sequence in order, so you can spot which hop returned the error, diff two requests, Copy as cURL, and replay any single call in isolation.

For language-scoped how-tos, see debugging Node.js API requests and debugging Python API requests on macOS.

Can I feed captured traffic directly to an AI assistant — and is that safe?

There are two paths out of a single capture, and you choose based on whether you want a one-shot paste or a live channel.

1. Export and paste. Right-click a flow and Export as HAR, Export as OpenAPI (YAML or HTML), Copy as cURL, or Publish to Gist — then drop it into your model of choice.
2. Connect over MCP. Rockxy's built-in MCP server exposes list_flows, get_flow_detail, replay_request, and diff_flows over stdio, so a client like Claude Desktop reads your captured flows directly. The three-minute Claude Desktop setup covers the wiring, and the Stripe webhook case study shows it in a real debugging session.

Most tools do one leg of this — they export a HAR, or they generate a spec. Rockxy pairs capture with an MCP channel back to the assistant in one local app, which is the part that closes the loop.

Now the safety question, because it's the right one to ask. LLM and agent requests carry secrets in their headers — Authorization: Bearer tokens, x-api-key values, session cookies. Pasting full request logs into a model is one of the more common ways those leak; in July 2025, an xAI API key committed to GitHub exposed access to dozens of internal models, a reminder of how cheaply credentials escape. Rockxy's Redact Sensitive Data Before Sending to AI toggle strips sensitive fields from flows before they leave through the MCP bridge or an export. And because Rockxy is local-first — no cloud account, no telemetry — the unredacted bytes never leave your Mac in the first place. You can also script redaction yourself with an onRequest hook.

Where a local-first, open-source proxy fits

Charles and Proxyman are the tools most macOS developers already know, and they're good at what they do. The table below isn't a takedown — it's where Rockxy sits relative to them, as of June 2026, named for context only.

Everything Rockxy does runs on your machine, against open-source code you can read. The model-API streaming formats, the MCP transports, and the local-LLM defaults referenced above all come from primary sources — Anthropic and OpenAI streaming docs, the Model Context Protocol specification, and the Ollama, LM Studio, and vLLM docs. If a claim here matters to you, the source is one click away.

Frequently asked questions

The takeaway

AI changed what we build, and it changed what we have to debug — but it didn't change where the truth lives. Agents, MCP tools, local models, and distributed services all leave a trail of real HTTP, WebSocket, and Protobuf traffic. Read that trail on your own machine, in a native app you can audit, and most "mysterious" AI behavior stops being mysterious. That's the whole pitch.