Overview
The Session Replay Viewer is a detail drawer on the Call Logs page that shows the full HTTP conversation for any tool call: the exact outbound request GetMCP sent to the upstream API and the exact raw response it received back.
This gives you the same visibility as a network proxy — directly inside the WordPress admin panel — without configuring any external tooling.
Enabling Session Replay
The Request (MCP arguments) and Response (MCP content blocks) stages are always captured. To also capture the raw Outbound HTTP request and Upstream HTTP response stages, enable Log Response Data in GetMCP → Settings → General.
HTTP-level captures can be large depending on the APIs your tools call. Enable this setting only when you need detailed debugging, and rely on the log retention period to keep storage under control.
replay_data JSON blob alongside the standard log entry. This blob contains the full outbound request and the raw upstream response.
Accessing the Replay Drawer
- Go to GetMCP → Logs.
- Click any row in the log table to open the detail panel on the right.
- The detail panel shows four collapsible stages covering the full data flow.
The Four Replay Stages
Each stage is a collapsible accordion item. The two MCP-level stages (Request and Response) open by default — they are always available. The two HTTP-level stages (Outbound HTTP request and Upstream HTTP response) are collapsed by default and only render when Log Response Data is enabled (see Enabling Session Replay above).
Request
The MCP tools/call arguments the AI client sent. Always available — no settings required.
| Field | Description |
|---|
| Tool | Name of the tool that was called |
| Arguments | JSON of the arguments supplied by the AI client |
Outbound HTTP request
The exact HTTP request GetMCP made to the upstream API. Only present when verbose logging was on at the time of the call.
| Field | Description |
|---|
| Method | HTTP method (GET, POST, etc.) |
| URL | Full URL including query parameters |
| Headers | All request headers — sensitive values (Authorization, API keys, cookies) are masked with *** |
| Body | Request body (truncated at 64 KB; a body_truncated flag marks shortened payloads) |
Auth headers are masked in replay data before storage. The original credentials are never written to the database.
Upstream HTTP response
The raw HTTP response from the external API. Only present when verbose logging was on at the time of the call.
| Field | Description |
|---|
| Status | HTTP status code |
| Headers | Response headers (e.g. content-type, x-rate-limit-remaining) |
| Body | Raw response body (truncated at 64 KB; a body_truncated flag marks shortened payloads) |
Response
The final MCP content blocks delivered to the AI client — the same payload the AI used as the tool result. Always available.
The Replay in Tool Editor button (available in the detail panel) opens the Tool Editor pre-filled with:
- The same tool that was called
- The same arguments that were sent
This lets you iterate on the tool’s response mapping, JMESPath expression, or template without needing the AI client to call the tool again. Useful for:
- Debugging why a tool returned unexpected output
- Refining a JMESPath selector against real production data
- Reproducing a reported error with the exact original inputs
Storage and Retention
Replay data is stored in the replay_data column of the wp_getmcp_call_logs table as a LONGTEXT JSON blob. It follows the same log retention setting configured at GetMCP → Settings → General → Log Retention Days.
Replay data is not included in the Immutable Audit Log signature — so enabling or disabling the replay feature does not invalidate existing log signatures.
When Replay Data is Not Available
Replay data may be absent for a log entry when:
| Reason | Detail |
|---|
| Log Response Data disabled | Setting was off when the call was made |
| Cache hit | Response was served from the transient cache; no upstream HTTP call was made |
| Execution error before HTTP | Tool failed during parameter resolution or auth injection, before making a request |
| Migration | Log was created before the replay_data column was added (DB version < 1.14) |
