Idea: Should Rockxy support both direct AI chat and MCP?

[LocNguyenHuu]

Rockxy now has MCP support, which lets tools like Claude Desktop or Claude CLI inspect captured traffic through the local MCP server.

That is useful, but I also want to discuss whether Rockxy should support a direct AI chat inside the app.

Sometimes I just want to select a request and ask:

• Why did this AI request fail?
• What changed between these two responses?
• Why is the streaming response slow?
• Did the tool call fail because of my request or the provider?
• Can you explain this error using the captured traffic?
• Which request should I replay to reproduce the problem?

With direct chat, Rockxy could automatically use the selected request, AI inspector data, headers, body, timing, errors, replay results, and related traffic as context.

The main question is: should Rockxy support both approaches?

Option 1: MCP only

Users continue using Claude, Cursor, or another MCP-compatible client.

This keeps Rockxy focused on traffic debugging, but it requires users to configure another AI tool and switch between apps.

Option 2: Direct AI chat only

Rockxy provides its own chat panel and connects directly to a selected AI provider or local model.

This would be easier for quick investigations, but it could duplicate some of the work already handled by MCP.

Option 3: Support both

Rockxy could provide a simple direct chat for quick debugging while keeping MCP for advanced users and external AI workflows.

Ideally, both would use the same Rockxy context and permission system. The difference would mainly be where the conversation happens:

• direct chat inside Rockxy;
• external chat through MCP.

I think this might be the most useful direction, but I am not sure if it creates too much complexity or maintenance work.

Privacy is also very important because captured traffic may contain prompts, tokens, cookies, credentials, customer data, or private tool payloads.

Any direct chat feature should:

• redact sensitive data by default;
• show what context will be sent before sending it;
• clearly show which provider or local model is being used;
• keep API keys in the macOS Keychain;
• avoid saving conversations unless the user chooses to;
• make local-model and remote-provider usage clear;
• require confirmation before replaying requests, changing rules, exporting data, or performing other actions.

The first version could be read-only. It could explain the captured traffic and link back to the relevant request or inspector tab. Later, it could suggest actions such as replaying a request or creating a rule, but those actions should always require approval.

I’d like to hear what people think:

• Should Rockxy support both direct AI chat and MCP?
• Would you use direct chat inside Rockxy?
• Is MCP enough for this workflow?
• Which providers or local models should be supported?
• Should both features use the same context and permission system?
• What information should be included by default?
• Should the first version only answer questions, or also suggest debugging actions?
• Where would direct chat fit best: inspector panel, separate workspace, or a chat window?
• Are there other approaches we should consider?

The goal is not to turn Rockxy into another general-purpose AI chat app. The goal is to make AI-assisted network debugging easier while keeping the workflow local-first, transparent, and under the user’s control.

Related work:

• Discussion #203 — AI-aware debugging views
• #36 — Design Rockxy’s local MCP debugging workflow
• #134 — MCP permissions and audit history
• #135 — Consent-gated MCP actions
• #174 — Redacted AI/Web3 summaries through local MCP