What does the mcp.method.name attribute mean in Rius?

In Rius, mcp.method.name marks a tool span as a tool called over the Model Context Protocol (MCP), and on a tool call its value is tools/call. It sits on the execute_tool span for each MCP call. Rius uses it to tell MCP tools from local tools when it reports how many context tokens MCP tools took in a trace.

How it works

A tool called over MCP is an execute_tool span like any other tool call, with the OpenTelemetry MCP attributes added.

• What the key holds: the OpenTelemetry MCP conventions define it as “the name of the request or notification method”, a string at Development stability that is required on MCP spans. Upstream lists well-known values such as initialize, tools/list and tools/call. On an MCP tool call it is tools/call. Its registry entry links the definition at the conventions commit Rius pins.
• Which spans carry it: the execute_tool spans for MCP calls. Local tools do not carry it, and that difference is what the key is for.
• What Rius computes from it: a trace’s context attribution. It reports how many context tokens MCP tools took, and their share of the total, only when at least one span in the trace carries mcp.method.name.
• When it is missing: Rius cannot tell MCP tools from local tools, so the MCP share shows as unknown, not zero.

The companion attribute mcp.protocol.version holds the MCP protocol version the client negotiated. Rius stores it with the span, and no analytics read it.

The mcp namespace holds one other key you may see on older spans, mcp.result_type. It is deprecated, nothing replaces it, and nothing ever read it. Early Rius SDKs set it only on interim tools/call rounds. Those rounds stay identifiable as a tool span carrying mcp.method.name. The mcp namespace registry page lists it.

Set it up

If you use the Rius SDKs, their MCP integration sets mcp.method.name and mcp.protocol.version for you. You only need to act when you instrument MCP calls by hand, for example with a vanilla OpenTelemetry SDK. The full attribute contract is in the span attribute reference, and the broader setup is in Trace LLM calls with OpenTelemetry.

1. Make the MCP call an execute_tool span. Set gen_ai.operation.name to execute_tool, or openinference.span.kind to TOOL. Set either one and Rius derives the other.
2. Name the span the way the GenAI conventions ask, the operation followed by what it acted on, such as execute_tool get_weather.
3. Set gen_ai.tool.name to the tool’s own name, never the span name. Set gen_ai.tool.call.id to the id of the model’s tool call this execution answers.
4. Set mcp.method.name to tools/call on that span. Optionally set mcp.protocol.version too.
5. Send the spans to Rius over OTLP/HTTP with your API key as a bearer token:

POST https://ingest.eu.console.rius-glassflow.com/v1/traces
Authorization: Bearer <your API key>
Content-Type: application/x-protobuf

You only need mcp.method.name on one span in a trace for the MCP share to be computed, but setting it on every MCP tool span keeps the split between MCP and local tools accurate. Do not send a cost attribute. Rius computes cost from the model and token counts.

What you get

• A trace’s context attribution that separates MCP tools from local tools, with the number of context tokens MCP tools took and their share of the total.
• A clear signal when the split is unknown: without mcp.method.name the MCP share is unknown, not zero.
• A tool span that is identifiable as an MCP call, including the interim tools/call rounds that early SDKs marked with the deprecated mcp.result_type.
• The negotiated protocol version stored on the span when you also send mcp.protocol.version, for inspection in the trace.

When something else fits

• If your agent calls only local tools, you do not need mcp.method.name. Those spans need only the execute_tool operation and gen_ai.tool.name.
• If you use the Rius SDKs, leave the attribute to their MCP integration instead of setting it yourself.
• For every other attribute Rius reads, use the span attribute reference.

Related