Tool reference

Every tool the Rius MCP server exposes, with arguments and example invocations. All tools return Markdown, which your client renders as tables and summaries. Everything is read-only with one exception, create_api_key, which is admin-gated.

Two conventions apply across the trace tools:

• workspace is optional everywhere: pass a workspace name or ID, or omit it to use your default workspace. Discover workspaces with list_workspaces.
• hours is a lookback window ending now (default 24). “This week” is hours: 168.

ack_alert

Acknowledge an alert: record that a human has seen it, so it stops notifying.

Acknowledging is NOT resolving. The alert stays open and keeps counting occurrences; only the detector resolves it, once the condition clears. Nothing in the API can force an alert closed.

Only available on an interactive (OAuth) connection: the acknowledgement records which user saw the alert, and an API key is not a user.

I’ve seen that alert, stop pinging me about it.

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

agent_traces_summary

Summary KPIs for agent traces over a time window: trace count, LLM calls, error rate, total/average cost, token usage, and latency percentiles (p50/p95/p99).

How did my agents do over the last 24 hours?

{ "name": "agent_traces_summary", "arguments": { "hours": 24 } }

Summarize the checkout-agent service this week.

{
    "name": "agent_traces_summary",
    "arguments": { "hours": 168, "service": "checkout-agent" }
}

Summarize traces between two specific dates.

{
    "name": "agent_traces_summary",
    "arguments": { "start": "2026-08-01T00:00:00Z", "end": "2026-08-08T00:00:00Z" }
}

create_alert_channel

Create a place for alerts to be delivered: a webhook, an email list, or Slack.

This provisions a real outbound effect. Once a rule points at this channel, alert content leaves the platform to wherever you named — for a webhook, an HTTP POST to that URL. The payload carries the alert title (which is a span’s error message, so it can contain model output), its labels, counts, and a sample of trace ids.

Needs the channels:manage capability.

Send my alerts to this webhook.

{ "name": "create_alert_channel", "arguments": {
    "name": "ops webhook", "channel_type": "webhook",
    "url": "https://hooks.example.com/rius"
} }

create_alert_rule

Create a custom alert rule. Call describe_alert_catalog first.

The rule fires when every threshold in rules holds at once, over the same rolling window, for the traffic left after every filter in filters. There is no OR: for alternatives, create a second rule.

Predefined rules cannot be created — they already exist per workspace. Use update_alert_rule to configure one.

Alert me when the checkout agent starts erroring.

{ "name": "create_alert_rule", "arguments": {
    "name": "checkout errors",
    "filters": [{"field": "service", "operator": "eq", "values": ["checkout"]}],
    "rules": [{"metric": "errors", "aggregation": "count", "operator": "gte", "value": 5}]
} }

Tell me if p95 cost per trace goes over two dollars.

{ "name": "create_alert_rule", "arguments": {
    "name": "cost spike",
    "window_minutes": 60,
    "rules": [{"metric": "cost", "aggregation": "p95", "operator": "gt", "value": 2.0}]
} }

create_api_key

Create a new API key in one of your workspaces. Requires admin access in that workspace. The plaintext key is shown exactly once in the response. It is never retrievable again after this call, so save it immediately.

Not available when this MCP connection is itself authenticated with an API key (headless mode): a leaked agent key must not be able to mint more keys. Mint keys from an interactive (OAuth) session or the console instead.

Create an API key so this agent can send traces.

{ "name": "create_api_key", "arguments": { "name": "my-agent" } }

Give it a key that can query the API too.

{ "name": "create_api_key", "arguments": { "scopes": ["ingest", "read"] } }

delete_alert_channel

Delete a notification channel. Irreversible.

Takes two calls, like delete_alert_rule: once to preview, once with the phrase.

Any rule still pointing at this channel loses that destination silently and falls back to the region’s default webhook — it does not start failing loudly. Consider update_alert_channel with enabled false instead, which is reversible.

Needs the channels:manage capability.

Remove the old ops webhook.

{ "name": "delete_alert_channel", "arguments": { "channel_id": "8a1…" } }

delete_alert_rule

Delete a custom alert rule AND its entire firing history. Irreversible.

Takes two calls. Call it without confirm to see what would be destroyed and get the phrase to pass back; call it again with that phrase to go ahead.

Prefer update_alert_rule with enabled false: that stops detection and keeps the history, and can be undone. Predefined rules cannot be deleted at all.

Delete the cost spike alert.

{ "name": "delete_alert_rule", "arguments": { "ref": "9c2…" } }

describe_alert_catalog

Describe what you can alert on: the fields, metrics and limits for a custom rule.

Read this before calling create_alert_rule. It returns the filter fields, the metrics with the aggregations each one actually supports, the comparison operators, and the allowed window — plus the constraints the catalog itself does not advertise.

What can I alert on?

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

Which services could I filter an alert to?

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

get_agent_trace

Get one agent trace’s span waterfall (spans in time order, indented by depth).

The header names the root span’s agent and each row carries its own, so a multi-agent run shows which agent owned which span; pass either name back to list_agent_traces or list_spans as agent to see that agent’s other work.

Captured content is subject to the workspace’s privacy controls: spans exported with capture_content=False or a mask have nothing extra to show.

Break down trace 4bf92f3577b34da6a3ce929d0e0e4736 for me.

{
    "name": "get_agent_trace",
    "arguments": { "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736" }
}

What did the LLM actually say in that failed span?

{
    "name": "get_agent_trace",
    "arguments": {
        "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
        "include_content": true
    }
}

get_alert

Read one fired alert in full, with its root-cause finding when one exists.

Use this after list_alerts to understand a single alert: its labels, the sample trace ids behind it, and — if root-cause analysis ran for it — the investigation’s written finding.

Why did that alert fire?

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

get_me

Get your own identity and access context.

Returns your user (id, external id, email), your organization (id, name) and your role in it (“admin” or “member”), and the workspaces you can access. If you have not yet joined an organization (for example, a pending invite that has not been accepted), the organization and role are reported as “none”. On a connection authenticated with an API key rather than a login, only the workspaces are reported — a key has no user or organization of its own.

No arguments.

Who am I in Rius?

{ "name": "get_me", "arguments": {} }

list_agent_traces

List recent agent traces (one row per trace) newest-first, as a Markdown table.

The trace_id column feeds get_agent_trace. When more traces match than limit, the reply carries a next-page cursor: pass it back as cursor to fetch the next page, rather than raising limit past what a chat can usefully display.

Show me the failed runs from the last two days.

{ "name": "list_agent_traces", "arguments": { "hours": 48, "status": "Error" } }

Which runs actually failed, ignoring the ones that retried and recovered?

{ "name": "list_agent_traces", "arguments": { "hours": 48, "root_status": "Error" } }

Show me the runs that hit errors but finished cleanly anyway.

{
    "name": "list_agent_traces",
    "arguments": { "hours": 48, "status": "Error", "root_status": "Ok" }
}

checkout-agent’s traces between two dates.

{
    "name": "list_agent_traces",
    "arguments": {
        "agent": "checkout-agent",
        "start": "2026-08-01T00:00:00Z",
        "end": "2026-08-08T00:00:00Z"
    }
}

list_alert_channels

List where this workspace’s alerts can be delivered.

Use it to find a channel id for create_alert_rule or update_alert_rule. Needs the channels:manage capability rather than plain read, because the target column shows the actual destination — a webhook URL, an email recipient list, a Slack channel.

Where do my alerts go?

{ "name": "list_alert_channels", "arguments": {} }

list_alert_rules

List every alert rule in the workspace — predefined and custom together.

Predefined rules are the built-in detectors, one per kind, which you can configure and toggle but not create or delete. Custom rules are ones someone built from the metric catalog; there can be many.

The ref column is what update_alert_rule and delete_alert_rule take: a kind name for a predefined rule, a uuid for a custom one.

A predefined rule only appears once alert-manager has reached this workspace, so an empty list can simply mean detection has not started yet.

What alerts are configured?

{ "name": "list_alert_rules", "arguments": {} }

list_alerts

List alerts that have fired, newest first.

This is the “what is broken” tool. An alert is opened by a detector and stays open, accumulating occurrences, until the detector resolves it — so an open alert with a recent last_seen is still happening.

What alerts are open right now?

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

Show me the errors alert for the checkout service this week.

{ "name": "list_alerts", "arguments": { "service": "checkout", "hours": 168 } }

list_metrics_catalog

List every metric the platform knows how to compute, with its unit, nullability, which endpoint serves it, and its companions (the extra response keys it contributes: coverage keys for scalars, row/point value keys for breakdowns and series). Use it to discover exact field names instead of guessing them.

What latency metrics exist?

{ "name": "list_metrics_catalog", "arguments": { "group": "latency" } }

list_spans

List spans across every trace in the workspace (not grouped by trace), as a Markdown table — the cross-trace complement to get_agent_trace’s single-trace waterfall. Use it to find spans by kind/session/agent regardless of which trace they landed in, e.g. “every failed tool call this week” or “this session’s spans across however many traces it touched”.

Show me every errored tool call in the last day.

{ "name": "list_spans", "arguments": { "kind": "tool", "status": "Error" } }

All spans in session user-42-chat-7.

{ "name": "list_spans", "arguments": { "session_id": "user-42-chat-7" } }

list_workspaces

List the workspaces you have access to (id and name).

Use it to find the right value for the workspace argument of the trace and metrics tools.

No arguments.

Which Rius workspaces do I have?

{ "name": "list_workspaces", "arguments": {} }

update_alert_channel

Change a notification channel: rename it, re-point it, or enable/disable it.

Only what you pass changes; a channel’s secrets are left alone if you do not resubmit them. A channel’s type cannot be changed — create a new one instead.

A channel that has failed to deliver several times in a row is disabled automatically; pass enabled true to bring it back once you have fixed it.

Needs the channels:manage capability.

Disable the ops webhook for now.

{ "name": "update_alert_channel", "arguments": { "channel_id": "8a1…", "enabled": false } }

update_alert_rule

Reconfigure or toggle one alert rule, predefined or custom.

ref decides which: a kind name (consistent_error_pattern, silent_failure, tool_loop) addresses the predefined rule of that kind; a uuid addresses a custom rule. Get either from list_alert_rules.

Only what you pass changes. Turning a rule off stops detection, not just notification — gaps in history are permanent and nothing backfills them.

The two rule shapes take DIFFERENT settings, and mixing them is refused with a message naming the right one:

• a predefined rule has named integer knobs -> pass config
• a custom rule has metric thresholds -> pass rules (+ window_minutes)

Turn off the tool loop alert.

{ "name": "update_alert_rule", "arguments": { "ref": "tool_loop", "enabled": false } }

Make the error pattern alert less noisy — 10 errors, not 3.

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

workspace_metrics_overview

Aggregated health of a whole workspace over a time window: the numbers behind the dashboard’s overview: volume (traces/spans/LLM calls), cost, tokens, latency percentiles, TTFT, error rates, each with its previous-window baseline and delta, plus ranked breakdowns (per model, top agents, calls by kind, top exceptions, slowest spans).

Use this to answer “how is my workspace doing” before drilling into individual traces with list_agent_traces / get_agent_trace.

Values are milliseconds for latency/TTFT; — means not measured (null), which is never the same as a measured 0. Metrics listed as degraded failed to compute and are absent rather than zero.

How is my workspace doing today?

{ "name": "workspace_metrics_overview", "arguments": {} }

Anything wrong in the last 10 minutes?

{ "name": "workspace_metrics_overview", "arguments": { "minutes": 10 } }

Next steps

• Example workflows: the trace tools composed into complete investigations.
• Quick connect: connecting a client if you have not yet.