[bot] Anthropic MCP connector tool calls (mcp_tool_use/mcp_tool_result) produce broken, input-less child spans

从 InstrumentationSemConv.addAnthropicServerSideChildSpans 开始，位于 braintrust-sdk/src/main/java/dev/braintrust/instrumentation/InstrumentationSemConv.java，其中块由 type 分派；还要阅读 ANTHROPIC_SERVER_TOOL_USE_TYPE、isAnthropicToolResultType 以及 call == null 的回退逻辑。将 mcp_tool_use 注册为调用类型，以便现有的基于后缀的结果匹配将其与 mcp_tool_result 配对。在 BraintrustAnthropicServerSideSpansTest.java 中仿照现有的 server_tool_use 覆盖，并运行该测试类；完成意味着 MCP 子 span 携带真实工具名称和 input_json。

Summary

InstrumentationSemConv.addAnthropicServerSideChildSpans dispatches Anthropic Messages response content blocks by checking each block's "type" against the literal string "server_tool_use" (see ANTHROPIC_SERVER_TOOL_USE_TYPE and the dispatch check). Anthropic's MCP connector feature emits a different, distinct pair of block types for server-executed MCP tool calls: "mcp_tool_use" (the call) and "mcp_tool_result" (the result). "mcp_tool_use" does not match the "server_tool_use" check, so it is never registered in the call-tracking map used to pair calls with results.

Meanwhile "mcp_tool_result" does match the result-type check, which is a suffix check (type.endsWith("_tool_result") && !type.equals("tool_result")). So the result proceeds through the pairing logic, never finds its matching call, and is emitted alone with call == null.

Consequence for every MCP connector tool invocation:

• The child span is named generically "mcp_tool" (derived by stripping "_tool_result" off the result's type) instead of the real tool name, because the fallback naming path only runs when call == null.
• input_json is never set on the span, because the input-extraction path also returns null when call == null. The tool's name, server_name, and input arguments — which live only in the dropped mcp_tool_use block — are permanently lost from the structured child span.

The raw response body is still present in the parent LLM span's full JSON passthrough, so the data isn't gone from Braintrust entirely, but the per-tool-call child span that Braintrust's UI specifically surfaces for tool calls is broken for every MCP connector invocation — call name and input are unrecoverable from that span.

Braintrust docs status: supported

Braintrust's docs at https://www.braintrust.dev/docs/integrations/ai-providers/anthropic describe this capability for the Python SDK: tool calls (including MCP connector tool calls) are captured "with its input and result ... named after the tool" as dedicated spans. This confirms the capability is documented/expected, just not delivered correctly by the Java SDK.

Why this isn't speculative

The identical bug (same mechanism: literal match on "server_tool_use", suffix-based result matching that doesn't require a paired call) was already found and fixed in Braintrust's Python SDK — see braintrustdata/braintrust-sdk-python#797 (fixed in py-sdk-v0.44.1) — and is tracked as still-open for the Go SDK in braintrustdata/braintrust-sdk-go#107. The fix was never ported to the Java SDK.

Upstream sources

• https://docs.anthropic.com/en/docs/agents-and-tools/mcp-connector — documents the mcp_tool_use / mcp_tool_result content block shapes (e.g. {"type":"mcp_tool_use","id":"mcptoolu_...","name":"<tool>","server_name":"<server>","input":{...}}), distinct from server_tool_use.
• https://github.com/anthropics/anthropic-sdk-java/blob/v2.2.0/anthropic-java-core/src/main/kotlin/com/anthropic/models/beta/messages/BetaContentBlock.kt — confirms these block types were already modeled in the Anthropic Java SDK at the version this repo pins (2.2.0). This instrumentation parses raw JSON directly rather than typed SDK objects, so the gap is a pure string-literal dispatch miss, not an SDK-version-currency issue.
• https://github.com/braintrustdata/braintrust-sdk-python/issues/797 — identical bug, already fixed in the Python SDK.
• https://github.com/braintrustdata/braintrust-sdk-go/issues/107 — same class of bug, open in the Go SDK.

Local repo files inspected

• braintrust-sdk/src/main/java/dev/braintrust/instrumentation/InstrumentationSemConv.java — ANTHROPIC_SERVER_TOOL_USE_TYPE constant and dispatch check; addAnthropicServerSideChildSpans (call registration loop); isAnthropicToolResultType (suffix-based result matching); emitAnthropicServerToolSpan, anthropicToolSpanName, anthropicToolSpanInput (fallback behavior when call == null).
• braintrust-sdk/instrumentation/anthropic_2_2_0/src/test/java/dev/braintrust/instrumentation/anthropic/v2_2_0/BraintrustAnthropicServerSideSpansTest.java — only exercises web_search/server_tool_use; no mcp_tool_use/mcp_tool_result test coverage exists.
• Repo-wide search for mcp_tool_use / mcp_tool_result / "MCP connector" — zero matches outside this finding.

Suggested fix

Recognize "mcp_tool_use" as an additional call-type alongside "server_tool_use" when populating the call-tracking map (the existing suffix-based result matching already handles "mcp_tool_result" correctly once a matching call is registered), and add a test mirroring the existing server_tool_use test for the MCP connector block pair.