VS Code 裡的 MCP server 是什麼#

在 VS Code 的 AI 功能裡，MCP servers 會提供工具、resources、prompts，甚至互動式 apps。常見例子像 Playwright MCP、GitHub MCP、資料庫工具或公司內部 API 工具。

對開發者來說，它的價值不是「多一個聊天功能」，而是讓 agent 能夠基於真實工作區做事。例如：

• 用瀏覽器工具重現前端問題。
• 讀取專案內特定 resources。
• 呼叫內部 API 查狀態。
• 透過 prompt template 固定團隊工作流。

但只要工具能動到本機或外部服務，就要把權限當成開發環境的一部分，而不是把它當成單純的 AI 小工具。

第一個選擇：User profile 還是 workspace#

VS Code 官方文件說 MCP 設定存在 mcp.json，位置可以是兩種：

如果 MCP server 是純個人工具，例如你自己的 local memory 或瀏覽器測試工具，我會放 user profile。
如果是專案需要的工具，例如某個 dev container 內固定要用的測試 server，才考慮放 .vscode/mcp.json。

關鍵是：**workspace 設定應該像 CI 設定一樣被 review。**不要因為它只是 JSON，就把 unknown command、API endpoint、credential 寫進 repo。

最小 mcp.json 長什麼樣子#

VS Code 的 MCP configuration reference 說，設定檔主要有三個區塊：

• servers: server 名稱與啟動設定。
• inputs: API key 這類敏感輸入。
• sandbox: sandboxed server 的檔案系統與網路規則。

本機 stdio server 的最小概念大概像這樣：

1
{
2
  "servers": {
3
    "memory": {
4
      "command": "npx",
5
      "args": ["-y", "@modelcontextprotocol/server-memory"]
6
    }
7
  }
8
}

實務上我不會直接把這段丟進 repo 就收工。至少要再問：

• npx -y 會下載哪個 package？
• package 來源是否可信？
• 是否需要固定版本？
• 是否需要 network access？
• 是否會讀寫 workspace 外的資料？

MCP 設定不是只看能不能啟動，而是要看啟動後它能碰到什麼。

Trust prompt 不是形式#

VS Code 文件說，當你新增 workspace MCP server 或修改設定後，啟動前需要確認信任 server 與它的能力。第一次啟動時會出現 trust dialog；如果不信任，server 不會啟動，chat 也不會使用它提供的工具。

這個 prompt 值得點進去看設定，不要直接按掉。尤其是這幾種情況：

1. command 是 npx、uvx、docker 或 shell script。
2. args 裡有遠端 URL。
3. env 或 envFile 會帶入金鑰。
4. 設定檔來自別人的 PR。
5. 你不清楚 server 會提供哪些 tools。

官方文件也提醒，如果你直接從 mcp.json 啟動 MCP server，就不會看到 trust prompt。這代表 review 設定檔本身更重要。

API key 不要硬寫進設定檔#

VS Code 的 MCP 文件明確提醒，不要 hardcode API keys，要使用 input variables 或 env files。這點跟一般後端設定一樣，但 MCP 更容易被忽略，因為它常常長得像「本機開發工具設定」。

我會用這個原則：

1
{
2
  "servers": {
3
    "internal-api": {
4
      "type": "stdio",
5
      "command": "node",
6
      "args": ["./scripts/mcp/internal-api.js"],
7
      "env": {
8
        "INTERNAL_API_TOKEN": "${input:internal-api-token}"
9
      }
10
    }
11
  },
12
  "inputs": [
13
    {
14
      "id": "internal-api-token",
15
      "type": "promptString",
16
      "description": "Internal API token",
17
      "password": true
18
    }
19
  ]
20
}

這段只是示意，不代表你要照抄。重點是把 credential 從 repo 裡移出來，並讓輸入流程有機會使用安全儲存或互動式輸入。

macOS / Linux 可以考慮 sandbox#

VS Code 文件提到，macOS 和 Linux 上可以對本機 stdio MCP servers 開啟 sandbox，限制它能存取的檔案路徑與網路 domain。設定上可以用 "sandboxEnabled": true，再用 top-level sandbox 描述允許範圍。

這很適合用在「工具本身有用，但你不想讓它碰整台機器」的情境。例如只允許寫 workspace、只允許連到某個 API domain。

但要注意兩件事：

• sandbox 不是 Windows 可用功能。
• sandboxed server 的 tool calls 可能因為受控環境而被 auto-approved，設定範圍要更保守。

我的原則是先從最小權限開始。需要寫檔就只開 workspace；需要打 API 就只開必要 domain。能不用全域 filesystem access，就不要開。

接進團隊 repo 前的 review checklist#

如果有人送 PR 新增 .vscode/mcp.json，我會至少看這幾點：

VS Code 有 MCP: List Servers、MCP: Open User Configuration、MCP: Open Workspace Folder Configuration、MCP: Reset Trust 這類命令可以輔助管理。設定完後，不要只問 agent 「能不能用」，也要確認 VS Code 裡看到的 server 狀態與 output log。

實際結論#

VS Code 支援 MCP servers 之後，AI coding workflow 會更容易接到真實工具。但越接近真實工具，越不能只靠「看起來能跑」判斷是否安全。

我的建議是：

1. 個人工具放 user profile，團隊工具才放 workspace。
2. .vscode/mcp.json 要像程式碼一樣 review。
3. Trust prompt 要點開看設定，不要只按同意。
4. API key 用 inputs 或 env file，不要硬寫。
5. macOS / Linux 上能 sandbox 就先縮權限。

MCP 的價值在於讓 agent 做更具體的事。也正因為它能做事，權限邊界要在接入前就設好。

常見問題#