MCP

Trace your agent’s outgoing MCP tool calls with Rius, and connect them to the server’s own traces where the protocol allows it.

Two different things share the MCP name. This extra instruments your agent’s own outgoing MCP tool calls so they show up in your traces. The Rius MCP server is the opposite direction: an endpoint that lets AI clients query your telemetry. Instrumenting your agent does not require the MCP server, and vice versa.

Setup


pip install "glassflow-rius[mcp]"


import rius
 
rius.init(api_key="glassflow_...", service_name="my-agent")
# use mcp.ClientSession exactly as before

Unlike the client-library integrations, which are powered by OpenInference, the MCP integration is built into the SDK itself.

What gets captured

Calls made through mcp.ClientSession.call_tool() are traced as TOOL spans named execute_tool <name>, carrying:

gen_ai.tool.name: the tool being called
input.value: the tool arguments (JSON)
output.value: the tool result, preferring structured content, falling back to text blocks

Failures are recorded with ERROR status, both when the call raises and when the MCP result itself is flagged as an error (is_error on the mcp 2.x package, isError on 1.x; both majors are supported). Argument and result values are content attributes, so privacy controls apply to them like everything else.

Connecting agent and MCP server traces

With the mcp package at 2.x, trace context propagates through tool calls. That connects both sides of a call into one trace, if two things are true:

The MCP server you call is itself instrumented (with the Rius SDK or any OpenTelemetry SDK).
The server exports its traces to the Rius receiver, using an API key for the same workspace as your agent.

The server’s spans then appear under your agent’s execute_tool span, one waterfall covering the agent’s side and the server’s side of the same call. On mcp 1.x there is no context propagation: an instrumented server’s spans still arrive, but as separate traces.