Your agent should read the request, not your description of it.

The problem it solves

Debugging a failing request with an AI agent usually means copying a cURL command out of devtools, pasting it into a chat window, and hoping you grabbed the right header. The agent reasons about your description of the traffic. If the description is wrong — and the reason the request is failing is usually that something is not what you think it is — the answer is wrong too.

Charlotte removes the copying step. It sits as a proxy on your own machine, decrypts HTTPS from any client you point at it, and serves the captured flows to your agent as structured data. The agent reads the actual bytes.

2. Connect your agent

Claude Code

Charlotte speaks streamable HTTP, so a single command is enough:

claude mcp add --transport http charlotte http://127.0.0.1:8765/ \
  --header "Authorization: Bearer YOUR_TOKEN"

On Windows (version 1.0.12 and later) the server requires an access token, so that no other program on your PC can read your traffic just because the server is running. Charlotte's Settings → AI agents screen shows the token with a copy button — paste it in place of YOUR_TOKEN above.

Add --scope user to make it available in every project rather than just the current one. Check it connected with claude mcp list.

Claude Desktop, Cursor, and other stdio clients

Clients that launch the server as a subprocess use Charlotte's stdio bridge, which relays JSON-RPC to the running app and streams live capture events back. The bridge reads the access token itself, so there is nothing extra to configure here.

Windows. The executable lives under a versioned WindowsApps path, so don't type it by hand — Charlotte's Settings → AI agents screen shows the exact command with a copy button. It looks like this:

{
  "mcpServers": {
    "charlotte": {
      "command": "C:\\Program Files\\WindowsApps\\...\\Charlotte.exe",
      "args": ["--mcp-stdio", "--mcp-port", "8765"]
    }
  }
}

macOS.

{
  "mcpServers": {
    "charlotte": {
      "command": "/Applications/Charlotte.app/Contents/MacOS/Charlotte",
      "args": ["--mcp-stdio", "--mcp-port", "8765"]
    }
  }
}

Live capture stream

Anything that can read Server-Sent Events can watch capture happen in real time, including streaming LLM responses arriving token by token:

curl -N -H "Authorization: Bearer YOUR_TOKEN" http://127.0.0.1:8765/events

Filter with ?events=flow_chunk,flow_completed. Passwords, tokens and cookies are redacted by default.

4. Give each agent exactly the access it should have

One shared admin token was fine for one agent. Running several — a coding assistant, a CI job, a teammate's client — needs a credential per agent, each scoped to what it actually does.

Named access tokens (RBAC)

Issue one token per agent from Settings → AI agents — access control, each with a role: Viewer can read and search captured flows, Editor can also replay requests and edit rules, and Admin can do everything the app's own user can. A leaked Viewer token can never modify your traffic. Revoke one agent without touching any other's.

OAuth 2.1 with PKCE

Modern MCP clients don't have to be handed a static secret at all. Turn on OAuth and a client registers itself, then you approve its role on a consent screen — no token to copy, paste, or accidentally commit. Static tokens keep working alongside it for clients that don't support OAuth yet.

Policy, on top of roles

Enforced on every tool call, regardless of which token or role made it:

• Read-only mode — agents may inspect but never modify or replay, no matter what role their token has.
• No-PII-replay — refuses to replay any captured flow whose body looks like it carries personal data.
• Allow-list — deny everything a rule doesn't explicitly permit, instead of trusting roles alone.

A sandbox around replay

replay_flow runs inside a sandbox that blocks requests to cloud-metadata and link-local addresses (the class of target an SSRF attempt would reach for), rate-limits replays per credential, and offers a dry-run mode that shows exactly what would be sent without sending it.

An audit trail you can read

Every agent action — which credential, which tool, allowed or refused — is written to an attributable log, so "what did that agent actually do" has a real answer.

Plugins

Extend Charlotte with custom MCP tools and traffic analyzers. A JWT inspector and a security-headers analyzer are built in. External plugins are opt-in and load only when allow-listed in plugins.json with a matching SHA-256 — nothing loads because a folder happens to contain it.

Multi-device capture hub

Capture from several phones, VMs, and containers at once. Charlotte identifies each by its client address and shows it as its own named device with its own stats, with an optional dedicated port for a source a shared network would otherwise merge into the rest.

Security posture

• Loopback only. The server binds to 127.0.0.1. It is not reachable from your network.
• Role-scoped credentials. Every client presents a token — a named Viewer/Editor/Admin token or an OAuth-issued one — copied or approved from Settings. Loopback keeps the server off the network; the token keeps it scoped to the agent it was issued for. Revoke one at any time without disturbing the others.
• Off by default. The server does not run until you turn it on.
• Read-only by default. Nothing can change your traffic until you explicitly allow it — and the read-only policy can enforce that even for a token whose role would otherwise permit more.
• Credentials redacted by default. Authorization and Cookie headers, credential-named body fields and JWTs are masked everywhere an agent can read them — the live stream and the fetch, list and search tools alike. You can turn that off when the token is what you are debugging.
• Replay is sandboxed. Cloud-metadata and link-local addresses are blocked, replays are rate-limited per credential, and a dry-run mode exists for when you want to see the request without sending it.
• Every action is attributable. An audit trail records which credential did what, and whether it was allowed.
• No cloud inference. Charlotte's own AI analysis runs on-device. Your traffic is never sent to an AI service — ours or anyone else's.
• Your CA key stays put. The root CA's private key is encrypted with Windows DPAPI (or the macOS Keychain) and never leaves the machine.

Charlotte is for inspecting traffic you are authorised to inspect: your own applications and devices, or systems you have permission to test.