Viewing Logs

MCP Manager records every request and response that passes through your MCP gateways and makes them available as logs. Logs exist in two kinds of places: a central Logs page that shows activity across the entire workspace, and scoped views attached to individual servers, gateways, connections, and apps. Think of the central page as the headquarters and the scoped views as satellites that show the same data filtered to one entity.

​

Where to find logs

Open the Logs link in the left-hand navigation at Logs. The Logs page is organized into four tabs:

• Logs — the workspace-wide table of recent MCP request and response activity. This is the main view and the focus of this page.
• Export History — a record of the log exports generated in your workspace, with their status and a link to download each finished file.
• Data retention — where you set the workspace’s log storage policy: what message content the gateway keeps in your logs. See Data retention (log storage policy).
• Integrations — where you configure forwarding of logs downstream to an OpenTelemetry-compatible collector.

Which tabs you see depends on your capabilities: Logs and Export History require View and export logs, Data retention requires Manage workspace settings, and Integrations requires Manage OpenTelemetry collector (see Who can view and export logs).

​

The logs table

When you open the Logs tab you immediately see a table of the most recent log activity across all connections in the workspace, newest first. Each row is a single log entry — one leg of a message’s journey through the gateway, not a whole request/response exchange (see Log types and the correlation model). In this first version the logs are presented as a flat tabular dataset: every entry is its own row, and related entries are tied together by a shared correlation ID rather than being visually grouped into spans or traces. You can sort by any column, and narrow the table either from the filter builder above it or straight from a cell — see Filtering the logs table.

​

Filtering the logs table

Filters live in the Filters card above the logs table, and every filter you apply narrows the rows already loaded into the table rather than issuing a new query. Loading more entries widens the pool the filter runs against, so a filter that matches nothing on the first page can still match on a later one. Click the card to expand the builder, then Add a filter condition to add a row. Each row is three parts — field, operator, and value — and the operator list changes with the field you pick. The first row reads Where; every row after it carries an and / or dropdown in that position. That dropdown sets the conjunction for the whole group, so changing it on one row changes it for all of them: a group is entirely and or entirely or, never a mix. Clear all, at the right of the card, removes every condition; it appears only once at least one condition exists. Collapse the card and your conditions stay applied, shown as chips with an N applied badge so the count is visible without expanding anything. Every log table starts with a last 24 hours date filter applied, which keeps the first page fast on a busy workspace. Widen it from the time-range control above the table.

​

Operators available for each field

The operator list is determined by the field’s type, and the four sets are: A list field lets you tick several values at once, which is what makes is any of... and is none of... the defaults for it. Text fields take a single typed value, so their exact-match operator is is.... Two behaviors are worth knowing because they look like bugs otherwise. A condition with no value yet matches every row, so a half-built filter never empties the table while you are still choosing a value. And a value you have selected that does not appear in any loaded row shows as an amber chip, explaining on hover that it was “Not found in the loaded events” — most often because it arrived from a link with a typo, or because the matching entries have not loaded yet.

​

Filtering from a table cell

Hovering any cell reveals two buttons at its right edge: a copy button, and a ⋯ button that opens a menu offering Filter by this value and Exclude this value. Both add a condition to the builder with the operator already chosen for that field’s type, which makes this the fastest way to pivot onto a value you can see — a correlation_id, a user’s email, a single method. Either action is unavailable when it would change nothing or contradict a filter you already have, and hovering the unavailable row explains which: Narrowing stays available. With type filtered to two values, excluding one of them is offered, because the other one still matches.

​

Saved filter views and sharing a filtered link

A filtered view is saved to your account and the page URL carries only an opaque identifier for it — never the filter values themselves. Filter values are customer log content: email addresses, IP addresses, correlation IDs, and server names. A URL does not stay in the browser, so keeping those values out of it keeps them out of analytics, session recording, and anywhere else a pasted link travels. What that buys you, and what it costs, both follow from the view belonging to an account rather than to the link:

• Your own link works anywhere you sign in. Open it in another browser or on another machine as the same person and the filters come back, because they are stored server-side rather than in that browser.
• Sending the link to a colleague does not send them the filters. They will see a notice that the saved view is not available and the table will load unfiltered. Sharing a view between people is not supported yet, so if a colleague needs the same result, either tell them the conditions to rebuild — a matter of a few clicks with the ⋯ menu — or hand them the data instead, via an export or the Admin API, both of which carry the rows rather than a pointer to a view.
• A view lasts 60 days from the last time it was opened, and each use refreshes that window. A link you return to regularly keeps working indefinitely; one you have not opened in over two months stops resolving.

When a link names a view your account does not hold — because someone else made it, or because it has lapsed — the Filters card is replaced by a notice saying so, with a Reset button that clears the dead identifier from the URL. The table stays usable throughout and loads unfiltered.

​

Log types and the correlation model

Every log entry has a type that identifies which leg of a message’s journey it represents. A single MCP message travels four legs through the gateway, so one message generally produces four log entries that share the same correlation_id:

1. The client’s request arrives at the gateway — proxy_request_success.
2. The gateway forwards the request down to the MCP server — mcp_request_success.
3. The MCP server’s response returns to the gateway — mcp_response_success.
4. The gateway returns the response to the client — proxy_response_success.

Because each leg is logged independently, you can follow a single message end-to-end by filtering on its correlation_id and reading the four entries in order. For a hands-on walkthrough, see Trace a tool call in your logs.

​

Type values

Each leg has a success and an error variant, and additional types are recorded when policy enforcement or gateway feature filtering acts on a message. The four *_success types — proxy_request_success, mcp_request_success, mcp_response_success, and proxy_response_success — are the ones you will see most often, one per leg, for a healthy message.

​

Trace and span IDs

Alongside the correlation_id, every log entry carries OpenTelemetry trace identifiers that tie the legs of a request together and let a log pivot to a distributed trace. MCP Manager mints these for every proxied request, whether or not a traces collector is configured — see Traces and trace-correlated logs.

• trace_id — the same value on all of a request’s legs (like correlation_id, but the W3C trace ID your observability backend understands). Filter on it to gather every log in one trace.
• span_id — the span that entry represents. The client- and server-facing legs carry the gateway span; each rule-engine evaluation carries its own distinct child span, so a rule engine’s log entry can be matched to its span in a trace waterfall.
• traceparent — the W3C traceparent on that leg. On the client-facing proxy_request_success leg it is present only when the client sent one: its presence means the trace was received from the client, and its absence means MCP Manager minted the trace itself. The server-facing mcp_* legs always carry the traceparent forwarded upstream.

You can filter the table by trace_id and span_id; traceparent is shown on an entry but is not a filter column.

​

What each log column means

Each log entry carries a wide set of columns. Most are self-explanatory; the ones below are worth a note. You can sort by any column, and most columns can be filtered — see Filtering the logs table for the operators each field type offers.

• created_at — the timestamp the entry was recorded, with microsecond resolution. The table is sorted by this, newest first, by default.
• type — the leg of the journey, as described in Log types and the correlation model.
• method — the JSON-RPC method the message carried, such as tools/call, prompts/get, or resources/read.
• correlation_id — the identifier shared by the (typically four) entries that belong to one message. Use it to reconstruct a full exchange.
• trace_id, span_id, and traceparent — the OpenTelemetry trace identifiers for the entry, described in Trace and span IDs. trace_id is shared across all legs of a request; span_id identifies that leg’s span; traceparent records the W3C trace context on the leg, and signals whether the trace was received from the client or minted by MCP Manager. trace_id and span_id are filterable.
• request_id and session_id — the JSON-RPC request identifier and the MCP session identifier. These are populated only when the relevant value is available for that entry, so they are filled in sparsely depending on the log type.
• response_code and response_type — the HTTP status code and content type (for example application/json or text/event-stream) on response-leg entries.
• duration_ms — how long the leg took, in milliseconds.
• headers and body — the full headers and body of the message, captured when they are available for that entry. Whether they are stored at all depends on the workspace’s log storage policy: under Metadata only these two columns are always empty while every other column still populates, and under Zero data retention no entry is stored at all.
• token_count and tokenizer_encoding — an estimate of the message size in tokens, and the encoding used to produce it (see the note below).
• feature_type and feature_name — the kind of MCP feature involved (such as a tool, prompt, or resource) and its specific name, populated when a feature operation is being logged.
• json_rpc_version and mcp_protocol_version — the JSON-RPC version (typically 2.0) and the negotiated MCP protocol version.
• rule_engine_id, rule_engine_type, and rule_engine_comment — populated only on entries produced by a rule engine, recording which engine acted, how it classified the message (for example pass, modify, or block), and any comment it returned.

​

Names and identifiers for each entity

For each entity involved in a message, a log entry stores both a human-readable name in plain text and a globally unique identifier (GUID). The plain-text name makes the table easy to read; the GUID is the precise, stable value used for sorting and filtering so that you can scope a view to exactly one entity. The entities recorded this way include:

• Outbound gateway — outbound_gateway_name and outbound_gateway_guid.
• Host — host_name and host_guid.
• Inbound server — inbound_server_name, inbound_server_url, and inbound_server_guid.
• Inbound server identity — inbound_server_identity_name and inbound_server_identity_guid.
• Server container — server_container_name and server_container_guid.
• Connection — gateway_connection_guid.
• User — user_name, user_email, and user_guid (plus the originating ip_address).
• Organization and team — org_guid and team_guid.

Additional GUID columns capture the precise configuration in effect for the message, including gateway_assignment_guid, feature_lists_snapshot_guid, feature_list_guid, and feature_item_guid. Because not every column applies to every type of entry, columns such as request_id, session_id, the identity columns, and the rule-engine columns are filled in sparsely — populated only when that piece of information is meaningful for the given log entry.

Full column reference

Every column available on a log entry:

• created_at — timestamp the entry was recorded (microsecond resolution).
• type — which leg of the journey the entry represents.
• method — JSON-RPC method (for example tools/call).
• correlation_id — identifier shared across the entries of one message.
• trace_id — W3C trace ID, shared across all legs of one request.
• span_id — the span this entry represents (gateway, upstream, or rule-engine leg).
• traceparent — W3C trace context on this leg; absent on the client-facing leg when MCP Manager minted the trace rather than receiving it.
• request_id — JSON-RPC request identifier.
• session_id — MCP session identifier.
• response_code — HTTP status code.
• response_type — response content type.
• duration_ms — leg duration in milliseconds.
• headers — message headers, when available and permitted by the workspace’s log storage policy.
• body — message body, when available and permitted by the workspace’s log storage policy.
• token_count — estimated token size of the message.
• tokenizer_encoding — encoding used for the estimate.
• outbound_gateway_name / outbound_gateway_guid — the outbound gateway.
• host_name / host_guid — the host.
• inbound_server_name / inbound_server_url / inbound_server_guid — the inbound server.
• inbound_server_identity_name / inbound_server_identity_guid — the inbound server identity.
• server_container_name / server_container_guid — the server container.
• gateway_connection_guid — the connection.
• gateway_assignment_guid — the gateway assignment in effect.
• feature_lists_snapshot_guid / feature_list_guid / feature_item_guid — the feature configuration in effect.
• user_name / user_email / user_guid — the acting user.
• ip_address — originating IP address.
• org_guid / team_guid — organization and team.
• feature_type / feature_name — the MCP feature involved.
• json_rpc_version — JSON-RPC version.
• mcp_protocol_version — negotiated MCP protocol version.
• rule_engine_id / rule_engine_type / rule_engine_comment — rule-engine outcome details.

​

Opening a single log entry

Click any row in the logs table to open the log detail view for that entry. The detail view shows the entry’s key fields together — including its type, method, timestamp, token count, duration, response code, the outbound gateway and inbound server names, the user, the feature involved, and the trace, span, and traceparent values — and then renders the full body and headers of the message when they are available, formatted for readability. Use this when the table row alone does not give you enough context to understand what happened.

​

When the full record cannot be loaded

Opening a row fetches the complete record, because the row itself carries only a short preview of body and headers. If that fetch fails, the detail view still opens and says so at the top: Full record unavailable. The fields below that notice are the preview from the table row, so body and headers may be cut short or missing entirely. Close the entry and open it again to retry. While you are looking at a preview, any value the server cut short is labeled as such — the Body and Headers sections say the value was cut short and that its end is not shown. A record that loaded successfully never carries that label, because the full record is returned whole.

​

When the logs table cannot load

A failed request and a genuinely quiet workspace both leave you with an empty table, so MCP Manager tells them apart rather than showing “No logs found” for both.

• The first load fails. The table says that loading failed — and that the empty table is not a statement about your activity — followed by what the server returned, including the HTTP status code and the server’s own error text where it sent one. Try again re-runs the request.
• Loading more fails. The entries already loaded are kept, and a notice appears above the table with the same detail. Its Try again picks up from where the load stopped rather than starting over, so a single failed page never costs you the entries you already pulled.

​

Pagination

The logs table is paginated. You can change how many entries load at a time, choosing between 50, 100, or 250 entries per page; the default page size is 50. Your selected page size is remembered for the next time you open the table.

​

Exporting logs

The logs table includes an Export action that generates a downloadable file of your logs. When you export, you choose:

• Format — export as CSV (the default) or as ND-JSON (newline-delimited JSON), depending on how you intend to process the data downstream. CSV opens directly in spreadsheet tools; ND-JSON is easier to stream and parse record by record in a data pipeline.
• Time range — the span of logs to include. The range you can select is bounded by your plan’s log retention period: logs older than that window are not available to export (see How long logs and exports stay available).

Before the export runs, MCP Manager shows you an estimated file size and row count so you know roughly how large the file will be. The estimate updates as you switch format, because ND-JSON repeats field names on every row and so runs somewhat larger than the equivalent CSV.

​

How an export runs

Generating the file is asynchronous — MCP Manager builds it in the background rather than blocking the page, so you can navigate away and come back later.

​

Export limits

To keep exports responsive for everyone in your workspace, MCP Manager caps how many can run at once:

• Per person — you can have up to 3 exports generating at the same time. If you start another while three are still in progress, MCP Manager asks you to wait for one to finish and try again.
• Per workspace — your workspace can start up to 25 exports per day. The count resets at 00:00 UTC each day, rather than on a rolling 24-hour basis, so a workspace that hits the limit can export again after the next reset.

These limits govern how many exports you can start at a time; they do not limit how much data a single export can contain.

​

Export History

The Export History tab lists the log exports generated in your workspace, newest first. Use it to download a file you requested earlier, to check whether an export you triggered has finished, or to start a fresh copy of a previous export. Each entry shows its status, the format (CSV or ND-JSON), the row count and file size, when it was created (in UTC), and who requested it. The status is one of: Each row offers the relevant actions for its status — Download for a ready file, and Re-run to generate a new copy with the same format, time range, and filters. When you arrive from the link in an export-ready email, the matching entry’s download starts automatically.

​

Data retention (log storage policy)

The Data retention tab controls what the gateway writes to your logs, separate from how long those logs are kept. Open it at Data retention; it holds one workspace-wide setting, the log storage policy, with three levels: The policy is set once for the whole organization and takes effect on new log records within a few seconds of saving; it does not rewrite entries already stored. Because it governs what is written, a stricter level applies everywhere stored logs are used, including log exports, and cannot be bypassed by exporting: under Metadata only an export carries the metadata columns but never message bodies or headers, and under Zero data retention there are no stored logs to view or export at all. Setting anything stricter than All data requires a higher-tier plan (the Data Retention Controls add-on); on plans without it the tab still shows the options but keeps the default All data policy and points you to your MCP Manager contact. The tab itself appears only for roles with the Manage workspace settings capability.

​

How long logs and exports stay available

Two separate time windows govern log availability, and it helps to keep them distinct.

• Log retention period — how far back your stored logs go, and therefore the maximum age of a log you can view or export. This period is set at the organization level by your plan — it applies across your whole workspace, not per gateway — and starts at 14 days, extending to a year or more at higher plan levels. Retention periods longer than 12 months can be configured, subject to your plan and agreement with your MCP Manager contact. To find the plan that fits the retention you need, speak with your MCP Manager contact. For example, if your plan’s retention period is 30 days, you can export logs up to 30 days old; a log that is 31 days or older falls outside the window and cannot be exported.
• Download availability window — how long a generated export file stays downloadable after MCP Manager creates it. Every export’s download link is valid for 7 days from the moment the file finishes generating; after that the link expires and the file is removed from our servers. This window is fixed — it does not vary by plan — and applies to the export file, not to the underlying log data.

​

Scoped log views

Beyond the workspace-wide Logs page, MCP Manager makes logs available directly on the entities they relate to. Each scoped view shows the same columns as the global table but is filtered to the single entity you are looking at, and each offers its own scoped export. The scoped locations are: Each scoped export is automatically restricted to that entity, which is a convenient way to pull just the logs for one server, gateway, connection, or app.

​

Who can view and export logs

Access to logs is controlled by capabilities. Under the Capabilities tab when managing a role (in People), the Logging group contains two capabilities: View and export logs is what grants a person the ability to see logs at all: when a user’s role has it, the Logs nav link and the per-entity Logging tabs are available to them; when their role does not, those links and tabs are hidden. Capabilities are assigned per role and are fully configurable — including on any custom roles you create — so access depends on the capabilities granted to a person’s role, not on any fixed role name. Because log contents can include sensitive request and response data, grant View and export logs only to the roles that should see it. Manage OpenTelemetry collector additionally lets a person set up and maintain the downstream log-forwarding integration described in Export to SIEM.

​

Accessing log data programmatically

MCP Manager does not offer an API to pull or query logs — there is no endpoint to fetch logs programmatically, for example by session ID. To work with log data outside the MCP Manager interface, you have two options:

• Export a file — generate a CSV or ND-JSON file from the Export action and process it downstream.
• Forward logs over OpenTelemetry — stream logs to your own OpenTelemetry-compatible collector, then store and query them in your own observability platform or SIEM. See Export to SIEM.

​

Logs and Reporting

Logs are the underlying data source for the Reporting section. The charts you see under Reporting — such as feature call volume over time and feature popularity — are built from the activity captured in your logs. If you need the raw, per-message detail behind a chart, the logs are where to find it.

​

Logs versus Alerts

Logs and Alerts are related but serve different purposes. Logs capture every individual request and response that flows through the gateway, at full per-message detail. Alerts surface higher-level events to administrators — for example errors, or the outcomes of rule engines configured on specific gateways — that may warrant attention. Reach for logs when you need to trace exactly what happened on a given message; reach for alerts when you want to be notified about notable events across the workspace.

​

Further reading