mcp-server integration: align attribute names to current OTel GenAI/MCP semconv

[dcramer]

The MCP server integration's attributes.ts is pinned to an old draft of the OTel MCP spec (commit 3097fb0 in the now-deprecated open-telemetry/semantic-conventions repo). The spec has since moved to open-telemetry/semantic-conventions-genai and the attribute names have materially changed.

Wrong attribute names

The following SDK constants emit the wrong attribute key. Each has a verified spec equivalent.

SDK constant	Emits	Should emit	Requirement level	Source
MCP_TOOL_NAME_ATTRIBUTE	mcp.tool.name	gen_ai.tool.name	Conditionally required (tool calls)	common.yaml
MCP_PROMPT_NAME_ATTRIBUTE	mcp.prompt.name	gen_ai.prompt.name	Conditionally required (prompt ops)	common.yaml
MCP_REQUEST_ID_ATTRIBUTE	mcp.request.id	jsonrpc.request.id	Conditionally required (requests)	spans.yaml
MCP_TRANSPORT_ATTRIBUTE	mcp.transport	network.transport	Recommended	common.yaml
MCP_REQUEST_ARGUMENT (prefix)	mcp.request.argument.<key>	gen_ai.tool.call.arguments (single attr)	Opt-in	spans.yaml
MCP_TOOL_RESULT_CONTENT_ATTRIBUTE	mcp.tool.result.content	gen_ai.tool.call.result (single attr)	Opt-in	spans.yaml
MCP_TOOL_RESULT_IS_ERROR_ATTRIBUTE	mcp.tool.result.is_error	error.type = "tool_error"	Conditionally required	common.yaml

Notes:

• network.transport values SHOULD be tcp or quic for HTTP transport and pipe for stdio — not the MCP-level transport name.
• gen_ai.tool.call.arguments and gen_ai.tool.call.result are single serialized attributes, not per-key prefixes.
• mcp.tool.result.content_count has no spec equivalent at all.

Missing attributes

Attribute	Requirement level	Source	Notes
gen_ai.operation.name	Recommended	common.yaml	SHOULD be execute_tool on tool call spans; allows consumers to treat MCP tool spans like other GenAI tool spans
rpc.response.status_code	Conditionally required	common.yaml	When response contains a JSON-RPC error code
jsonrpc.protocol.version	Recommended	common.yaml	When not 2.0

Custom attributes with no spec equivalent

These are Sentry-invented attributes that don't appear in the OTel spec. They may be worth keeping as explicit Sentry extensions, but should be documented as such and should not use namespaces that conflict with or extend spec-owned ones:

• mcp.client.name, mcp.client.title, mcp.client.version
• mcp.server.name, mcp.server.title, mcp.server.version
• mcp.logging.level, mcp.logging.logger, mcp.logging.data_type, mcp.logging.message
• mcp.prompt.result.description, mcp.prompt.result.message_count, mcp.prompt.result.message_role, mcp.prompt.result.message_content

The mcp.* namespace in the spec covers only: mcp.method.name, mcp.session.id, mcp.resource.uri, mcp.protocol.version. Anything else under mcp.* risks colliding with future spec attributes.

Spec references

• open-telemetry/semantic-conventions-genai — model/mcp/ (current authoritative source)
• common.yaml — shared attributes including gen_ai.tool.name, gen_ai.prompt.name, gen_ai.operation.name
• spans.yaml — span definitions with gen_ai.tool.call.arguments, gen_ai.tool.call.result
• registry.yaml — full mcp.* attribute registry (only 4 attributes)

[linear-code]

JS-2760

[dcramer]

the per key prefixes we intentionally wanted when we implemented this, so i think we should keep that, but we should support the gen_ai prefixes broadly