嗨，我是 Lena。今個星期我本來冇打算寫 MCP。我只係想幫自己一直跑緊嘅一個 Hermes Agent 實例接上第二個工具 server。結果改 config、睇住工具列表刷新到一半嘅時候，我停咗低。
呢個 agent 而家可以存取四個十分鐘前仲未有嘅 servers。我其實冇真正諗清楚，每一個 server 到底被允許讀啲咩。於是我返去睇 docs，再返去睇 config。呢次開場我就先停喺呢度——因為呢個小小嘅停頓，基本上就係成篇文章想講嘅事。
呢篇唔係 MCP 入門。如果你睇到呢度，大概已經知道呢個 protocol 係咩。我想寫低嘅係，呢段時間我學到嘅：點樣喺將 MCP 用喺 Hermes Agent 入面時，唔好靜靜雞將比原本打算更多嘅權限交咗畀 agent。
MCP 實際為 Hermes Agent 加咗咩
唔寫 Hermes 原生工具，都可以接入外部工具
Hermes 內置咗一組固定能力。MCP 就係你唔需要重新寫一個原生工具，都可以擴展呢組能力嘅方法。 你將 Hermes 指向一個 server——本地又好，遠程又好——嗰個 server 嘅工具列表就會同內置工具一齊出現。喺 agent 角度睇，幾乎冇咩分別。
但呢個「幾乎」好重要。內置工具活喺 Hermes 自己嘅權限模型入面。MCP tools 就隔住一層 protocol boundary。佢哋喺你部機或者你個 network 入面實際做咩，完全取決於你信任咗邊個 server。
點解 MCP 係 adapter layer，而唔係魔法功能
我成日提醒自己呢一點。MCP 唔會令一個工具自動變得更安全，亦唔會令佢更聰明。佢標準化嘅係：一個工具點樣被描述畀 agent，以及 calls 同 responses 點樣透過 JSON-RPC 2.0 來回傳。就係咁。
所以當 Hermes 入面某個 MCP tool 出事時，bug 幾乎從來唔係喺 MCP 本身。問題通常係你連咗嘅 server、佢用緊嘅 credentials，或者嗰個「agent 會自己判斷應該 call 咩」嘅假設。我係要學兩次先真係記得呢件事。
幾時應該用 MCP，幾時唔應該用
適合、不適合，以及過度暴露嘅工具面
喺 Hermes setup 入面，MCP 真正值得出現嘅場景通常係呢啲：
- 圍繞外部系統嘅讀取型工作——拉 issues、查 logs、攞 docs、瀏覽 agent 原生夠唔到嘅 files。
- 你本身已經信任嘅 internal APIs，再用一個你自己控制嘅細 MCP server 包住。
- 一次性 integrations，即係寫 Hermes 原生工具有啲 overkill 嗰種。
而下面呢啲場景，我會諗多一次：
- 任何會破壞 production systems 嘅操作。 Deletes、force-pushes、schema changes——只要 tool description 聽落夠自信，agent 真係會開心咁 call 佢。
- 一次暴露幾十個 tools 嘅 servers。 Anthropic 工程團隊提過，大多數 MCP clients 會將所有 tool definitions 預先載入模型 context，意思係連接嘅 servers 越多，tokens 越多，surface area 越大，亦越多地方可以畀 tool description 靜靜咁塑造行為。研究人員亦另外記錄過，tool descriptions 本身會被餵入 LLM，而且可以帶住隱藏指令——呢個就係而家廣泛叫做 tool poisoning 嘅問題。窗口越大，風越容易入嚟。
- 隨便搵返嚟嘅 community servers，尤其係一開口就要大範圍 credentials 嗰啲。MongoDB 團隊喺 docs 入面講得好直接：Streamable HTTP servers 預設應該綁喺 localhost (127.0.0.1)，因為綁到 0.0.0.0 會將佢哋暴露畀成個 local network。好多「即裝即用」tutorials 會跳過呢段。
如果一個 workflow 好少用、好敏感，或者生命週期好短，MCP 大概唔係最啱佢嘅形狀。 寫成 script，然後明確咁 call 佢，會清楚好多。
喺 Hermes 入面安全配置 MCP
stdio 同 remote servers
兩種 transports。佢哋唔可以互相代替。
Stdio 會將 MCP server 作為你部機上嘅 child process 跑起。Hermes 透過 stdin/stdout 同佢溝通。佢簡單、低延遲，適合本地 filesystem 或 developer tooling 呢類場景。代價係：你喺自己部機上執行緊一個 binary，而且 OAuth/token 嗰套機制喺呢度基本上用唔上。
Remote (Streamable HTTP) 就係 server 跑喺其他地方，透過 HTTP 溝通。呢度 authorization 先真正有牙力。根據官方 MCP specification，MCP servers 喺呢個模式下而家被分類為 OAuth Resource Servers，即係 tokens 有明確嘅 scope 同 audience，而唔再只係一條泛用 API key。我覺得自己開始明白，點解 2025 年 11 月嘅 spec 會咁用力強調呢點——單一靜態 API key 其實一直喺靜靜咁製造每個問題最差嘅版本。
我成日返去用嘅粗略規則係：真正需要本地嘅嘢用 stdio，任何會同真實 network service 溝通嘅嘢用 remote。 喺同一個 Hermes config 入面混用兩者冇問題，但我會標籤得清清楚楚，免得自己唔記得邊個係邊種。
按 server 過濾、隔離 env、以及 /reload-mcp workflow
有三個習慣，真係幫我慳過時間：
- 按 server 過濾工具面。 如果一個 server 暴露 20 個 tools，而 agent 只需要 3 個，就唔好 load 另外 17 個。Hermes 俾你按 server allowlist tool names。呢個唔係疑神疑鬼——佢會直接縮細我前面講過嘅 prompt-injection surface。
- 隔離 environment variables。 唔好將你完整嘅 shell environment 一次過丟畀每一個你 spawn 嘅 MCP server。只傳嗰個 server 真正需要嘅 variables，並且透過 expansion 引用 secrets（例如
"GITHUB_TOKEN": "$GITHUB_TOKEN"），而唔係 hardcode 入去。其他 agent runtimes 會喺 spawn MCP processes 之前，自動 redact 符合 TOKEN、SECRET、PASSWORD 呢類 patterns 嘅 variables——Hermes 預設唔會幫你做呢件事，所以你要寫得明確。 - 有意識咁用
/reload-mcp，唔好反射式咁用。 當你改咗 server config，就 reload 佢——但繼續工作之前，先檢查新嘅 tool list。reload 係你最自然重新讀一次「agent 而家可以存取咩」嘅時刻。我可能諗得太多，但 跳過呢個檢查，就係 silent privilege creep 發生嘅方式。
日常真正可行嘅 MCP 模式
GitHub、databases、internal APIs、browser stacks
幾個我見過撐得住嘅模式：
GitHub 式 read access。 Scoped fine-grained tokens。agent 可以讀 issues、PRs 同 code，但唔可以 push 或 merge。寫入動作交返畀人。
Databases。 只連 read replicas。就算係咁，我都會將 query timeouts 設短，將 result-row caps 壓低——agents 意外寫出好重嘅 queries 係真實 failure mode，唔係理論風險。
Internal APIs。 用一個細嘅 in-house MCP server 包住。唔好重用 master service-account token——專門為 agent 發一個範圍更窄嘅 token。研究大規模 MCP 實踐嘅人提到過，現實中相當一部分 MCP servers 依賴 API keys 或 PATs 呢類 long-lived static secrets，而呢種模式正正係最容易 leak 嗰種。嗰個數字一直留喺我腦入面。
Browser stacks。 呢類 integration 嘅 blast radius 最大。一個 browser MCP server 可以 navigate、click、submit forms。我會預設關掉，只有真正需要時先開，用完再關。
貫穿所有呢啲嘅線索係：least privilege 應該按 server 切，而唔係按 agent 切。 每一個 MCP server 都係一次獨立嘅信任決策。
Hermes 入面常見嘅 MCP 錯誤
唔安全嘅預設值、巨大嘅工具面、過期嘅 config assumptions
有啲事我自己做錯過，亦見過其他人做錯：
- 相信「default config」等於「safe config」。 通常佢只係代表「最容易 demo」。任何由 blog post copy-paste 返嚟嘅 config，都值得 audit 一次，包括呢篇——defaults 係為最簡單路徑寫嘅，唔係為最安全路徑寫嘅。
- 先 connect，之後先 scope。 老實講，之後先 scope 通常就等於永遠唔 scope。加 server 嗰一刻就設好 scopes。
- 以為 tool description 就係 tool 實際會做嘅事。 Tool descriptions 係prompts。佢哋活喺 agent 嘅 context 入面，並且塑造行為。一個 poisoned 或者寫得好鬆散嘅 description，可以將 outcome 推去用戶永遠睇唔到嘅方向。
- 忘記 config drift 係真實存在。 上個月安全嘅 server，今個月可能已經更新咗 tool list。Reload, re-read, re-decide.
最後呢點，我仲未完全肯定點樣自動化。可能值得之後再返嚟寫。
FAQ
如果 Hermes 已經有可用嘅 tools，我仲需要 MCP 嗎？
唔需要。只有真係有 gap 先加 MCP。新 servers 會增加 surface area，無論你用唔用佢哋。
Stdio 定 remote——邊個「更安全」？
呢個問題問錯咗。Stdio 喺本地跑一個 binary；remote 跨過 network。佢哋面對嘅 threats 唔同。應該按 data 同 credentials 實際住喺邊度嚟揀。
我可唔可以直接信任一個官方 MCP server？
「官方」只代表 vendor 寫咗佢。唔代表你畀佢嘅 configuration 係安全嘅。scope 同 tokens 仍然係你嘅責任。
我應該幾耐 review 一次 MCP configs？
每次 add、remove 或 update server 嘅時候都要睇一次——就算冇改動，我都會每個月快速掃一遍。
我大概會繼續睇住佢點樣演進。protocol 仲喺度變，spec 仲喺度收緊，而而家睇落好 obvious 嘅 patterns，六個月後可能會顯得好天真。至少而家，對我最有用嘅唔係某段 config snippet——而係當 tool list 變長時，先停一停嗰個小習慣。呢次我就寫到呢度。
