How can my coding agent list the fields traces can be searched by in Rius?

Your coding agent lists the fields Rius traces can be searched by with the describe_search_catalog tool on the Rius MCP server. It returns every filter field with its type and the operators it accepts, merged with the keys your workspace has actually produced. Ask in plain words, such as “What can I filter traces on?”, and your client picks the tool and sends the arguments for you.

How it works

describe_search_catalog is a read-only tool. It returns the filter grammar for traces and spans: every field, its type, the operators it admits, and what a filter on it means for a whole trace. It merges that with the keys your workspace has produced recently, so you see your own attribute names next to the built-in fields.

The tool takes four optional arguments:

• workspace: a workspace name or ID. Leave it out to use your default workspace.
• field: a key whose values you want to see. It accepts either spelling, tool.name or attr.tool.name.
• prefix: narrows the key list, for example tool. to find your own tool attributes.
• hours: the lookback for the key and value lists. The default is 24.

The reply also tells you what each kind of field costs to search:

• Fields marked source: column are cheap over any window. These include status, agent, service, model, span_kind, operation and session_id.
• Your own attributes, reached with the attr. and resource. prefixes, cost roughly 10 times more. Rius accepts them only over windows of 31 days or less.

So narrow with a column first, then add one of your own attributes. The reply is Markdown, which your client renders as tables.

Set it up

1. Connect your client to the Rius MCP server. In Claude Code, run this once:

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

   If you use the Rius plugin, it already registers the server as rius. For a headless agent, use a read-scoped API key, because ingest keys cannot query. The MCP page covers Codex, Cursor and other clients, and the key setup.

2. Ask your client in plain words. Any of these works:

   • “What can I filter traces on?”
   • “What tool attributes does this workspace set?”
   • “Which models could I filter to?”

3. Your client calls the tool. For the first question it sends an empty argument list:

   { "name": "describe_search_catalog", "arguments": {} }

4. Narrow the answer when the full list is long. A prefix lists keys that start with it:

   { "name": "describe_search_catalog", "arguments": { "prefix": "tool." } }

   A field lists the values seen in your workspace for that key:

   { "name": "describe_search_catalog", "arguments": { "field": "model" } }

5. Use the keys you found as filters in a search. Each clause has a field, an op and values, and clauses are combined with AND. This call lists failed runs that used gpt-4o and called the send_email tool:

   {
       "name": "list_agent_traces",
       "arguments": {
           "status": "Error",
           "filters": [
               {"field": "model", "op": "eq", "values": ["gpt-4o"]},
               {"field": "attr.tool.name", "op": "eq", "values": ["send_email"]}
           ]
       }
   }

The operators are eq, ne, in, not_in, gt, gte, lt, lte, exists and not_exists. The full argument lists are in the tool reference.

What you get

• A single answer to “what can I search by?” that reflects your workspace, not a generic list.
• Keys your agent can use without guessing. A guessed key is a rejected call, and a rejected clause comes back naming itself.
• A cost signal on each field, so your agent searches by cheap columns first and adds your own attributes second.
• The same filter grammar in other tools. list_agent_traces, list_spans, agent_traces_summary and user_activity_summary all take filters in this shape. A slice you listed and the summary of that slice use the same field registry, so they cannot disagree.
• For free text over a failure, use the error_text argument of list_agent_traces. Its search argument matches span names and IDs. Substring matching on an attribute value is refused.

When something else fits

If you want to look at fields yourself rather than through your agent, use the trace list and its filters in the console. To go from the fields to answers about a whole agent fleet, read Monitor AI agents in production. For the arguments of the search tools that take these filters, see the tool reference.

Related