# MCPツール結果 クライアント受入試験票

種別：規範＝MCP仕様の条件／追加＝採用するアプリが自分で決める条件／観測＝ホスト（製品）固有の挙動。
結果欄は PASS / FAIL / 取得不可 と、証拠（ログのパス・ID）を書く。

## 実行条件

```yaml
server_name: ""
server_commit: ""
server_sdk_and_version: ""
host_product: ""
host_version: ""
client_sdk_and_version: ""
transport: "stdio | Streamable HTTP"
protocol_version_on_wire: ""
model_and_settings: ""
resource_read_route: "resources/read | direct HTTPS | dedicated tool | unsupported"
auth_context: "tenant/role only; never record credentials"
result_size_utf8_bytes: ""
model_visible_capture_method: "debug trace | observable answer with marker | unavailable"
executed_at_utc: ""
evidence_path_or_id: ""
```

## 試験

| ID | 種別 | 操作 | 合格基準 | 結果 / 証拠 |
|---|---|---|---|---|
| W01 | 規範 | 2026-07-28の正常resultを受信 | `resultType:"complete"` と `content` がある。JSON-RPCのidが対応する | |
| W02 | 規範 | 各requestを送る | 版と`clientCapabilities`を`_meta`に含める。`clientInfo`も付ける | |
| T01 | 追加 | search_textを呼ぶ | textのJSONを解析すると共通データと一致する。追加readは不要 | |
| T02 | 追加 | text中のtotalを文字列に改変 | MCPの外形検査が通っても、業務型の合格にしない | |
| S01 | 規範＋追加 | search_structuredを呼ぶ | structuredContentが宣言したoutputSchemaに適合する。クライアントの検証が有効 | |
| S02 | 規範 | outputSchema付きの正常結果からstructuredContentを除く | サーバーの契約違反。クライアントが失敗として見せる | |
| S03 | 追加 | `total:"2"`を返す | 検証で不合格。成功データとして後続処理しない | |
| S04 | 追加 | `total:999`でhitsは2件 | 型検証と意味検証を分ける。意味検査で不合格にする | |
| S05 | 追加 | textとstructuredContentを違う値にする | 一致検査で不合格。正本から両方を作り直す | |
| S06 | 規範＋追加 | array / null / false / 0 / 空文字を許容するschemaで返す | 欠落と誤判定しない。旧版にも提供するなら互換を別途確認 | |
| S07 | 規範 | structuredContentがあり、contentを省く | wire検査で不合格。`content:[]`との違いを確認 | |
| E01 | 追加 | search_embeddedを呼ぶ | resource.textが共通データと一致する。本文のための追加readは無い | |
| E02 | 追加 | MIMEはJSONで、textは壊れたJSON | resource外形の合格と、本文JSONの不合格を区別する | |
| E03 | 観測 | 同梱本文の末尾に確認用マーカーを入れる | 対象ホストのモデルがマーカーを使えたか記録する | |
| L01 | 規範＋追加 | search_linkを呼ぶ | `type`・`uri`・`name`がある。本文が応答にあるものとして扱わない | |
| L02 | 追加 | resources/listは空で、URIは有効 | 一覧掲載を前提にせず、受信元サーバーへreadして本文が一致する | |
| L03 | 追加 | キャッシュが空の状態でリンク本文を要求 | 追加readの回数と経路を記録する。0回なら本文の出どころを特定する | |
| L04 | 追加 | resources機能を持たないホスト | URIだけで完了にしない。unsupportedを表示するか、決めた代替の読取りを使う | |
| L05 | 規範 | 未知・期限切れのURIをread | `-32602`で失敗する。空の`contents`でごまかさない | |
| L06 | 追加 | 接続を変えて同じURIをread | 接続の暗黙状態に頼らず、決めた保持・認可の契約で読める | |
| L07 | 追加 | 他テナント・権限取消し後にread | 再認可される。本文もキャッシュも漏れない | |
| L08 | 追加 | 同じURIを別サーバーも返す | 受信元サーバーを取り違えない | |
| C01 | 規範 | resources/read成功 | `ttlMs`と`cacheScope`を含む | |
| C02 | 規範＋追加 | privateの結果を別の認可文脈で要求 | キャッシュを共有しない。権限変更も試す | |
| R01 | 規範 | outputSchemaに外部ネットワークの`$ref` | 既定で通信しない。未解決を黙って許容しない | |
| R02 | 追加 | 深いoneOf/anyOfなど | 検証の時間・深さ・サイズの上限を守る | |
| H01 | 観測 | 4形式を同じホストで実行 | raw受信、UI表示、モデル可視、read可能を別々に記録する | |
| H02 | 観測 | 結果サイズを段階的に増やす | 切詰め・保存・拒否の閾値と、本文取得を続けられるかを記録する | |
| F01 | 規範＋追加 | tool resultが`isError:true` | 業務成功として集計しない。tool errorとprotocol errorを分ける | |
| F02 | 規範＋追加 | readが`input_required`を返す | 本文扱いせず、MRTRとして処理する。非対応なら明示的に失敗する | |