MCP

Python

There is nothing to install. Unlike the client-library integrations, which are powered by OpenInference and come from extras, the MCP instrumentation ships inside the SDK, and it enables itself whenever the mcp package is importable, which it already is in any agent that calls MCP tools.

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

TypeScript

There is nothing to install. The MCP instrumentation ships inside the SDK, and it enables itself whenever @modelcontextprotocol/sdk is resolvable, which it already is in any agent that calls MCP tools.

import { init } from '@glassflow-ai/rius'
 
init({ apiKey: 'gf_...', serviceName: 'my-agent' })
// use the MCP SDK's Client exactly as before

init() patches the MCP SDK’s Client class itself, so every client you construct afterwards is traced. Call it before you make tool calls. In a CommonJS application, require the MCP SDK before init(): the SDK patches the copies of the Client class already in your process, and one that is first required later stays untraced.

Python

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).

TypeScript

Calls made through the MCP SDK’s Client.callTool() are traced as TOOL spans named execute_tool <name>, carrying:

• gen_ai.tool.name: the tool being called
• input.value: the tool arguments
• output.value: the tool result

Failures are recorded with ERROR status, both when callTool() rejects and when the MCP result itself is flagged as an error (is_error on the MCP SDK’s 2.x results, isError on 1.x; both spellings are read). An error-flagged result keeps its output, since the error content is what you need to see.

A tool call that comes back asking for more input records mcp.result_type: input_required and no output, because an input request carries conversation content that does not belong on a tool span. The final round of the same call records its output as usual.

Python

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:

1. The MCP server you call is itself instrumented (with the Rius SDK or any OpenTelemetry SDK).
2. 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.

TypeScript

The TypeScript integration does not propagate trace context into the tool call, so an instrumented server’s spans arrive as separate traces rather than nested under your agent’s tool span. Both sides are still queryable, and the timestamps line up, but there is no single waterfall across the call.