MCP の OpenTelemetry トレース計装

model-context-protocol (MCP) サーバ/クライアント間のやり取りを opentelemetry-observability の Trace として可視化する取り組み。LLM アプリケーションは「クライアント → MCP サーバ → 外部 API → LLM」と多段に処理が流れるため、どこで時間がかかったか・どんな引数で Tool が呼ばれたかを分散トレースで追いたい、という動機がある。

プロトコル側の議論

標準化に向けた提案・Issue が複数走っている。

• modelcontextprotocol#269 — MCP への OpenTelemetry Trace サポート追加提案。
• python-sdk#421 — MCP SDK への OpenTelemetry 導入。
• traceloop/openllmetry#2662 — OpenLLMetry の MCP 対応リクエスト。
• open-telemetry/semantic-conventions#2043 — MCP 向けの semantic conventions（span 名・属性の標準化）。

MCP は仕様面で LSP に似ている（リクエスト/レスポンスの構造）という指摘があり、計装の設計でもこの類似が参照される。

未対応・課題

• Sampling（サーバ → クライアント方向のリクエスト、LLM 補完を逆方向に要求する機能）のトレースは未対応。
• 独自に OTel 計装した事例はあるが、semantic conventions が固まっていないため属性の付け方が実装依存になる。

A2A への接続

リモート MCP や A2A (Agent2Agent) プロトコルが普及すると、エージェント間通信もトレース対象になる。MCP がツール接続（垂直方向）を、A2A がエージェント協調（水平方向）を担うという整理がなされている。

関連: model-context-protocol・opentelemetry-observability・llm-observability・rust-opentelemetry-tracing