Skip to Content

What does the gen_ai.tool.type attribute mean in Rius?

In Rius, gen_ai.tool.type describes the kind of tool an execute_tool span ran, with values such as function, extension and datastore. You set it on the span for each tool execution, and Rius stores it as sent, so you can read, search and filter on that key in trace inspection. It sits beside gen_ai.tool.name, which holds the tool’s own name.

How it works

  • What it holds: the OpenTelemetry GenAI conventions define it as the “type of the tool utilized by the agent”, a string at Development stability. Their example values are function, a tool the client executes with parameters the agent generated, extension, a tool the agent executes itself to call external APIs, and datastore, a tool the agent uses to query external data for retrieval. It is a free string, not a closed list.
  • Which spans carry it: spans for tool executions, meaning spans whose operation is execute_tool. Model-call, agent and retrieval spans do not use it.
  • How it sits with the other tool keys: gen_ai.tool.name holds the tool’s own name, never the span name. gen_ai.tool.call.id holds the id of the model’s tool call that this execution answers. gen_ai.tool.type adds the category.
  • How the span becomes a tool span: the span is classified as a tool by gen_ai.operation.name set to execute_tool, or by openinference.span.kind set to TOOL. Set either one and Rius derives the other. The tool type attribute does not change the classification.
  • How it is stored: OpenTelemetry GenAI attributes are stored as sent, with two exceptions that concern other keys (gen_ai.tool.call.arguments and gen_ai.tool.call.result, and the deprecated gen_ai.system). gen_ai.tool.type is kept under its own name, so that is the key you search and filter on.
  • Where it is defined: its registry entry links the upstream definition at the GenAI conventions commit Rius pins, and the attribute reference lists it with the other tool keys.

Set it up

  1. If you emit spans with the Rius SDKs, the SDK sets the operation and kind of the span for you. If you emit spans from a vanilla OpenTelemetry SDK, a collector pipeline or another language, you set the attributes yourself. Trace LLM calls with OpenTelemetry covers the full setup.
  2. Send traces over OTLP/HTTP to https://ingest.eu.console.rius-glassflow.com/v1/traces, with your API key in an Authorization: Bearer header.
  3. On each tool execution, name the span the way the GenAI conventions ask, the operation followed by the tool, such as execute_tool get_weather. Then set these attributes on it. The tool name and call id below are examples, so use your own:
gen_ai.operation.name: execute_tool
gen_ai.tool.name: get_weather
gen_ai.tool.call.id: call_1
gen_ai.tool.type: function
  1. Open the trace in the console and look at the span’s attributes to confirm the value arrived. Use the exact key gen_ai.tool.type when you search or filter.

The attribute reference has the rest of the tool, agent and retrieval keys, and what the platform does with each.

What you get

  • A tool category recorded on every tool execution span you tag, stored under the key gen_ai.tool.type exactly as you sent it.
  • A consistent set of tool keys across a mixed fleet: the name in gen_ai.tool.name, the call id in gen_ai.tool.call.id, and the category in gen_ai.tool.type.
  • Tool spans that are classified as tools through the operation or the span kind, whether or not the type is set.
  • Cost that does not depend on this key. Rius computes cost on the server from the model and token counts, and you never send a cost attribute.

When something else fits

  • To identify which tool ran, use gen_ai.tool.name, not the type.
  • To tie an execution to the model’s request for it, use gen_ai.tool.call.id.
  • To mark a tool as an MCP tool, set mcp.method.name on the span, which is what separates MCP tools from local ones in context attribution.

Still stuck? Get help

Last updated on
Quickstart