Alerts

What the MCP Manager Alerts page surfaces — the error, warning, and info events it raises, what triggers each one, what an alert record contains, and how alerts differ from logs and reporting.

The Alerts page in MCP Manager is the workspace-wide feed of notable events that an administrator should know about — authentication failures on a connected server, and the outcomes of policy rule engines configured on your gateways. Open it from the Alerts link in the left-hand navigation at Alerts. Each alert is a stored record you can open, read, and use to jump straight to the server, gateway, policy, or connection it concerns.

If you don’t see an Alerts link in your left-hand navigation, your role doesn’t have the See all alerts capability. Access to the Alerts 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 alerts.

Alerts are in-app only today. MCP Manager does not yet send alerts by email, Slack, or webhook — there is no proactive notification. To learn about a new alert, open the Alerts page. Treat it as a feed you check, not a channel that pages you.

How alerts differ from logs and reporting

The Alerts page, Viewing Logs, and Reporting draw on the same gateway activity but answer different questions:

• Logs capture every individual request and response passing through a gateway — the complete per-message record.
• Reporting aggregates that activity into trend charts — what was called, by whom, how fast.
• Alerts call out a small set of notable events — things that failed or that a policy flagged — that warrant an administrator’s attention.

An alert is the exception worth surfacing; a log is the full transcript. When an alert fires, the logs are where you find the surrounding request detail.

What an alert record contains

Every alert is a stored record with the same shape, designed so you can start diagnosing the problem from the alert alone:

• A subject and message — a plain-language summary of what happened (for example, “Failed to refresh features for …”).
• A code — a machine-readable identifier in the form type.category.subcategory, where type is one of error, warning, or info. The code groups the alert by severity and source. See What triggers an alert.
• A debug context — the technical detail an engineer would need to diagnose the cause. For a failed HTTP call this includes the response status code, the response headers, and the response body. Long values (headers and bodies) are truncated in the panel and offer a copy button for the full value.
• Related-resource links — navigation shortcuts to the server, identity, gateway, gateway-server assignment, policy, rule engine, and connection involved (see Navigating from an alert).

Alerts do not have a resolved state. An alert is a record that an event occurred; MCP Manager does not track whether you have acted on it, and there is no “mark as resolved” action. Old alerts remain in the list until removed.

What triggers an alert

MCP Manager raises an alert for the following events. Each row shows the alert’s code and what causes it. Warnings come from gateway policy enforcement; errors come from connected-server failures.

Code	Severity	What triggers it
warning.gateway.policy_triggered.tool_response	Warning	A policy rule on a gateway flagged a tool response while enforcing your configured policy.
warning.gateway.rule_engine_misconfigured	Warning	A policy references a rule engine whose URL is missing or invalid, so the engine cannot be reached.
warning.gateway.rule_engine_error_verdict	Warning	A configured rule engine failed at request time (for example, returned an error or timed out).
error.inbound_server.oauth_callback_failed	Error	The OAuth token exchange with a connected server failed during the authentication callback.

A few behaviors are worth calling out explicitly:

• A rule-engine error does not block the request. When a rule engine fails at runtime (warning.gateway.rule_engine_error_verdict), MCP Manager records the alert but does not automatically block the call — the policy’s own failure mode decides whether the request passes or is blocked.
• Engine alerts are deduplicated for 30 minutes. To prevent a misconfigured or failing engine from flooding the feed, MCP Manager raises at most one rule_engine_misconfigured and one rule_engine_error_verdict alert per engine per 30-minute window. Policy-trigger and OAuth-callback alerts are not deduplicated and are recorded each time they occur.
• Alerts are workspace-scoped. The Alerts page shows alerts for the whole workspace (organization), not per-user. There are no on-page filters to scope by gateway, server, or user.

Viewing and navigating alerts

The Alerts page lists alerts in a paginated table, ordered by when they were created, with the most recent at the top. Each row shows the alert’s subject and message and its creation date. Selecting a row opens a detail panel with the full message, the debug context, and the related-resource links.

The table loads 50 alerts per page by default; you can switch the page size to 100 or 250. Pagination preferences are remembered for this page.

Navigating from an alert

The alert detail panel links to the resources the alert concerns, so you can go straight from the event to the thing that caused it. Depending on the alert, the panel offers links to:

• the MCP server involved,
• the connected-server identity that failed,
• the gateway that processed or blocked the call,
• the gateway-to-server assignment,
• the policy whose rule triggered (opens the gateway’s rules),
• the rule engine referenced (opens the Rule Engines list, where you can find the engine by its ID — there is no per-engine deep link yet), and
• the connection involved, along with the user who established it (shown by name and email).

A link appears only when that resource is attached to the alert. Each alert also has its own URL, so you can share or bookmark a specific alert.

Who can see alerts

Access to the Alerts page is controlled by a single capability. Under the Capabilities tab when managing a role (in People), the Alerting group contains one capability:

Capability	What it allows
See all alerts	View all alerts in the workspace and open the Alerts page.

When a user’s role has See all alerts, the Alerts link appears in their left-hand navigation and they can open every alert; 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 alert debug context can include request and response data, grant See all alerts only to the roles that should see that detail.

Further reading

Viewing logs

The full per-request record behind an alert, with scoped views and export.

Reporting

Workspace-wide trend charts for activity, performance, and error rates.