Skip to main content
The Proxy module is the CTPF observation center: transparent interception of Model Context Protocol (MCP) traffic so you can inspect tool calls, modify messages in flight under control, and export sessions for evidence.

​
When to Use the Proxy

The proxy is a client-side interception tool. It sits between an MCP client and an MCP server, and the person running the proxy must control the client — because the client is what gets configured to route traffic through the proxy. The target server is unaware of the proxy’s presence. This means the proxy works when:
  • You control the MCP client. Configure Claude Desktop, Cursor, an agent framework, or other MCP clients you operate to route through the proxy for observation, self-assessment, or debugging.
  • Library tooling drives a client you control. Research fixtures (for example inject fixture servers or custom clients) may open MCP connections that you can point through the proxy. The proxy does not depend on removed root commands such as qai audit or qai inject.
The proxy does not work when the MCP client belongs to the target. If a remote platform’s internal MCP client makes the tool calls, you cannot configure that client without modifying the target. In those scenarios, use other evidence sources (IPI callbacks, agent response content, conversation logs) instead of proxy capture.
Once positioned in the traffic path, the proxy lets you:
  • Inspect tool calls — See exactly which tools are being invoked and with what parameters
  • Modify messages — Alter requests or responses mid-session for controlled CTPF experiments
  • Replay sessions — Re-send captured messages against different server implementations
  • Drop messages — Intercept and discard specific tool invocations during manual testing

​
Core Concepts

​
Session Capture

The proxy operates as a transparent man-in-the-middle positioned between your client and server. Every message in both directions flows through the proxy envelope:
  • ProxyMessage — Wraps each JSON-RPC message with proxy metadata (timestamp, sequence number, direction, transport type)
  • ProxySession — Captures the complete sequence of messages across a single interaction, serializable to JSON for storage and replay

​
Operating Modes

Passthrough Mode (default)
  • All messages flow through unobstructed to their destination
  • Passive capture and monitoring without latency overhead
  • Use for baseline traffic recording
Intercept Mode
  • Messages are paused and held for user inspection
  • User can FORWARD unchanged, MODIFY with edits, or DROP entirely
  • Interactive TUI-based control
  • Useful for targeted analysis of specific interactions — including live mutation of server→client tool results

​
Transport Support

The proxy bridges three MCP transports:
  • STDIO — Local processes communicating via stdin/stdout
  • SSE — HTTP servers using server-sent events
  • Streamable HTTP — Bidirectional HTTP for modern MCP implementations

​
Typical Workflow

  1. Start the proxy with your target server details and optionally enable intercept mode (ctpf proxy)
  2. Configure the MCP client you control to connect to the proxy instead of directly to the target server
  3. Watch messages in real-time via the interactive TUI
  4. Toggle intercept mode to halt and inspect specific interactions
  5. Forward, modify, or drop messages as needed
  6. Export the completed session for evidence or later analysis

​
What to Expect

Proxy is interactive. It captures and replays traffic but does not produce automated vulnerability findings. The researcher observes, inspects, and optionally modifies messages in real time. Session recordings provide evidence for later analysis; the analysis itself is manual. Live mutation of server→client tool results is a first-class research path. Full agent counterfactual replay is not assumed.

​
Next Steps