How can my coding agent list the metrics an alert can use in Rius?

Your coding agent calls the describe_alert_catalog tool on the Rius MCP server, which lists what a custom alert can use. Ask “What can I alert on?” and the reply covers the metrics, the aggregations each metric supports, the comparison operators, the filter fields and the allowed window. The tool only reads, so it changes nothing in your workspace.

How it works

describe_alert_catalog is one of the tools the Rius MCP server exposes. You rarely call it by hand. You ask in plain words and your client picks the tool and its arguments.

It takes two optional parameters:

• workspace: a workspace name or ID. Leave it out to use your default workspace. When the same name exists in two of your organizations, pass org-name/workspace-name.
• field: a filter field ID such as service. With it, the tool also lists the values that field has taken in your workspace over the last 24 hours.

Without field, the reply lists:

• the metrics, with the aggregations each one supports (not every aggregation applies to every metric)
• the comparison operators: lt, lte, gt, gte and eq
• the filter fields, with the operators each field admits
• the allowed rolling window, which for a rule is 5 to 1440 minutes
• the constraints the catalog itself does not advertise

Like every tool on the server, it returns Markdown, which your client renders as tables and summaries. The tool reference shows every argument.

Set it up

1. Connect your client to the server. In Claude Code, run this once. If you already use the Rius plugin, the server is registered as rius and you can skip this step. The MCP page has the snippets for other clients, and for headless agents that sign in with a read-scoped API key.

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

2. Ask your agent in plain words:

   What can I alert on?

   The client sends the tool call with no arguments:

   { "name": "describe_alert_catalog", "arguments": {} }

3. Narrow it to the values you can filter on. For example, ask “Which services could I filter an alert to?” The client passes the field:

   { "name": "describe_alert_catalog", "arguments": { "field": "service" } }

4. Pass a workspace when your agent should read a workspace other than your default. If you are unsure of the name, ask “Which Rius workspaces do I have?” and the client calls list_workspaces.

5. Build the rule from what came back. The create_alert_rule tool takes metric and aggregation pairs exactly as the catalog lists them. Pass filter values as the data spells them. The span_kind value is LLM, not llm, and a lowercased value creates a rule that saves and then never fires. The alert-management tools need an admin on an interactive session, or an agent key minted with the alert-management scope.

What you get

• A list of the metrics a custom rule can use, with the aggregations each one actually supports, so your agent does not guess a pair that Rius would reject.
• The comparison operators, the filter fields and the window limits in one reply.
• With field, the real values in your workspace, such as the service names you can filter to.
• A safe first step before create_alert_rule, whose own description tells the agent to call describe_alert_catalog first.

For how alerts fire and what the built-in ones do, see Monitor AI agents in production.

When something else fits

• If you want every metric Rius can compute, not only those an alert can use, ask for the metrics catalog. The list_metrics_catalog tool lists each metric with its unit and group, and takes optional group and kind filters.
• If you want to see which alert rules already exist, ask “What alerts are configured?” and the client calls list_alert_rules.
• If you want to find filter keys for traces or spans rather than alerts, use describe_search_catalog.

Related