How can my coding agent change an alert threshold in Rius?

Your coding agent changes an alert threshold in Rius with the update_alert_rule tool on the Rius MCP server. You ask in plain words, for example “make the error pattern alert less noisy, 10 errors instead of 3”, and the agent sends the rule’s ref plus the new values. The connection needs permission to manage alert rules: an admin on an OAuth session, or an API key minted with alerts:manage.

How it works

update_alert_rule reconfigures one rule and changes only what you pass. Which argument holds the threshold depends on the rule type:

• Predefined rules (consistent_error_pattern, swallowed_error, tool_loop) have named integer settings. Pass them in config, for example min_errored_spans for consistent_error_pattern, or min_identical_calls for tool_loop. window_minutes goes inside config too.
• Custom rules have metric thresholds. Pass rules to replace them, together with window_minutes. Each threshold has a metric, an aggregation, an operator (lt, lte, gt, gte or eq) and a value.

Mixing the two shapes is refused with a message that names the right one.

The main parameters:

Because rules replaces the whole list, a custom rule with several thresholds needs every threshold you want to keep in the call, not just the one you change. Call describe_alert_catalog to see the metrics, aggregations and the bounds for each setting.

Set it up

1. Connect your coding agent to the Rius MCP server, which is registered as rius. If you use the Rius plugin, it already registers the server, so skip this. MCP has the connect line for each client.
2. Give the connection permission to manage alerts. On an OAuth session you need to be an admin. For a headless agent, an admin ticks Manage alert rules (alerts:manage) in the Connect an agent dialog of the console’s MCP page. Without that scope the tool is listed but replies that the key isn’t allowed and changes nothing.
3. Ask in plain words. For example:
   • “What alerts are configured?” The agent calls list_alert_rules and reads the ref of the rule.
   • “Make the error pattern alert less noisy, 10 errors, not 3.”
   • “Raise the checkout errors alert to fire at 10 errors.”
4. For a predefined rule, the agent sends a call like this:

{ "name": "update_alert_rule", "arguments": {
    "ref": "consistent_error_pattern",
    "config": { "min_errored_spans": 10 }
} }

5. For a custom rule, it sends the new thresholds and the window together, using the rule’s uuid as ref:

{ "name": "update_alert_rule", "arguments": {
    "ref": "9c2…",
    "window_minutes": 15,
    "rules": [{"metric": "errors", "aggregation": "count", "operator": "gte", "value": 10}]
} }

The tool reference lists every argument of update_alert_rule and the other alert tools.

What you get

• The threshold changes on the rule you named, and nothing else on it changes.
• Like every Rius MCP tool, update_alert_rule returns Markdown, which your client shows as a short summary.
• If the connection isn’t allowed to change alert rules, or you mixed the predefined and custom shapes, the reply says why instead of making the change.
• You can review the result with list_alert_rules, which shows the rules and their ref values.
• The call only edits the rule. It does not acknowledge a firing, and no API key can do that.

To see how alerts are used across your agents, read Monitor AI agents in production.

When something else fits

• To create a brand-new rule rather than edit an existing one, ask your agent to use create_alert_rule, after describe_alert_catalog.
• To stop a noisy rule without losing its history, set enabled to false instead of deleting it. Deleting a custom rule also deletes its firing history and cannot be undone.
• If you prefer to review changes by eye, make the edit in the console instead.

Related