Skip to main content
The Reporting page in MCP Manager turns the activity flowing through your gateways into charts. Open it from the Reporting link in the left-hand navigation at Reporting. Every chart is computed live from your MCP logs — the same request and response records documented in Viewing Logs — aggregated across the whole workspace, so Reporting is the at-a-glance view and the logs are the per-message detail behind it.
If you don’t see a Reporting link in your left-hand navigation, your role doesn’t have the View reports capability. Access to the Reporting page — and whether the link appears at all — is controlled by that capability. Ask whoever manages roles in your workspace to grant it. See Who can see Reporting.
The page has two tabs:
  • Reports — feature usage, performance, and error dashboards for the last 31 days. This is the default tab.
  • Usage — message and connection volume over a longer horizon, oriented toward tracking overall consumption.

How Reporting relates to your logs

Every Reporting chart is an aggregate query over your MCP log data, run when you open the page, scoped to your workspace (organization). Reporting reads the same records shown in Viewing Logs; it does not maintain a separate data store, so charts reflect logged activity in near real time. Two consequences follow from this:
  • Reporting history is bounded by your log retention period. A chart can only show activity that still exists in your logs. If your plan’s retention period is shorter than a chart’s window, the older buckets in that chart will be empty. See how long logs stay available.
  • Token figures are estimates. Charts that count tokens use the same approximate tokenizer as the logs (the o200k_base encoding); the values are consistent guidance, not an exact match for the tokenizer your LLM uses. See the token estimate note.

The time window is fixed

The Reports tab summarizes the last 31 days (inclusive of today). The daily Usage chart also covers the last 31 days, and the monthly Usage charts cover the last 12 months. These windows are fixed: the Reporting page has no date-range picker, so you cannot widen, narrow, or shift the period from the UI. A chart with no logged activity in its window displays “No data available” rather than an error.
The Reporting page shows workspace-wide aggregates. There are no on-page filters to scope a chart to a single gateway, server, host, user, or feature, and there is no per-chart download/export. To inspect the underlying records, or to export a scoped slice, use Viewing Logs and its scoped views and export.

The Reports tab

The Reports tab opens with four KPI tiles that count the key objects in your workspace, followed by a grid of feature, performance, and error charts covering the last 31 days.

KPI tiles

Four count tiles sit at the top of the Reports tab. Three of them are shortcuts — selecting them navigates to the matching settings list — and one is display-only:

Reports charts

The Reports tab renders the following charts, each summarizing the last 31 days. The descriptions state what each chart measures; “feature calls” means calls to tools, prompts, and resources. The two latency charts pair deliberately: median duration tells you the typical experience, while 95th percentile duration surfaces the slow tail that a median hides. Read them together when you are investigating performance, and use Error codes by MCP server and Response Codes together to separate where errors occur from what kind they are.

The Usage tab

The Usage tab focuses on overall consumption volume rather than individual features, and is the place to track message and connection trends over time. Unlike the Reports tab, the Usage charts count all messages, not just successful feature calls — so they reflect total traffic through your gateways, including non-feature protocol messages.

Who can see Reporting

Access to the Reporting page is controlled by a single capability. Under the Capabilities tab when managing a role (in People), the Reporting group contains one capability: When a user’s role has View reports, the Reporting link appears in their left-hand navigation and they can open every chart; when their role does not, the link is hidden and the page is unavailable to them. Capabilities are assigned per role and are fully configurable — including on any custom roles you create — so whether a given person has access depends on the capabilities granted to their role, not on any fixed role name. Because the charts can reveal who is using which features and how often, grant View reports only to the roles that should see that activity data.

Reporting and Alerts

Reporting summarizes activity — what was called, by whom, how fast, and with what response codes. For notifications about notable events — errors and the outcomes of rule engines configured on your gateways — see Alerts. Reporting and Alerts both draw on the same underlying gateway activity but answer different questions: Reporting is the trend dashboard, Alerts is the event feed.

Further reading

Viewing Logs

The per-message request and response records every Reporting chart is derived from.

Alerts

The event feed for errors and rule-engine outcomes, alongside the Reporting trends.