MCPを「使う側」から「作る側」の視点へ。AIが正しいツールを選べるかは説明文の書き方で決まり、エラーから回復できるかはエラーの返し方で決まる——という設計思想のドメイン。tomoさんの伸びしろが最も大きい領域。
analyze_content と analyze_document）は誤ルーティングの温床analyze_content → extract_web_results）→ 汎用ツールを目的別に分割（例：analyze_document を「データ点抽出」「要約」「出典照合」の3つへ）agents/skills の frontmatter description がまさにこれ。config-optimizer エージェントが「description品質」を監査項目にしているのは、この試験思想の運用版。skills の description に「〜のときに起動 / 〜は別スキルへ」と境界を書き込む流儀（例: seo-schema「サイトマップはseo-sitemapを使う」）は満点回答のパターン。
isError フラグ：ツールの失敗をエージェントに伝える標準の仕組みerrorCategory（transient/validation/permission）＋ isRetryable（真偽値）＋ 人間が読める説明文retriable: false ＋ 顧客向けに説明できる文言を付ける（AIが適切に謝れる）failed経験の宝庫。integration-discovery ルールの「2>/dev/null でstderrを捨てて空判定するな」は「一般エラーと正当な0件の混同」事故そのもの（Metabase初見化事件）。x-posting-worker のIPガチャ（Geminiの間欠エラー→5分後リトライで自己回復）は transient / isRetryable=true の実例。n8n診断の「生エラーログから読む」も同じ思想。
tool_choice で強制する。verify_fact（単純な事実確認専用）を渡し、複雑な検証は従来どおりコーディネーター経由——85%の単純ケースの往復を削減しつつ関心の分離を守る（サンプル問題Q9の正解）fetch_url → 文書URLだけ通す load_document）tool_choice の3モード："auto"（ツールを使うかもモデル判断＝テキスト返答もあり得る）／"any"（必ずどれかのツールを呼ぶ）／{"type":"tool","name":"..."}（特定ツールを強制）extract_metadata を走らせたい→強制指定、会話文でなく必ず構造化出力が欲しい→ "any"agents/*.md の tools 制限そのもの。verification-agent は読み取り専用（Read/Grep/Glob/Bash）、planner は Read/Grep/Glob のみ、audit系はWrite封印——「役割外のツールは渡さない」の実装。52体のエージェントにフルツールを渡していないのは、まさにこの試験原則。
.mcp.json（プロジェクト直下・git管理）、個人の実験なら ~/.claude.json（ユーザー領域）。秘密鍵は環境変数参照で書き、ファイルに直書きしない。.mcp.json（チーム共通ツール）vs user-level ~/.claude.json（個人・実験用）.mcp.json 内の環境変数展開（例：${GITHUB_TOKEN}）で、シークレットをコミットせずに認証情報を管理16本のMCPサーバー運用と registry/integrations.yaml（接続情報のSSOT）。「シークレットは環境変数参照」は、うちでは op:// 参照＋opx で徹底している（試験の${VAR}方式と同じ思想の上位互換）。「コミュニティサーバー優先・自作は固有ニーズのみ」は resilience-first の判定表と同じ考え方。
**/*.test.tsx）毎日使っている道具そのもの。運用知見の蓄積（feedback-edit-before-read「Edit/Write前に同一会話でRead」、ensoレッスン「Globにはpathを付けて範囲を絞る」）は試験知識の実戦版。このタスクステートメントは新規学習ゼロでよい。
MCPツールの結果が「失敗である」ことをエージェントに伝える標準フラグ。これに errorCategory / isRetryable などのメタ情報を添えるのが構造化エラー応答。
エラーの種類（transient=一時的 / validation=入力不正 / permission=権限）と、リトライで直る見込みがあるかの真偽値。これが無いとAIは「もう一回試す価値があるか」を判断できない。
ツール使用の強制度を決めるAPI設定。"auto"=使うかはモデル次第／"any"=必ずどれかのツールを呼ぶ／{"type":"tool","name":"..."}=指名したツールを必ず呼ぶ。
役割の壁を越える高頻度ニーズにだけ、機能を絞った専用ツールを渡す設計。「85%の単純ケースは直接、15%の複雑ケースはコーディネーター経由」のような最小権限の落とし所。
MCPサーバー設定の置き場所。前者=プロジェクト直下・git共有（チーム用）、後者=ユーザー個人（実験用）。シークレットは ${ENV_VAR} 参照で書く。
「実行するもの（ツール）」ではなく「参照するもの（コンテンツカタログ）」をMCPサーバーが公開する仕組み。issue一覧・DBスキーマなどを渡しておくと、エージェントの探り打ちツールコールが減る。
「検索は成功したが該当なし」と「検索自体ができなかった」は別物。混同すると、無いだけのものを延々リトライしたり、障害を「該当なし」と誤報したりする。