> ## 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.
# Trace a tool call in your logs
> A hands-on MCP Manager lesson in observability: follow the four correlated entries of one tool call, open a log entry to read its body and headers, and answer who did what, when, and through which tool.
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](/deployment/rbac-and-roles/capabilities).
## 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](/tutorials/first-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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','actorBkg':'#aed8ff','actorBorder':'#0b4880','actorTextColor':'#062b4c','signalColor':'#6a6b76','signalTextColor':'#12141d','noteBkgColor':'#fff8e4','noteBorderColor':'#ffa535','noteTextColor':'#12141d'}}}%%
sequenceDiagram
participant C as 🤖 AI client
participant G as 🛡️ MCP Manager gateway
participant S as 🖥️ MCP server
C->>G: proxy_request_success
G->>S: mcp_request_success
S->>G: mcp_response_success
G->>C: proxy_response_success
```
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
Go to [Logs](https://app.mcpmanager.ai/settings/logs). Entries are sorted newest-first by **Created at**.
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.
Note that row's **Correlation id**, and find the other entries that share it. Together they are the complete journey of that one call across all four legs.
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](/features/viewing-logs#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](/tutorials/first-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](https://app.mcpmanager.ai/settings/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](/enterprise/export-to-siem).
## Further reading
Generate logged, attributed traffic from code instead of a client.
The complete reference: every column, the correlation model, retention, and scoped views.
Aggregate usage and trends built on top of this log data.
Stream logs to Datadog, Splunk, and other destinations for long-term retention.