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?Documentation Index
Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
Use this file to discover all available pages before exploring further.
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 areproxy_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
Open the logs
Go to Logs. Entries are sorted newest-first by Created at.
Locate a tool call
Find a row whose Method is
tools/call. Sort or filter by a column — User email, Outbound gateway name, or Feature name (the tool) — to narrow a busy log to the call you care about.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.
.png?fit=max&auto=format&n=gKqTvJPtsRi2bLNx&q=85&s=8abbce3efb590630de2102c43d32aadf)
.png?fit=max&auto=format&n=Dy9YsIECUbR9JZiT&q=85&s=a1f404cd7f7aeb1727c89d81137ae1ac)