-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[Bug]: MCP tool spans exported via the OpenClaw Opik plugin are present in trace data but missing from the Opik UI trace view #5934
Description
What component(s) are affected?
- Opik Python SDK
- Opik Typescript SDK
- Opik Agent Optimizer SDK
- Opik UI
- Opik Server
- Documentation
Opik version
Plugin:
- opik-openclaw
- version: 0.2.9
Describe the problem
Summary
I’m using the OpenClaw Opik plugin (opik-openclaw) to export traces to Opik.
When a run calls:
- built-in/local tools, those tool spans appear in the Opik UI
- tools exposed via an MCP server, those tool spans do not appear in the Opik UI trace view
The MCP tool calls succeed, and the corresponding spans appear to exist in the raw/original trace data, but they are not shown in the Opik UI.
This was reproduced with a minimal MCP server exposing a single trivial tool, so it does not seem specific to one particular MCP tool or payload.
────────────────────────────────────────────────────────────────────────────────
Integration context
This issue is occurring through the OpenClaw Opik plugin, not through a direct Opik SDK integration in my app.
Plugin:
- opik-openclaw
- version: 0.2.9
────────────────────────────────────────────────────────────────────────────────
Expected behavior
If a tool span is successfully exported to Opik, it should be visible in the Opik UI trace/span view regardless of whether the tool came from:
- a built-in/local tool
- or an MCP server
────────────────────────────────────────────────────────────────────────────────
Actual behavior
- Built-in/local tool spans appear in the Opik UI
- MCP tool spans do not appear in the Opik UI
- The MCP tool call itself succeeds
- The MCP span appears to exist in the raw/original trace data
────────────────────────────────────────────────────────────────────────────────
Minimal reproduction
1. Use the OpenClaw Opik plugin to export traces to Opik
2. Register a minimal MCP server with one trivial tool
For example, a tool named mcp_echo_test that returns:
input:
{"text":"hello-mcp"}output:
{"ok":true,"text":"hello-mcp"}3. Trigger two traced runs
- one run calling a built-in/local tool
- one run calling the MCP tool mcp_echo_test
4. Compare the Opik UI trace view
Observed:
- built-in/local tool span is visible
- MCP tool span is not visible
────────────────────────────────────────────────────────────────────────────────
Why I think this may be on the Opik/UI side
From inspecting the OpenClaw plugin behavior, it appears that:
- the MCP tool is successfully invoked
- the plugin creates/exports the corresponding tool span
- the span exists in the underlying trace data
- but the Opik UI does not render/show it
So this looks less like an execution/export failure and more like:
- span classification issue
- UI filtering
- frontend rendering behavior for these tool spans
────────────────────────────────────────────────────────────────────────────────
Related issue
Possibly related to prior tool span classification issues:
Not the same bug, but potentially in the same area.
────────────────────────────────────────────────────────────────────────────────
Questions
- Is there any known UI filtering/classification rule that could hide MCP-origin tool spans?
- Does Opik expect a specific span type or metadata shape for tool spans to appear correctly in the UI?
- Would it help if I provide a sanitized raw trace example plus the relevant OpenClaw-exported span payload?
────────────────────────────────────────────────────────────────────────────────
Reproduction steps and code snippets
No response
Error logs or stack trace
No response
Healthcheck results
No response