MCP Tools spec は、tool 連携の責任を「文字列返却」から型と確認へ押し戻す

要点

要点まとめ

MCP で社内 tool をつないでも、ただ呼べれば終わりではない。何が返るか、失敗か、危険操作の前に止めるかを曖昧にすると運用事故になる。
この spec の価値は、その曖昧さを protocol の外へ逃がさず、tool の入出力、失敗表示、更新通知、人間確認まで論点として明示している点にある。
`outputSchema` は返り値の形、`structuredContent` は機械が読みやすい結果、`isError` は実行失敗の印である。text だけ返す雑実装より、後で検証しやすい。
`listChanged` や pagination、sensitive operation 前の confirmation も書かれており、host 側 UI と監査責任は消えない。接続成功より、その後の扱い方が本体である。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む 作る前に確認したい

API や設定を試す前に、先に落とし穴を知りたい人向け。

同じテーマで読む AIエージェント

ツール利用、MCP、Agent SDK、長時間タスク、実行責任の設計。

次の記事 Responses API の組み込みツールは、Agent 実装の責任分界を変える

OpenAI は Responses API に remote MCP servers、image generation、Code Interpreter、file search 改善などを追加した。

読解

何が変わったのか

このページでは tool definition に `inputSchema` だけでなく `outputSchema` を置けること、result に `structuredContent` を持てること、execution error を `isError: true` で区別できることが示されています。これは大きいです。tool を LLM 向け文字列 API ではなく、型付きの操作面として扱う方向だからです。さらに user interaction model で、人間が deny できること、tool expose 状態を UI で明確にすること、confirmation prompt を出すことまで推奨しています。つまり protocol は model-control を認めつつも、無人実行を当然視していません。

日本の文脈

なぜ重要か

日本の社内導入では、MCP は「つながるか」までは通っても、「何を返すか」「失敗をどう見せるか」「確認 UI は誰が作るか」で止まりやすいです。この spec は、その停止点が実装責任として正しいことを裏付けます。また、tool result を text blob で押し切る雑実装は、後で監査、再利用、型検証、UI 表示で苦しくなります。spec を読むと、最初から structured result に寄せたほうがよい理由が分かります。

技術ポイント

技術的ポイント

`outputSchema` は tool output の期待構造を定義する。client と LLM が返り値を安全に扱う土台になる。
`structuredContent` は text とは別に機械可読な結果を返せる。UI 表示、後続 tool、保存処理で再利用しやすい。
`isError` は protocol error と別に tool execution error を示す。API failure や business logic error を返答文に埋めるだけで済ませないための仕組みだ。
`listChanged` は tool 一覧の変化通知を持てる。接続後に tool 面が変わる運用を前提にしている。
spec は sensitive operation 前の user confirmation、tool input 表示、tool usage log も client 側へ求めている。host UI と監査は省略できない。

用語

英日キーワード

英語	日本語	補足
outputSchema	出力スキーマ	tool が返すデータ構造の定義。text だけ返す実装より後で検証しやすい。
structuredContent	構造化コンテンツ	text と別に返す機械可読データ。UI 表示や後続処理で再利用しやすい。
isError	ツール実行エラー印	tool 内部失敗を返すための印。protocol error と business logic error を分けやすくする。
listChanged	一覧変更通知	tool list が変わったことを知らせる能力。接続後に操作面が変わる運用を前提にしている。
pagination	ページ分割	一覧を分割取得する仕組み。tool surface が増えた時に全部を一度に渡さない前提になる。
MCP	Model Context Protocol	AI アプリが外部ツールやデータ源に接続するためのプロトコル。ツールだけでなく resources / prompts も含む。

試す

試すなら

まず今の MCP tool 返り値が text だけか、構造化データを分けて返せるかを棚卸しする。
失敗時に文章だけ返している tool は、`isError` と入力検証を分けて扱う設計へ直す。
書き込み系 tool では、call 前 confirmation と input preview を UI に入れる。
tool list が変わる server では、client 側に再取得と監査ログの動作確認を入れる。

注意

注意点

spec に書かれていても、各 client が全部を同じ水準で実装しているとは限らない。
`structuredContent` を入れても、schema drift や version 管理を怠ると結局壊れる。
human confirmation を足すだけで安全になるわけではない。どの操作を sensitive とみなすかの設計が先に必要である。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。