How can my coding agent read one alert firing in Rius?

Your coding agent reads one alert firing in Rius with the get_alert tool on the Rius MCP server, which takes an alert id and returns the alert in full. Ask in plain words, such as “Why did that alert fire?”, and the client sends the id for you. You get the alert’s labels, the sample trace ids behind it, and the written root-cause finding when root-cause analysis ran for it.

How it works

The Rius MCP server exposes get_alert as a read-only tool. Like every tool on the server, it returns Markdown, which your client renders as a readable summary. You rarely call it by hand: your client picks the tool from your question.

It takes two arguments:

• alert_id is required. It is the alert’s id, taken from list_alerts.
• workspace is optional. Pass a workspace name or id, or leave it out to use your default workspace. If the same workspace name exists in two of your organizations, pass it as org/workspace.

The reply covers one fired alert:

• Its labels.
• The sample trace ids behind it.
• The investigation’s written finding, if root-cause analysis ran for that alert.

Because the alert id comes from list_alerts, the usual pattern is two calls: list, then read one. list_alerts shows newest first and takes status (open or resolved), kind, service, step, search on the alert title, acknowledged, hours and limit. The hours window defaults to 24 and applies to when the alert was last seen, so pass a larger value to find an older alert.

This works with an interactive sign-in, where reading is open to every member. It also works with a read-scoped API key, which reaches the alert reads. See MCP for both connection types and Tool reference for every argument.

Set it up

1. Connect your coding agent to the Rius MCP server. In Claude Code, run this in your terminal. The sign-in opens the first time a session uses the server. If you already use the Rius plugin, it registers the server as rius and you can skip this step.

   claude mcp add --transport http rius https://mcp.eu.console.rius-glassflow.com/mcp

   Other clients are covered on the MCP page.

2. Find the alert. Ask “What alerts are open right now?” Your client calls list_alerts and shows a table that includes each alert’s id:

   { "name": "list_alerts", "arguments": { "status": "open" } }

   To narrow it down, ask for one service over a longer window, such as “Show me the errors alert for the checkout service this week.”

3. Read the one you want. Ask “Why did that alert fire?” Your client passes the id from the list to get_alert:

   { "name": "get_alert", "arguments": { "alert_id": "2f9c…" } }

4. Follow the evidence. The reply names sample trace ids. Ask “Break down that trace for me” and your client calls get_agent_trace with one of them, which returns the span waterfall for that run.

In a long session, say which alert you mean, for example by service and title. Your client then reuses the id it already listed instead of guessing one.

What you get

• One alert, in full. Labels, sample trace ids and, when root-cause analysis ran, the written finding, all in your coding session instead of a console tab.
• A path to the cause. The sample trace ids lead straight to get_agent_trace, so your agent can go from the alert to the failing spans without you copying ids.
• Plain-language access. “Why did that alert fire?” is enough. Your client chooses the tool and fills the arguments.
• A safe read. get_alert changes nothing. Acknowledging is a separate tool, ack_alert, which works only on an interactive sign-in because it records which person saw the alert. An API key never acknowledges a firing.

For the wider picture of watching agents, see Monitor AI agents in production.

When something else fits

• To scan what is firing rather than read one alert, ask for list_alerts first. It filters by status, service and step.
• To change alert rules or channels, use the alert-management tools in the Tool reference. They need an admin on an interactive sign-in, or a key minted with the matching manage scope.
• To see how a whole agent or workspace is doing before you pick an alert, use agent_traces_summary or workspace_metrics_overview.

Related