500行代碼搭遠程MCP服務器，3種認證方式讓我栽了2次

一個人維護四套AI客戶端的記憶同步，Daniel Schwartzer用MCP（Model Context Protocol，模型上下文協議）做到了。他的"Open Brain"系統存著WhatsApp聊天記錄、播客轉錄、隨想筆記，Claude、ChatGPT、Cursor、Claude Code都能調用同一套工具查詢。

本地跑通只是開始。今年3月，他把服務器搬到Supabase Edge Function上，才發現MCP的遠程部署和本地體驗完全是兩碼事。

60行手寫代碼 vs 三個認證方案

整個協議實現不到60行TypeScript，一個switch語句處理JSON-RPC 2.0：GET返回SSE流做服務發現，POST分發到initialize、tools/list、tools/call、ping。沒有官方SDK，純手寫。

這種"薄協議"是MCP的設計哲學——規格文檔夠短，一下午能從頭實現。但薄也意味著大量決策丟給開發者，認證就是第一個坑。

Daniel的解決方案堪稱妥協藝術：URL參數（?key=secret）、自定義請求頭（x-brain-key）、標準Bearer token，三種方式并存。

「每個MCP客戶端傳憑證的方式都不一樣，我不想每次接新客戶端都調試認證失敗。」他在博客里寫道。Claude Desktop走stdio本地管道，Cursor支持部分HTTP配置，ChatGPT的插件機制又有自己的規矩——沒有統一標準，只能窮舉兼容。

SSE流：協議規定的麻煩

MCP遠程傳輸基于SSE（Server-Sent Events，服務器推送事件），這個選擇本身就有爭議。GET請求建立長連接流，后續POST請求通過同一個會話ID關聯——理論上優雅，實際部署中Daniel遇到兩個具體問題。

一是邊緣函數的冷啟動延遲。Supabase Edge Function按請求計費，SSE長連接保持期間算活躍狀態，成本模型和短請求完全不同。二是某些云環境的代理層會緩沖SSE響應，導致客戶端收不到實時推送，調試時一度以為是代碼bug。

他最終用純HTTP輪詢替代了部分場景，但這就偏離了協議標準，可能和某些客戶端不兼容。

工具發現：200ms的隱形稅

MCP要求客戶端連接時先調用tools/list獲取可用工具列表。Daniel的Open Brain有12個工具，序列化后JSON約15KB。每次新會話都要走一遍這個流程，加上邊緣函數的冷啟動，首響應用時經常超過2秒。

他試過緩存工具列表，但MCP協議規定initialize消息必須包含完整的協議版本和能力協商，跳不過。對于個人項目能忍，如果是生產環境面向C端用戶，這200-500ms的"握手稅"會直接影響留存。

更隱蔽的問題是工具命名沖突。不同MCP服務器的工具暴露在同一個命名空間，Daniel給工具加了"brain_"前綴才避免和Cursor內置工具撞車。協議層面沒有命名空間隔離機制，全靠開發者自覺。

錯誤處理：JSON-RPC的幽靈

MCP基于JSON-RPC 2.0，這個誕生于2010年的規范對現代開發者有些陌生。Daniel花了相當篇幅處理錯誤碼映射：MCP定義了-32600到-32603的標準錯誤，但工具執行失敗返回什么？他最終約定-32000到-32099為業務錯誤，-32603為內部服務器錯誤。

「Claude Desktop遇到-32603會直接斷開連接，ChatGPT則會重試3次。同樣的錯誤碼，行為完全不同。」這種差異沒有文檔說明，只能靠實測摸索。

日志是另一個痛點。stdio模式下子進程的stderr直接打到終端，遠程HTTP模式下需要額外設計日志采集。Daniel最后把結構化日志寫進Supabase的日志表，調試時才能追蹤完整請求鏈路。

個人系統 vs 生產-ready

Daniel反復強調這是"單用戶個人系統"。三種認證方案并存、SSE緩沖問題用輪詢繞過、工具前綴手動規避沖突——這些在toC場景都是技術債。

但MCP的價值恰恰在這里：它讓個人開發者能用500行代碼搭起跨客戶端的AI基礎設施，而不必等官方集成。Claude、ChatGPT、Cursor的封閉生態被撬開一道縫，數據終于能流動起來。

3月的MCP討論熱度暴漲，Anthropic剛發布了遠程MCP的改進草案。Daniel的實驗發生在標準定稿前夜，他的踩坑記錄因此有了標本價值——協議越薄，實現越重，這是所有"簡單設計"的宿命。

他在文末留了一個待辦：把認證方案收斂到OAuth 2.1，支持動態客戶端注冊。但什么時候動手？「等下一個客戶端接不通的時候吧。」