Skip to main content
An audit trail is only useful if you can read it. This tutorial walks one tool call through MCP Manager’s logs from end to end: you’ll see the four entries a single call produces, follow them by their shared correlation ID, and open one to read its body, headers, timing, and — the part that matters most — the person it’s attributed to. By the end you can answer the question every auditor, board, and regulator asks: who accessed what, under which permissions, for what purpose?
This tutorial uses View and export logs. If you don’t see the Logs page, your role lacks that capability — access depends on the capability, not on a role name. See the capabilities reference.

​
What you’ll need

  • A gateway you’ve called at least one tool through. If your log is empty, run Your first governed tool call to generate some traffic.
  • About 10 minutes.

​
One call, four log entries

A single MCP message doesn’t produce one log row — it produces four, one for each leg of its journey through the gateway. All four share the same Correlation id, which is how you reassemble the round trip. The four Type values are proxy_request_success (the client’s request reaching the gateway), mcp_request_success (the gateway forwarding to the server), mcp_response_success (the server’s reply), and proxy_response_success (the gateway returning to the client). Reading them in order tells you exactly where time went and where anything failed.

​
Step 1: Open the logs and find your call

1

Open the logs

Go to Logs. Entries are sorted newest-first by Created at.
2

Locate a tool call

Find a row whose Method is tools/call. To narrow a busy log, hover a cell holding the value you want and click the ⋯ button that appears, then Filter by this value — pivoting on User email, Outbound gateway name, or Feature name (the tool) takes two clicks this way. The filter builder above the table does the same thing when you need to combine several conditions.
3

Follow the correlation id

Hover the row’s Correlation id cell, click ⋯, and choose Filter by this value. The table now holds only the entries sharing that ID — typically four, one per leg — which together are the complete journey of that one call.
Every entry also carries a Trace id shared across all four legs — the same grouping as the correlation ID, but the W3C trace ID your observability backend understands, so it’s the value you pivot on once logs are forwarded to a SIEM. Rule-engine legs additionally carry their own Span id. See Trace and span IDs.

​
Step 2: Open a single entry

Click any row to open Log details. It has three sections:
  • Fields — the structured facts: Type, Method, Created at, Duration (in milliseconds), Response code, Outbound gateway name, Inbound server name, User name, and Feature name. This is where attribution lives — the call is tied to a named person, a specific gateway, and a specific server.
  • Body — the request or response payload for that leg, formatted for reading. This is the tool’s actual input or output.
  • Headers — the request or response headers for that leg.
Attribution holds even when a server uses a shared service account. MCP Manager records the real human who made each call — User name, User email, and a user GUID — regardless of which upstream identity the server itself used. The audit answers “which person,” not just “which account.”

​
Step 3: Answer the audit question

With one entry open and its correlated siblings in view, you can now state, for that call: who (the user fields), what (the method and feature/tool, with the body as evidence), when (the timestamp and duration), and through which gateway and server (the gateway and server fields). If a gateway rule acted on the call, the Rule engine type and rule comment fields name it, and the entry’s type reflects it (policy_enforced_mutation or policy_enforced_abort).
You took a single tool call, reassembled its four legs by correlation ID, opened one to read its payload and timing, and tied it to a real person. That’s the whole job of the audit trail — and it’s the evidence behind “who accessed what, under which permissions, for what purpose.”

​
Step 4: Get the data out

For analysis or retention beyond the in-product window, click Export button from the Logs page; completed exports appear under Export History. The in-product retention and download windows depend on your plan. For continuous, long-term retention in your own systems, stream logs to a SIEM — see Export to SIEM.

​
Further reading

Run a headless agent

Generate logged, attributed traffic from code instead of a client.

Viewing Logs

The complete reference: every column, the correlation model, retention, and scoped views.

Reporting

Aggregate usage and trends built on top of this log data.

Export to SIEM

Stream logs to Datadog, Splunk, and other destinations for long-term retention.