MCP のツール結果には content と structuredContent の2チャンネルがあり、役割が分かれている。content はモデル（LLM）向けで可読性とトークン効率に最適化された面、structuredContent は機械（クライアント／レンダリング層）向けの構造化データで、出力スキーマによる型検証やプログラム連携のための面。重要なのは、structuredContent がクライアントに届いてもモデルのコンテキストに入るとは限らない点。ウィジェット描画専用に回してトークンコストをゼロにする使い方が推奨されるケースもあり、モデルに渡すかどうかはクライアント（ホストアプリ）実装に依存する。

誤解しやすい条件

• 「サーバーが structuredContent を返している」ことと「モデルがそれを読める」ことは別問題。あるクライアントではモデルに渡り、別のクライアント（ターミナル型で構造化データを無視するもの等）では渡らない。同じサーバーでもクライアントごとに挙動が変わりうる。
• モデルが明細を読めなかったとき、それは多くの場合バグではなく仕様の設計どおりの挙動。content と structuredContent の役割分担に沿っている。両方あるときどちらを優先すべきかは仕様が明示的に規定しておらず（明確化が議論中の段階）、クライアント差が「あり」の状態だと捉える。

判断基準

• LLM に確実に読ませたいデータは、structuredContent 任せにせず content のテキストブロックにも載せる。仕様も後方互換のため「構造化を返すツールはシリアライズしたデータをテキスト側にも入れるべき」としており、これに従うのが移植性の高い実装。
• structuredContent は、ウィジェット等クライアント側でのレンダリングや、大きなデータをコンテキストに載せずに渡す用途に使う。逆にモデルの判断・後続の推論に必要な値をここだけに置かない。
• 件数サマリや要約だけを content に返し、明細を structuredContent にしか入れないと、テキスト面しか読まないクライアント／モデルからは明細が存在しないように見える。「structuredContent には入れてある」は、テキスト面しか見ない消費者への免罪符にならない。

検証

対象ツールを、structuredContent を無視してテキスト面だけを情報源にする経路で呼び、必要なデータがそれだけで揃うかを確認する。揃わなければ、その経路のモデル／クライアントはそのデータを利用できない。

関連

「MCP ツール説明と structuredContent は同時に整える」（structuredContent を後続処理向けに安定キーで返す設計）とは別軸で、こちらは『そもそもモデルが structuredContent を読めるかはクライアント依存なので、モデル向けデータは content にも置く』というチャンネル選択の話。