A request to /api/checkout comes back 500. You open your AI assistant, describe the failure, and it asks to see the request. So you copy the URL, then the headers, then the JSON body — except you paste the trimmed body, forget the Authorization header, and mistype the status code. The assistant reasons about a request that never happened, and you iterate blindly.
The outcome of this guide removes the copy-paste loop entirely. Rockxy captures the real request and response on your Mac; its built-in local MCP server lets an AI assistant read that captured flow directly. Instead of you narrating the request from memory, the assistant lists your flows, opens the failing one in full, replays it with a changed header, and diffs the two responses — against the actual bytes Rockxy recorded.
What MCP gives an AI assistant here
MCP (Model Context Protocol) is the open standard that lets an AI client call tools exposed by a local server. Rockxy is that server. If you want the background, What Is an MCP Server? explains the concept, and the shortlist of MCP servers for API debugging puts Rockxy in context. This post is the practical part: with the server connected, a captured flow becomes something the assistant can query.
Rockxy exposes exactly four tools over MCP, and each maps to a debugging move you already make by hand:
list_flows— a filtered list of captured flows, so the assistant can find the call you mean without you scrolling.get_flow_detail— the full request and response for one flow id: method, URL, every header, the body, the status, the timing.replay_request— re-execute a captured flow, optionally overriding the header, body, or URL, to test a hypothesis.diff_flows— a structural diff of two flows: header, body, status, and timing deltas.
The point is that the assistant works from what was actually sent and received, not from your paraphrase of it.
Where your captured data lives
Local MCP is 100% free and unlimited in the Free tier. No license upgrade required. The workflow is local-first and user-controlled. Rockxy's MCP server binds to localhost only, and your captured request and response data lives in a local store on your Mac. Rockxy itself never uploads your captured traffic to an AI provider.
One honest caveat, stated plainly: the AI assistant you connect may include the data it retrieves through these tools in its own prompts to its own provider. That is your choice, per tool. If a flow holds a production token or customer PII, decide before you point an assistant at it. Rockxy's MCP documentation covers the current capabilities, and Redaction can strip sensitive fields from captures before anything reads them.
What you will need
- Rockxy on macOS 14 (Sonoma) or later. It is a native app; download it from the Rockxy download page.
- At least one captured flow — the failing request you actually want to debug. If your traffic list is empty, capture it first before connecting an assistant.
- An MCP-capable AI client. Rockxy's local MCP works with tools that speak MCP: Claude by Anthropic, ChatGPT by OpenAI, Gemini by Google, Cursor, GitHub Copilot by Microsoft, and Continue.
- Two minutes to connect the client to Rockxy's local MCP server. The step-by-step for one client is in Connect Claude Desktop to Rockxy; the same shape applies to the others.
Step 1 — Capture the failing request in Rockxy
The assistant can only see flows that exist. Start Rockxy, confirm capture is on, and reproduce the failure once so it lands in the traffic list — the 500 from /api/checkout, in this example. If the request never appears, that is a capture-routing problem, not an MCP one; the localhost capture guide covers the loopback case, which is the most common reason a local request is missing.
What you should see in Rockxy: a row for the failing call with its method, host, path, and status. Select it and confirm the request and response detail is populated. If the row is there and readable, the assistant will be able to reach it.
Step 2 — Enable Rockxy's local MCP server and connect a client
Turn on Rockxy's local MCP integration, then point your AI client at it. The exact toggle location and the per-client connection details live in the MCP documentation and, walked through for one client end to end, in Connect Claude Desktop to Rockxy. Whichever client you use — Claude, Cursor, Copilot, Continue, or another — the connection exposes the same four tools.
Once connected, confirm the client can actually see the server. Ask it something that requires a tool call rather than a guess:
List the last few flows Rockxy has captured and show their status codes.If the assistant returns real hosts and paths from your traffic list — not a generic explanation of how proxies work — the list_flows tool is wired up and you can trust the rest.
Step 3 — Ask the assistant to read, replay, and diff the flow
Now hand the assistant the actual task in one prompt. The wording below drives all four tools in sequence:
Find the last 500 to /api/checkout, show its request and response body,
replay it with a fixed Authorization header, and diff the two responses.Behind that sentence, the assistant walks a chain you would otherwise run by hand. It calls list_flows filtered to the failing call, then get_flow_detail to read the exact request the client sent and the response your server returned. It calls replay_request with the corrected header to re-run the call, and finally diff_flows to compare the original 500 against the replay. If the replay comes back 200, the diff points straight at the header that mattered, and you have a fix instead of a guess.
You can steer each move separately too. "Read flow 42 and tell me why the body was rejected" is just get_flow_detail. "Replay it with amount set to 0" is a single replay_request override. Small prompts keep you in control of what the assistant touches.
What you should see in Rockxy
Two checkpoints tell you the workflow is real, not the assistant improvising. First, the detail it reports back — headers, body, status, timing — must match what you see when you select the same flow in Rockxy's traffic list. If the numbers agree, it read the capture. Second, when the assistant calls replay_request, a new row appears in Rockxy's traffic list for the replayed call. That fresh row is proof the replay executed against your service rather than being described in prose. The screenshot below shows Rockxy's local MCP integration exposing captured flows to an AI assistant.
If it does not work
The assistant explains proxies instead of listing your flows. It is answering from general knowledge because no tool call reached Rockxy. Confirm the MCP server is enabled in Rockxy, that the client is pointed at it, and that the client actually shows the Rockxy tools as available. The MCP documentation lists the connection requirements.
list_flows returns nothing. There is nothing captured yet, or the failing request never reached Rockxy. Reproduce the call with capture on and check that a row appears in the traffic list before asking the assistant again. For a local service that skips the proxy, see the localhost capture guide.
The replay row never appears. If the assistant claims it replayed the request but no new row shows in Rockxy, the replay_request call did not execute — treat the assistant's "done" as unverified until the row is there. Re-run the prompt and watch the traffic list.
The assistant is confidently wrong about a value. Open the same flow in Rockxy and read it yourself. The capture is the source of truth; the assistant's summary is not. When they disagree, the flow detail wins.
Limitations to keep in mind
- The assistant only sees what you have captured, and only after you enable the workflow. No capture, no context.
- The connected AI provider may receive the data the tools return. That is your choice per tool; redact or avoid sensitive flows accordingly.
- Replaying a non-idempotent request has real side effects. A replayed
POST /api/checkoutcan charge a card or create a record — replay against a safe environment, not production, unless you mean it. - Rockxy is macOS-only today. The MCP workflow runs on your Mac; there is no Windows or Linux build.
Next steps
The shift is small but real: instead of narrating a request into a chat box and hoping you copied it right, you let the assistant read the flow Rockxy already captured, replay it with a change, and diff the result. The four tools — list_flows, get_flow_detail, replay_request, diff_flows — cover read, re-run, and compare, and the capture stays on your Mac the whole time.
From here, wire up your client with Connect Claude Desktop to Rockxy, get the concept underneath it from What Is an MCP Server?, and when you want to compare two responses by hand rather than through an assistant, read how to diff two API responses on macOS. The MCP documentation tracks the current tool set. If you have not installed Rockxy yet, start at the download page.
