MCP alerts

Be told when a gateway's backend fails, when an agent misbehaves and when a gateway exposes more tools than a model can pick from.

An MCP gateway sits between AI agents and the services behind it, so what goes wrong at a gateway is as often the agent's doing as the backend's - a tool that does not exist called five times, arguments a schema refuses, one session calling one tool in a loop. The gateway's alerts tell the two apart, and next to them stands one alert that reads no traffic at all - how many tools the gateway exposes.

The Alerts line

Alerts are the Alerts line of the wizard's step 02, What do they receive?, under More options. The line reads On or Off followed by the settings that differ from their defaults, and clicking Edit opens the popup with every setting of the gateway.

The popup has five sections, and each of its lines is one alert with the threshold and the window it reads. A line left at its default is what the tables below say.

Core

Line	Default	What it does
Active	on	Whether the gateway alerts at all
Use LLM	on	Whether each alert goes to a language model for an explanation before it is sent
LLM connection	the default one	The LLM connection the explanation is asked of
Email connection	the default one	The SMTP connection the notification goes out through

Failures

Line	Default	What it does
Failures in a row	3	The gateway's newest tool calls all failed - a JSON-RPC error, a result flagged `isError`, a rejection or a timeout. This is the backend failing and it raises an error alert
Error rate	10% in 5 minutes	The share of failed tool calls among the last ones, once there are at least ten of them in the window
Invalid tool calls	5 in 5 minutes	Calls that named a tool the gateway does not expose or passed arguments its schema refused - the JSON-RPC errors `-32601` and `-32602`. This is the agent's mistake, not the backend's, and with argument validation on it is the count of what validation turned away
Rejected responses	3 in 5 minutes	Responses a safeguard in reject mode or the size cap in block mode refused, so the agent received an error in their place

Callers

Line	Default	What it does
Rejected callers	10 in 5 minutes	Requests that carried no credentials or ones that matched none of the gateway's security definitions
Throttled callers	10 in 5 minutes	Requests answered with a 429 because the rate limit of their security definition was reached
Repeated calls	20 in 5 minutes	One session called one tool this many times - an agent stuck in a loop, every one of its calls reaching the backend

Traffic

Line	Default	What it does
Slow tool calls	5 s warning, 15 s error, in 5 minutes	The average time a tool call took in the window - a warning between the two values, an error above the second
Truncated responses	5 in 5 minutes	Responses the size cap in truncate mode cut down, so the agent received an incomplete response
Response volume	100 megabytes in a day	The sizes of every tool response the gateway returned in the window, added up whatever the tool - typed as kilobytes, megabytes or gigabytes
On no tool calls	off, 1 hour	For a gateway that expects traffic - no tool call arrived for this long, with time slots in which silence is expected and not alerted on

Configuration

Line	Default	What it does
Too many tools	25	The gateway exposes at least this many tools

The one alert with no window. The most capable models degrade past twenty to twenty-five tools in one list - they pick the wrong one or none at all, and every tool's schema is in the context of every call whether the agent needs it or not. The count is what the gateway's tools/list returns, the services and the connections it exposes together, and the alert stays open for as long as the count is at or above the number. A gateway that needs to expose more is a gateway to split by the audience each set of tools serves, with security deciding who reaches which.

The audit log

Every line but Too many tools reads the gateway's audit log, since that is where each tool call, each rejected caller and each throttled request is recorded. A gateway with Record each request in the audit log off has no traffic to count and only the tool count alerts about it. Turning the audit log on is the first step to alerting on a gateway, and the explanation of each alert is built from the same events - grouped by tool and by caller, with the session and the tool named for repeated calls and the JSON-RPC error text for invalid ones.