charles-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHARLES_MCP_ALLOW_BODIES | No | Set to 1 to enable request/response bodies. Bodies are off by default. Example: claude mcp add charles --env CHARLES_MCP_ALLOW_BODIES=1 -- charles-mcp | |
| CHARLES_MCP_DISCOVERY_FILE | No | Path to a discovery file to use, e.g. for development with the mock bridge: CHARLES_MCP_DISCOVERY_FILE=./mock.json charles-mcp |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_statusB | Bridge connectivity, Charles version, recording state, queue/drop counters and active safety settings. |
| list_requestsB | List captured requests (compact summaries, redacted URLs) with filters and cursor pagination. |
| get_requestC | Request line, headers (redacted), timing, sizes and optionally the bounded/redacted request body. |
| get_responseC | Status, headers (redacted), timing, TLS/connection info and optionally the bounded/redacted response body. |
| search_trafficB | Bounded search over redacted URLs, headers and (if enabled) bodies of recent traffic. |
| get_session_summaryC | Counts by host/method/status, recent errors and total sizes for indexed traffic. |
| watch_requestsB | Raw lifecycle events (request_created ... response_complete/failed) since a cursor. This is a pull: call it again with next_after to get newer events; it does not stream. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
The tools mostly target distinct inspection needs: status, compact listing, single request, single response, search, aggregate summary, and lifecycle events. Some overlap exists between list_requests, search_traffic, and watch_requests, but their descriptions clarify filtering, bounded search, and cursor-based event pulling respectively.
All names use consistent snake_case and a clear verb_noun pattern such as get_status, list_requests, get_request, and search_traffic. The set is predictable and easy to scan.
Seven tools is well-scoped for a traffic inspection server, covering listing, detail views, search, summary, status, and event watching without obvious redundancy. Each tool has a clear place in the inspection workflow.
The surface covers the core read-only inspection lifecycle, including status, captured requests, request/response details, search, summary, and live event polling. It lacks control or maintenance operations such as starting/stopping recording, clearing traffic, or exporting captures, but those may be intentionally out of scope.