Skip to Content

How can my coding agent summarize what one end user experienced in Rius?

Rius gives your coding agent the user_activity_summary tool on its MCP server, which rolls up one end user’s activity into a single summary. Ask something like “What did user u_8f2 experience in the last 24 hours?” and the agent calls it with that user’s id. The reply is a Markdown summary of that user’s traces, LLM calls, error rate, cost, tokens and latency, the same figures the Rius console shows on that user’s page.

How it works

An end user here is the person your agents serve, not a Rius account. Your code marks them with rius.user in Python or withUser in TypeScript, which stamps user.id on the spans. A trace counts for a user if the user scope was open on any span inside it, not only at the root.

The main parameters of user_activity_summary are:

  • user_id: the end user’s exact id. Read it off the user_id column of list_agent_traces or off list_users rather than guessing.
  • anonymous: set to true to summarize traffic that carries no end user. Pass either user_id or anonymous, never both.
  • hours: a lookback window ending now, 24 by default. “This week” is hours: 168.
  • start and end: absolute RFC3339 bounds that override the window.
  • filters: extra clauses ANDed with the user scope, such as one model. Call describe_search_catalog first to find valid keys.
  • workspace: a workspace name or ID. Leave it out for your default workspace.

The reply covers:

  • trace count and LLM calls
  • error rate
  • failed and errored traces, reported as two separate lines
  • sessions
  • total and average cost
  • token usage
  • latency and time to first token percentiles

A failed trace is a run whose root span errored. An errored trace hit an error somewhere, possibly recovered, and still finished. Do not add the two together or report either one as “errors”. Cost is a list-price estimate in US dollars, computed by Rius.

You never pick the tool yourself. Your client chooses it from your question. The full argument list is in the tool reference.

Set it up

  1. Connect your coding agent to the Rius MCP server. In Claude Code, run this in your terminal and finish the browser sign-in the first time a session uses the server:
claude mcp add --transport http rius https://mcp.eu.console.rius-glassflow.com/mcp

If you already use the Rius plugin, it registers the server as rius and you can skip this step. For agents that run without a browser, use a read-scoped API key as an Authorization bearer header, because ingest keys cannot query. Other clients and the headless setup are covered on the MCP page.

  1. Make sure your code sets the end user id with rius.user or withUser. Without it, the traffic lands under anonymous and you can only summarize it with anonymous: true.

  2. Ask in plain words, with the id:

    • “What did user u_8f2 experience in the last 24 hours?”
    • “How has that user’s week been?”
    • “What did that user’s gpt-4o runs cost?”
    • “How much of our traffic has no user attached, and is it failing?”
  3. If you don’t have an id yet, ask “Who are my busiest end users this week?” so the agent calls list_users and shows you the ids.

  4. To see what your agent sends for the first question, this is the call:

{ "name": "user_activity_summary", "arguments": { "user_id": "u_8f2" } }

For a week, add hours:

{ "name": "user_activity_summary", "arguments": { "user_id": "u_8f2", "hours": 168 } }

What you get

  • One rollup per user instead of a trace list your agent has to fold itself. A support complaint that arrives with an identifier gets an answer in one call.
  • Numbers that match the console. The figures, window and definitions are the same as on the user’s page in Rius, so what your agent reports and what a teammate reads there agree.
  • A view of unattributed traffic. With anonymous: true you see what happens to runs nobody attributed, and a high error rate there is worth knowing.
  • A narrower slice on demand, such as one model, through filters.
  • Readable results. Every tool returns Markdown, which your client renders as tables and summaries.

This is part of what Monitor AI agents in production covers, now reachable from the tool where you already work.

When something else fits

  • To see the individual runs behind the numbers, ask for that user’s traces. list_agent_traces takes user_id, and get_agent_trace then shows one run as a span waterfall.
  • If a trace row shows a blank user but matches the user, list_spans with user_id finds the spans that carried the user.
  • For the whole workspace or one agent rather than one person, use agent_traces_summary. The MCP page lists what else you can ask.

Still stuck? Get help

Last updated on