How can my coding agent summarize an agent’s recent traces in Rius?

Rius gives your coding agent the agent_traces_summary tool on its MCP server, which summarizes an agent’s recent traces in one call. You ask in plain words, such as “How is the planner agent doing this week?”, and the client sends the agent name and a time window. The reply comes back as Markdown with trace count, LLM calls, error rate, cost, tokens and latency figures. The same figures appear on the agent’s page in the Rius console.

How it works

Your coding agent connects to the Rius MCP server, picks agent_traces_summary for a summary question and fills in the arguments itself. The main ones are:

• agent: the exact agent name. It is matched against the root span of each trace, the same value the root_agent column shows on list_agent_traces.
• hours: a lookback window ending now. The default is 24, and “this week” is 168.
• start and end: absolute RFC3339 bounds that override hours.
• service and instance: narrow to a service, or to one running copy of the agent.
• filters: extra clauses, for example on model. Call describe_search_catalog before guessing a key.
• group_by with bucket: add one row per minute, hour or day under the whole-window figures.
• workspace: a name or ID. Omit it to use your default workspace.

What comes back is the trace count, LLM calls, error rate, failed and errored traces, sessions, total and average cost, token usage, and latency and time to first token percentiles. Cost is a list-price estimate in US dollars.

Read the two failure lines as separate questions. A failed trace is a run whose root span errored. An errored trace is a run that hit an error anywhere, even if it then recovered. Do not add them together. The error rate is errored traces over traces.

Set it up

1. Connect your coding agent to the Rius MCP server, if the Rius plugin has not already done it. The plugin registers the server as rius. For Claude Code:

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

Agents without a browser use a read-scoped API key instead. The MCP page covers every client and the key setup.

2. Find the exact agent name. Ask “Which of my agents are running right now?” to use list_agents, or read the root_agent column from list_agent_traces. A run that declares no agent falls back to its service name, so read the name off a listing rather than guessing.

3. Ask in plain words. These questions all lead to agent_traces_summary:

   • “How did my agents do over the last 24 hours?”
   • “How is the planner agent doing this week?”
   • “Is one copy of planner worse than the others?”
   • “What do planner’s gpt-4o runs cost?”
   • “Is planner getting slower or more expensive over the week?”

4. If the tool is not picked, name it in your question. For the weekly planner question the client sends:

{
    "name": "agent_traces_summary",
    "arguments": { "hours": 168, "agent": "planner" }
}

5. For a trend, add group_by so one call returns a row per time bucket:

{
    "name": "agent_traces_summary",
    "arguments": { "hours": 168, "agent": "planner", "group_by": "bucket" }
}

Rows are sparse. A bucket in which no trace opened has no row, so do not read a missing bucket as zero traces or a 0% error rate. A trace counts once, in the bucket where its first span opened.

The tool reference lists every argument with more example calls.

What you get

• One answer for an agent’s recent runs, with volume, error rate, cost, tokens and latency, without paging through a trace list.
• Numbers that match the agent page in the Rius console, so what your coding agent reports and what a teammate reads there are the same.
• A weekly trend by minute, hour or day from a single call.
• Slices by service, instance, model or a time range you name.
• Read-only access. The tool changes nothing, so a read-scoped key is enough.

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

When something else fits

• To see the individual runs behind the summary, ask for list_agent_traces, then get_agent_trace for one span waterfall.
• To see what is failing and why, agent_error_groups groups errored spans by exception type and message.
• To judge whether a new version is worse, compare_agent_versions puts two versions side by side.

Related