MCP Server 在 Claude Code 與 Agent 工作流程中的整合

MCP server 整合是 CCA-F 考試中 Claude Code 最具特色的可擴充性入口。任務說明 2.4——「將 MCP servers 整合到 Claude Code 與 agent 工作流程中」——屬於 Domain 2（Tool Design & MCP Integration，佔比 18%），並且是兩個最常考情境的核心：Developer Productivity with Claude 與 Code Generation with Claude Code。若考生無法正確判斷 MCP server 整合的作用域、憑證處理方式，或 MCP tool 與 MCP resource 的差異，在通過線僅 720/1000 的考試中，很容易就損失四到六分。

這份學習筆記完整涵蓋架構師應熟悉的 MCP server 整合面向：Model Context Protocol 本身、project 層級的 .mcp.json 與 user 層級的 ~/.claude.json 的差異、如何透過環境變數展開讓機密遠離版本控制、Claude Code 如何在連線時從所有已設定的 MCP servers 發現並合併工具、MCP tools 與 MCP resources 的結構差異、採用現有社群 MCP servers 還是自行開發的決策準則，以及常被忽略的強化 MCP tool descriptions 以讓 agent 優先使用它們而非內建工具。每個章節都以 CCA-F 辨識深度撰寫——著重架構判斷，而非實作程式碼。

Model Context Protocol 是什麼？Claude Code 為何需要它？

**Model Context Protocol（MCP）**是一個開放規格，透過統一的訊息介面將 AI 助手連接到外部系統——資料庫、API、檔案儲存、問題追蹤系統。在 MCP 問世之前，每個 AI 用戶端都必須發明自己的外掛格式，每個工具提供商也必須為每個用戶端分別開發轉接器。MCP 將這個 N × M 的整合矩陣壓縮成 N + M：一個 server 實作可供所有支援 MCP 的用戶端使用，而一個用戶端也能連接所有 MCP server。官方 MCP 規格將這個設計比喻為「AI 應用程式的 USB-C」——任何符合規格的插頭都能插入任何符合規格的插座。

Claude Code 是目前生產環境中最原生支援 MCP 的用戶端之一。一個 Claude Code session 可以同時連接多個 MCP servers，並將它們的工具目錄合併成 Claude 在 agentic loop 中推理時使用的單一工具清單。對於 Claude Code 架構師而言，MCP server 整合並非可有可無的附加功能——它是真實工程團隊將 Claude Code 從內建的 Read / Write / Edit / Bash / Grep / Glob 工具延伸至內部系統的主要機制。

MCP 三種原語一覽

MCP server 整合會暴露下列三種原語的某些組合：

• MCP tools — 可呼叫、有副作用的函式。例如：create_jira_ticket、run_sql_query、send_slack_message。
• MCP resources — 以 URI 定址的可讀內容單元。例如：jira://issue/PROJ-123、db://schema/orders、docs://handbook/deployment。
• MCP prompts — 用戶端可插入的可重複使用提示範本。例如：一個預先填入調查步驟的「bug-triage」提示。

CCA-F 考試持續測試 tools vs resources 的區別。若考生將所有 MCP 能力都視為「tool」，就會在「哪個原語可暴露供模型在呼叫工具前瀏覽的內容目錄？」這類問題上失分——答案永遠是 resources。

為什麼 MCP 出現在 CCA-F 考綱中

Domain 2 將 MCP 整合的權重定為 18%，任務 2.4 特別針對 Claude Code 整合。社群考試報告（Kukreja 893/1000、Hightower 完整指南、McRolly 技術路線圖）都將 MCP tool 邊界與作用域標記為高頻陷阱（pain point pp-12）。了解這個協定存在的原因——互通性、最小權限擴充、server 關切點與 client 關切點的分離——的考生，能夠在不死背設定旗標的情況下正確回答作用域與憑證問題。

Project 作用域 vs User 作用域：.mcp.json vs ~/.claude.json

CCA-F 考試中 MCP server 整合最常測試的面向是作用域。Claude Code 從兩個位置讀取 MCP server 定義，兩者的選擇對團隊協作、憑證安全與設定一致性都有直接影響。

Project 作用域 — 儲存庫根目錄的 .mcp.json

當 Claude Code 工作區的根目錄（通常是儲存庫根目錄）存在名為 .mcp.json 的檔案時，Claude Code 會在每次於該工作區啟動 session 時載入其宣告的 MCP servers。由於 .mcp.json 已提交到儲存庫，團隊中的每位開發者、每個 CI runner，以及每個 clone 了該儲存庫的自動化 agent，都會獲得完全相同的 MCP server 清單。Project 作用域適合共享的團隊工具：整個團隊查詢的 Jira server、支援共享分析工作流程的資料庫 schema server、發布流程使用的 staging 環境部署 server。

User 作用域 — home 目錄的 ~/.claude.json

第二個 MCP 設定位於每位開發者 home 目錄的 ~/.claude.json。這裡的項目是個人的——無論使用者在哪個儲存庫啟動 Claude Code session，這些設定都會套用，但永遠不會與隊友共享。User 作用域適合開發者專屬的工具：個人筆記 server、私人書籤管理工具、仍在積極開發中的實驗性 MCP server，或開發者不希望其他團隊成員看到的高度憑證整合。

選擇 Project 作用域還是 User 作用域

考試測試的決策規則很明確：

• 與團隊共享？→ project 作用域（.mcp.json）。
• 個人或實驗性？→ user 作用域（~/.claude.json）。

架構錯誤在兩個方向都會發生。把團隊共享的 Jira server 放在 user 作用域，會迫使每位開發者手動重新安裝，並造成設定漂移（「為什麼我的 Claude Code 看不到 Jira 工具？」）。把個人實驗性 server 放在 project 作用域，則會用隊友沒有要求、也無法使用的東西污染所有人的工具清單。

為什麼兩個作用域可以同時啟用

Claude Code 在 session 啟動時會合併兩個檔案中的 server。若開發者在 project 層級的 .mcp.json 宣告了 Jira server，並在 user 層級的 ~/.claude.json 宣告了個人筆記 server，則執行中的 session 會同時看到兩個 server 的工具。合併是加法式的，而非排他性的，因此 user 作用域的項目不會覆蓋或與 project 作用域的項目衝突，除非它們使用相同的 server 名稱。架構師應選擇能清楚傳達作用域的名稱（如 team-jira、personal-notes），以避免意外遮蔽。

環境變數展開：讓機密遠離 .mcp.json

由於 .mcp.json 已提交到版本控制，它絕不能包含憑證。將 GitHub 個人存取權杖、Jira API 金鑰或資料庫密碼寫死在 .mcp.json 中，會將機密洩漏給每個儲存庫 clone、每個 fork，以及每個爬取 diff 的 GitHub 搜尋。這是 MCP server 整合中嚴重程度最高的錯誤之一，而 CCA-F 考試會直接測試它。

${VAR_NAME} 展開語法

Claude Code 在 .mcp.json 項目中支援環境變數展開。任何格式為 ${VAR_NAME} 的字串，都會在 session 啟動時被替換為環境變數 VAR_NAME 的值。標準做法如下：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

提交到儲存庫的檔案只包含佔位符 ${GITHUB_TOKEN}。每位開發者在自己的 shell 環境中設定 GITHUB_TOKEN（透過 .envrc、direnv、1Password CLI 或機密管理工具整合），Claude Code 則在執行時解析這個變數。機密永遠不會進入儲存庫。

可擴展的憑證處理模式

對於小型團隊，direnv 加上一個（git 忽略的）.envrc 檔案就已足夠。對於較大的組織，模式則變成：

• 開發者機器 → 1Password CLI 或 AWS Secrets Manager → 環境變數 → .mcp.json 展開。
• CI runner → GitHub Actions Secrets 或 GitLab CI 變數 → 環境變數 → .mcp.json 展開。
• 共享的 CLAUDE.md 記錄所需的變數名稱，讓每位開發者無需猜測即可完成上線。

這種分層設計意味著 .mcp.json 檔案本身保持穩定且可審閱，而機密面則移至組織已信任的機密管理工具。

Claude Code 如何在連線時發現工具

架構師在推理 MCP server 整合時，必須理解 session 的生命週期。當 Claude Code 啟動 session 時，會依序執行以下步驟：

1. 從工作區根目錄讀取 .mcp.json（若存在）。
2. 從使用者 home 目錄讀取 ~/.claude.json（若存在）。
3. 將兩個 server 清單合併為一個連線計畫。
4. 並行啟動每個 stdio server（或撥接每個遠端 server）。
5. 對每個成功連線的 server，透過 MCP 的 tools/list 方法查詢其工具目錄。
6. 透過 resources/list 查詢每個 server 的 resource 目錄。
7. 將所有發現的工具與 Claude Code 的內建工具串接成一個清單。
8. 將合併後的清單提供給 Claude，並在整個 session 期間保持有效。

有兩個架構後果對考試至關重要：

所有已設定 Server 的工具可同時使用

一旦發現完成，Claude 就能看到每個已連線 MCP server 的所有工具，加上每個內建工具，形成一個扁平清單。不存在每個回合過濾 Claude 能連接哪些 server 的機制——只要 server 已連線，它的所有工具都可使用。這就是為什麼將工具分散到不同 agent（任務 2.3）很重要：同時連接太多 MCP server 的 agent，最終會有數百個工具在其 context 中，既增加 token 成本，又降低 Claude 的路由準確度。

發現只在每個 Session 進行一次

MCP 工具發現是一個連線時的操作。若你在 session 進行中途新增一個 MCP server 項目到 .mcp.json，Claude Code 要到下次 session 啟動才能看到它。這對長時間執行的自動化工作流程很重要：請為整個 session 設計設定，而非漸進式新增。

MCP Tools vs MCP Resources：影響得分的原語差異

MCP tools vs MCP resources 的區別是 Domain 2 中最少被研究的主題，而 CCA-F 考試在幾乎每次考試中都會測試它。

MCP Tools

MCP tool 是一個有副作用或計算輸出的可呼叫函式。呼叫一個 tool 需要完整的 agentic loop 往返：Claude 發出 stop_reason: "tool_use"，用戶端執行工具，結果以 tool_result 區塊回傳，Claude 繼續推進。Tools 是 agent 做事的方式——建立工單、執行查詢、發送訊息、執行腳本。

MCP Resources

MCP resource 是以 URI 定址的可讀內容單元。Resources 是 server 暴露內容目錄的方式——問題摘要、文件層次結構、資料庫 schema、檔案樹——讓模型在不付出完整 tool 呼叫成本的情況下瀏覽。設計良好的 MCP server 會將模型想要讀取的內容暴露為 resources，並將模型想要執行的操作暴露為 tools。

為什麼 Resources 能減少探索性 Tool 呼叫

想像一個只暴露 tools 的 Jira MCP server：search_issues(query)、get_issue(id)、create_issue(...)、update_issue(...)。當 Claude 想找到正確的工單來更新時，它必須猜測 search_issues 的關鍵字，檢視幾個候選項，再重新猜測，反覆迭代。每次迭代都是一次完整的 tool 呼叫往返。

現在想像同一個 server 在 jira://project/PROJ/open-issues 暴露了一個問題目錄 resource，回傳一份包含 ID、標題和狀態的開放工單精簡清單。Claude 可以在對話開始時讀取一次該 resource，透過對比使用者請求進行模式匹配找出相關工單，然後直接呼叫 get_issue(id) 或 update_issue(...)——零猜測。更少的 tool 呼叫、更低的 token 成本、更高的準確度。

同樣的模式也適用於文件層次結構（一個 resource 回傳目錄；tools 取得特定頁面）和資料庫 schema（一個 resource 回傳 schema 概覽；tools 執行特定查詢）。

考試信號：「減少探索性 Tool 呼叫」

當 CCA-F 情境描述「agent 在找到正確記錄之前進行了許多試探性的搜尋呼叫」時，解法幾乎總是「將目錄暴露為 MCP resource，讓 agent 在呼叫 tools 之前先行瀏覽」。提議「新增更多 tools」或「增加搜尋工具的 limit 參數」的答案，都錯過了架構洞察。

白話說明 MCP Server 整合

抽象的協定設計，一旦錨定在具體的日常情境上，就會變得直觀。三個截然不同的類比涵蓋了 MCP server 整合概念的完整面貌。

類比一：辦桌廚房 — Tools、Resources 與 Servers

想像 Claude Code 是一位主廚，掌管一個廚房。主廚的內建工具就是廚房配備的刀具、鍋具和爐台——Read、Write、Edit、Bash、Grep、Glob。MCP servers 是按需推入的專業工作站：麵食製作站（Jira server）、烘焙站（資料庫 server）、低溫慢煮站（部署 server）。每個工作站都附帶自己的一套 MCP tools——麵食機的按鈕、低溫慢煮機的溫控旋鈕——主廚都可以操作。

MCP tools 與 MCP resources 的差異，在同一個廚房中也有對應。麵食機在按下按鈕時會做某件事（那是 tool）。貼在工作站側面的食譜冊，主廚不需要按任何東西就能閱讀，那是 resource。一個裝備完善的工作站兩者都有：食譜冊告訴主廚這個工作站能做什麼；按鈕才真正產出料理。

Project 作用域（.mcp.json） 是廚房牆上共用的設備清單——每位廚師、每個班次，都看到相同的工作站。User 作用域（~/.claude.json） 是主廚自己帶來的個人工具包——個人慣用的刨刀、自訂溫度計——下班後跟著他回家。環境變數展開是存放憑證（冷凍庫鑰匙、酒類許可證）的保險箱；牆上的設備清單寫的是「保險箱裡的鑰匙」，而不是直接印出鑰匙本身。

類比二：圖書館 — Resources vs Tools 用於內容探索

圖書館的類比能讓 resource 與 tool 的差異更清晰。想像你走進一間參考圖書館，想找一本特定的書。圖書館提供兩種找書方式。

純 tool 方式是走到參考台，請館員以關鍵字搜尋書籍。每次搜尋都是一次往返——你說出關鍵字，館員消失進書架，帶著候選書目回來，然後你再查詢。錯了關鍵字就無止境地重來。

Resource 加 tool 方式是入口處的卡片目錄——一個你可以自行掃描的可瀏覽索引，讓你找到精確的索書號，然後再請館員取出那本特定的書。卡片目錄是 MCP resource：一個可讀的內容介面，減少你需要麻煩館員（tool）的次數。任何設計良好的圖書館兩者都有。

這個類比直接對應到 Jira 的例子。純 tool 的 Jira 整合迫使 Claude 不斷猜測搜尋關鍵字。將開放問題目錄暴露為 resource 的 Jira 整合，讓 Claude 可以瀏覽清單、找出正確工單，然後進行一次精準的 tool 呼叫來更新它。

類比三：開卷考試 — 作用域、憑證與發現

開卷考試的類比涵蓋了作用域與憑證處理。每位學生（開發者）帶著兩本資料夾來考場。課程發的資料夾（project 作用域——.mcp.json） 對每位學生都完全相同：包含全班都可以使用的公式、參考表和共用材料，提交到共用的課程大綱。個人資料夾（user 作用域——~/.claude.json） 是每位學生自己的筆記：旁注、個人記憶術、練習草稿。沒有兩位學生的個人資料夾是一樣的。

兩本資料夾都不允許包含解答（憑證）。解答密封在監考員的信封裡；每位學生在考試開始時被告知：「若你需要第 7 題的解答，參考代碼是 ${PROBLEM_7_KEY}，監考員會在需要時念給你聽。」這就是環境變數展開：已提交的資料夾以名稱引用機密，而非以值。

連線時發現就是學生只能使用考試開始時帶進考場的資料夾這條規定。若學生在考試中途發現忘帶某本資料夾，他無法出去取回——只能用手上的資料應付，等到下次開考（下次 Claude Code session）才能補齊。

考試當天選用哪個類比

• 關於 MCP tools vs MCP resources 的問題 → 圖書館類比。
• 關於 project vs user 作用域、憑證、環境變數 的問題 → 開卷考試類比。
• 關於 server 如何合併成一個 agent 工具清單 的問題 → 辦桌廚房類比。

社群 MCP Servers vs 自行開發

CCA-F 的架構題目反覆以採用現有社群 MCP server 還是從頭開發自訂 server 作為選擇框架。有原則的回答幾乎總是「標準整合用社群 server，團隊專屬工作流程才保留自建」。

為什麼標準整合優先選社群 Server

Anthropic、MCP 社群及第三方廠商為最常見的整合目標維護了 MCP servers：GitHub、Jira、Slack、Linear、Google Drive、PostgreSQL、Notion、Sentry。這些 server 的特性是：

• 經過實戰驗證 — 已在數千個 Claude Code 安裝環境中部署，邊緣案例早已被提報並修復。
• 符合規格 — 正確實作了 MCP 協定，包含分頁、錯誤格式和 resource URI。
• 持續維護 — 追蹤上游系統的 API 變更（GitHub API v4 遷移、Jira Cloud schema 更新），讓你的團隊不必自行追蹤。
• 易於發現 — 出現在 MCP 目錄中，可透過 @modelcontextprotocol/ 或知名廠商 npm 套件識別。

對於標準的「從 Claude Code session 建立 Jira 工單」工作流程，使用社群 Jira server 是正確的架構選擇。自行開發 Jira MCP server 會重複數個月的工作、帶來新的維護負擔，而且幾乎可以確定錯誤處理比社群版本更差。

為什麼團隊專屬工作流程才選自行開發

社群無法為你的內部系統維護 server。若你的團隊有：

• 沒有符合標準 MCP server 的公開 API 的自建內部工具（部署協調器、內部 CMS、專有分析平台）；
• 將多個內部系統組合成一個邏輯操作的領域特定工作流程（「建立客戶事故工單、連結到值班輪換、並將摘要發到事故頻道」）；
• 必須在特定網路邊界內或特定稽核控制下執行的合規敏感整合；

...那麼自建 MCP server 才是正確的選擇。自建 server 將團隊的內部複雜性封裝在乾淨的 MCP 介面後面，讓整個團隊的每個 Claude Code session 都自動繼承這個能力。

考試測試的決策規則

CCA-F 情境通常透過一個單詞或短語來表明正確選擇：

• 「整合 Jira / GitHub / Slack / PostgreSQL」→ 社群 MCP server。
• 「整合團隊的內部部署系統」→ 自建 MCP server。
• 「團隊正在評估幾個選項」→ 若社群 server 存在則優先，只有在沒有現成選項時才考慮自建。

強化 MCP Tool Descriptions 讓 Agent 優先選用

MCP server 整合中一個微妙但考試頻繁測試的調控點是 tool description。Claude Code 的內建工具（Read、Write、Edit、Bash、Grep、Glob）有精心調校的 descriptions，使它們成為一般檔案與 shell 操作的預設路由目標。當 MCP server 新增一個 description 較弱或較模糊的工具時，Claude 往往會退回到內建工具——即使 MCP tool 才是架構上正確的選擇。

Tool Description 即路由機制原則

這對應到更廣泛的 Domain 2 pain point（pp-02）：tool descriptions 是路由機制。當兩個工具重疊時，Claude 會路由到 description 更能精確描述當前任務的那個。description 為「部署一個服務」的自訂 MCP tool deploy_service，在路由競爭中會輸給精心調校的 Bash（其 description 明確列出使用案例）。若重新撰寫 description 為：「透過內部 rollout 控制器將指定服務部署到公司的 Kubernetes 叢集；任何部署任務請使用此工具，而非直接執行 kubectl 或 helm；接受服務名稱和目標環境；回傳部署狀態與回滾指示」——這個 description 就能在路由競爭中勝出，因為它告訴 Claude 何時優先使用這個工具。

Description 調校檢查清單

生產等級的 MCP tool description 應包含：

• 一句目的說明，點名具體領域（「公司的 Kubernetes 叢集」，而非「一個叢集」）。
• 與內建工具的明確邊界（「請使用此工具，而非直接執行 kubectl」），讓 Claude 知道何時應覆蓋預設選擇。
• 輸入格式範例，至少包含一個具體例子。
• 邊緣案例與失敗模式（「主動 rollout 期間回傳 503；60 秒後重試」）。
• 輸出格式，讓 Claude 能正確串接後續工具。

考試信號

當 CCA-F 情境描述「Claude 一直透過 Bash 執行原始的 kubectl 指令，而不使用我們自訂的 deploy_service MCP tool」時，解法是重新撰寫 MCP tool 的 description，明確告訴 Claude 在部署任務中優先使用它而非 Bash。提議「限制 Bash 工具」或「將 Bash 從允許清單中移除」的答案是錯的——這些做法會引入脆弱性。輕量且持久的解法是更好的 tool descriptions。

遠端 MCP Servers 與 Messages API 的 MCP Connector

雖然 CCA-F 聚焦於 Claude Code，架構師也應認識透過 Messages API 連接的遠端 MCP servers 的相鄰面向。MCP connector 是一個公開 beta 功能，讓 Messages API 請求可以指定一個 MCP server URL；Anthropic 的基礎設施代表用戶端連接到該 server，並在進行中的對話中暴露其工具。

遠端 MCP 的架構意義

遠端 MCP 意味著為 Claude Code 開發的 MCP server，只需少量額外工作，就能被伺服器端的 Messages API 應用程式重複使用。該 server 成為組織級的能力，而非 per-client 的整合。CCA-F 可能在跨域情境中出現這個主題：「團隊已有一個供 Claude Code 使用的 Jira MCP server；他們能從建立在 Messages API 上的客服應用程式重複使用它嗎？」——可以，透過 MCP connector。

CCA-F Foundations 的範圍外項目

CCA-F 考試不測試 MCP server 的部署與託管（Kubernetes 拓撲、負載平衡、TLS 終止）。這些事項屬於基礎設施工程，而非架構基礎。請專注於協定、作用域與設定面向——那裡才是考試分數所在。

常見考試陷阱：作用域、憑證與原語混淆

CCA-F 考試集中了五個反覆出現的 MCP server 整合陷阱。

陷阱一：混淆 Project 作用域與 User 作用域

答案選項會調換檔案位置。.mcp.json 是 project 作用域，提交到儲存庫；~/.claude.json 是 user 作用域，位於 home 目錄，永遠不提交。任何反轉這點的選項都是錯的。

陷阱二：.mcp.json 中的字面憑證

任何將機密以字面字串寫入 .mcp.json 的片段都是錯的，即使周圍文字聲稱該機密是低權限或暫時性的。正確的模式永遠是 ${VAR_NAME} 環境變數展開。

陷阱三：將 MCP Resources 視為 Tools

關於瀏覽問題或文件目錄的情境，解法是 resources，而非 tools。回答「新增一個 list_issues tool」的考生，錯過了 MCP resources 以更低 token 成本原生解決這個問題的事實。

陷阱四：社群 Server 已存在時仍「自建 MCP Server」

對標準整合（Jira、GitHub、Slack、Postgres）採用自建實作，永遠是錯誤的預設。自建保留給沒有社群對應物的團隊專屬工作流程。

陷阱五：限制內建工具而非改善 Descriptions

當 Claude 優先選擇內建工具而非自訂 MCP tool 時，解法是重新撰寫 MCP tool description 以贏得路由競爭——而非將內建工具從允許清單中移除。移除內建工具會引入脆弱性；更好的 descriptions 才是持久的解法。

範疇說明：CCA-F 辨識深度 vs 進階 MCP 實作深度

CCA-F 定位為針對具備 6 個月以上 Claude 實作經驗的架構師的基礎Anthropic 認證。它測試的是 MCP server 整合面向的辨識層級能力——你能否識別正確的作用域、正確的原語、正確的憑證模式，以及正確的自建 vs 採用選擇？

更深入的 MCP 實作主題——從頭撰寫生產等級的 MCP server、設計自訂驗證流程、優化 stdio transport 效能、在高負載下部署遠端 MCP servers——屬於進階實作，而非 CCA-F 的範疇。

CCA-F 對你的期待

• 區分 .mcp.json（project）與 ~/.claude.json（user）作用域。
• 套用環境變數展開讓憑證遠離版本控制。
• 認識 MCP tools 在 session 啟動時被發現，並可同時使用。
• 透過「執行 vs 讀取」的信號區分 MCP tools 與 MCP resources。
• 標準整合預設使用社群 MCP servers；團隊專屬工作流程才保留自建。
• 改善 MCP tool descriptions 以贏得對內建工具的路由競爭。

CCA-F 不期待你做的事

• 以 TypeScript 或 Python 撰寫完整的 MCP server 實作。
• 為遠端 MCP server 設定 Kubernetes ingress。
• 開發 stdio 與 HTTP 之外的自訂 MCP transport。
• 從頭推導 JSON-RPC wire-format 規格。
• 從第一原則設計 MCP server 驗證方案。

若你發現自己在研究 MCP server 部署拓撲或驗證流程圖，你已偏離 CCA-F 的範疇——請重新導向到架構判斷深度，然後繼續前進。

練習錨點：任務 2.4 情境題型

CCA-F 練習題中與 MCP server 整合相關的，集中在五種題型。帶有完整說明的詳細題目位於 ExamHub 題庫中。

題型 A：作用域配置

一個團隊決定標準化採用共享的 Jira MCP server，讓每位工程師的 Claude Code session 都能建立和更新工單。MCP server 應在哪裡設定？正確答案：project 作用域，提交到儲存庫根目錄的 .mcp.json。干擾選項聲稱 user 作用域（違背「每位工程師」的信號）或全域安裝（不是 Claude Code 作用域的運作方式）。

題型 B：憑證安全

一位開發者提議直接將 GitHub 個人存取權杖提交到 .mcp.json「以簡化新工程師的上線流程」。哪種做法是正確的？正確答案：在 .mcp.json 中使用 ${GITHUB_TOKEN} 環境變數展開，並在團隊的上線指南中記錄這個變數。干擾選項包含「提交 token，因為它是低權限的」（永遠不可接受）和「將 token 存放在儲存庫的 secrets 檔案中」（換個名字，同樣的洩漏）。

題型 C：原語選擇

一個團隊的 Claude Code agent 在找到正確的 Jira 工單進行更新之前，反覆以猜測的關鍵字呼叫 search_issues。MCP 應新增什麼能力來減少探索性 tool 呼叫？正確答案：暴露開放問題目錄的 MCP resource（例如 jira://project/PROJ/open-issues），讓 agent 在呼叫 tools 之前先讀取一次。干擾選項提議「新增更多搜尋工具」或「增加搜尋工具的 limit 參數」——兩者都沒有解決架構根本原因。

題型 D：自建 vs 採用

一個團隊想將 Claude Code 與 PostgreSQL 資料庫整合以進行 schema 查詢。一個被廣泛使用的社群 PostgreSQL MCP server 已經存在。哪個是正確的架構選擇？正確答案：採用社群 PostgreSQL MCP server。干擾選項聲稱「自建 server 以獲得更嚴格的控制」——除非情境明確排除社群選項，否則這永遠是錯誤的預設。

題型 E：Tool Description 調校

Claude 一直透過內建 Bash 工具執行原始的 kubectl 指令，而不使用團隊自訂的 deploy_service MCP tool。哪個解法最合適？正確答案：重新撰寫 deploy_service 的 tool description，明確說明其目的、與 Bash 的邊界、輸入格式和輸出格式，讓 Claude 在部署任務中優先使用它。干擾選項提議將 Bash 從允許清單移除（脆弱）或新增 CLAUDE.md 規則（比精心調校的 description 持久性差）。

MCP Server 整合常見問題（FAQ）

CCA-F 考試中 .mcp.json 與 ~/.claude.json 有何差異？

.mcp.json 位於儲存庫根目錄，提交到版本控制；它定義了整個團隊共享的 MCP servers。~/.claude.json 位於使用者的 home 目錄，永遠不提交；它定義了個人開發者私有的 MCP servers。Project 作用域（.mcp.json）適合團隊共享的整合（Jira、GitHub、內部部署工具）。User 作用域（~/.claude.json）適合個人、實驗性或含有敏感憑證、應跟著開發者而非專案走的 server。兩個檔案都在 session 啟動時被讀取，其 server 清單被合併為一個工具目錄。

當 .mcp.json 已提交到儲存庫時，如何讓憑證遠離它？

使用環境變數展開：凡是 MCP server 設定需要憑證的地方，請寫成 ${VAR_NAME} 而非字面字串。Claude Code 在 session 啟動時從 shell 環境解析這個佔位符。開發者透過 direnv、.envrc、1Password CLI 或組織的機密管理工具在本機設定這些變數。CI runner 則透過 pipeline secrets 注入它們。若 session 啟動時變數不存在，Claude Code 會回報 MCP server 啟動錯誤，而不是靜默地展開為空字串。絕不要提交字面 token，即使只是佔位用——一旦機密進入 git 歷史，就必須輪換。

所有 MCP server 工具是否同時對 Claude 可用？還是 Claude 每次只能選一個 server？

所有已連線 MCP servers 的工具在整個 session 期間同時可用。在 session 啟動時，Claude Code 會連接 .mcp.json 宣告的每個 server，加上 ~/.claude.json 中的每個 server，查詢每個 server 的工具和 resource 目錄，並將所有項目合併為一個扁平清單，與內建工具（Read、Write、Edit、Bash、Grep、Glob）放在一起。不存在 per-turn 的 server 選擇機制——Claude 在整個 session 期間都看到完整的目錄。這就是為什麼架構師必須謹慎控制工具數量：連接太多 MCP servers 的 agent，最終會有數百個工具在 context 中，增加 token 成本並降低路由準確度。

MCP tool 與 MCP resource 有何差異？

MCP tool 是有副作用的可呼叫函式——呼叫它會觸發完整的 agentic loop 往返（stop_reason: tool_use → 用戶端執行 → tool_result 區塊 → Claude 繼續）。Tools 是 agent 做事的方式：建立工單、執行查詢、發送訊息。MCP resource 是以 URI 定址的可讀內容單元（jira://issue/PROJ-123、db://schema/orders）——它暴露內容目錄，讓模型可以在不付出完整 tool 呼叫成本的情況下瀏覽。暴露問題目錄為 resource 的 server，能減少探索性 tool 呼叫，因為模型可以直接讀取目錄，再決定呼叫哪個工具。設計良好的 MCP servers 兩種原語都提供。

什麼情況下應自建 MCP server 而非使用社群版本？

正確的架構預設是標準整合使用社群 MCP server（Jira、GitHub、Slack、Linear、PostgreSQL、Notion、Sentry），並將自建保留給沒有社群對應物的團隊專屬工作流程。社群 server 經過實戰驗證、符合規格、針對上游 API 變更持續維護，且易於發現。自建現有社群 server 的替代版本，是在重複數個月有人已在維護的工作，並附帶更差的錯誤處理。當整合自建內部系統、將多個內部系統組合成一個邏輯操作，或滿足社群 server 無法符合的合規需求時，自建才是正確的選擇。

為什麼 Claude Code 有時會忽略我的自訂 MCP tool，轉而使用內建工具？

因為 tool description 是 Claude 在重疊工具之間做選擇的路由機制。Bash 和 Read 等內建工具附帶精心調校的 descriptions，能在路由競爭中勝過 description 較弱的自訂工具。解法幾乎從來不是限制內建工具——那會引入脆弱性。持久的解法是重新撰寫自訂 MCP tool 的 description，說明其具體目的、與內建工具的邊界（「請使用此工具，而非直接執行 kubectl」）、帶有範例的輸入格式，以及輸出格式。具體且說明邊界的 description 能贏得路由競爭，讓 Claude 優先選用它。

CCA-F 考試會測試 MCP server 的部署與託管嗎？

不會。CCA-F Domain 2 任務 2.4 測試的是整合——如何從 Claude Code 設定、限定作用域、管理憑證和使用 MCP servers——而非部署。遠端 MCP servers 的 Kubernetes ingress、TLS 終止、水平擴展和自訂 transport 協定都在範疇之外。考試也不測試 fine-tuning、vision、streaming API 細節或雲端供應商特定的設定。請專注於協定、作用域與設定面向，那才是考試分數所在。

延伸閱讀

• Claude Code MCP 整合文件：https://docs.anthropic.com/en/docs/claude-code/mcp
• Model Context Protocol 介紹：https://modelcontextprotocol.io/introduction
• MCP 建立 Server 指南：https://modelcontextprotocol.io/docs/develop/build-server
• Messages API 的 MCP Connector：https://docs.anthropic.com/en/docs/agents-and-tools/mcp-connector
• Anthropic Engineering — 為 Agents 撰寫 Tools：https://www.anthropic.com/engineering/writing-tools-for-agents
• Claude Code Tool 參考（內建工具）：https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/tool-reference
• CCA-F 考試指南：https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf

Related ExamHub topics: Tool Design and MCP Integration Overview, Structured Error Responses for MCP Tools, Claude Code Built-in Tools, CLAUDE.md Configuration Hierarchy, Tool Descriptions as Routing Mechanisms.