Viewing Logs

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.

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 three 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 you have generated, with their status and a link to download each finished file.
• Integrations — where you configure forwarding of logs downstream to an OpenTelemetry-compatible collector.

​

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 and filter the table by its columns to narrow down what you are looking at.

​

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.

​

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.

​

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 several columns can be used to filter the table.

• 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.
• 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.
• 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.
• 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.
• body — message body, when available.
• 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, and the feature involved — 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.

​

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.
• 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 export will be. Generating the file is an asynchronous action: MCP Manager produces the report in the background and sends it to your email address when it is ready, rather than blocking the page while it runs.

​

Export History

The Export History tab lists every log export you have generated. For each entry it shows the status of the export and provides a button to download the finished file directly. Use this tab to retrieve a file you requested earlier or to check whether an export you triggered has finished generating.

​

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 by your plan: plans start at 14 days of retention and extend to a year or more at higher plan levels. 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 remains available for download after MCP Manager creates it, before it is removed from our servers. This applies to the files produced by the export action, not to the underlying log data, and the exact window is shown to you in the interface.

​

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