最近在做一個題庫測驗網站，需要大量的題目來填充內容。但如果每次都要自己手動輸入題目，或是花錢去調用 OpenAI API key 來產題，那成本可不是開玩笑的。我剛好有訂閱 Antigravity，裡面內建了 AI 額度，想說能不能好好利用這個資源？
於是我想到了一個點子：開發一個 MCP Server，讓 AI 可以直接自動化匯入題目。這樣不僅省了 API Key 的支出，還能省下開發後台匯入頁面的時間。聽起來很完美對吧？
使用AI產生題目 json檔案，然後使用 mcp匯入系統。起點與動機
整個專案的出發點其實很簡單：
- 題庫網站需要大量題目 - 這是最基本的需求
- 想節省成本 - 不想一直花錢調用 API
- 善用現有資源 - 既然訂閱了 Antigravity，裡面有AI額度，何不拿來用？
- 省時省力 - 透過 MCP Server，讓 AI 直接有「自動化匯入題目」的能力，不用另外開發後台界面
簡單來說，MCP (Model Context Protocol) 就是讓 AI 助手能夠連接外部工具的一種標準協議。透過開發 MCP Server，我可以賦予 AI 直接操作資料庫、匯入題目的能力。聽起來很酷，對吧？
當理想遇上現實：「假性正常」才是最難解的 Bug
理論上這個方案應該要順利運作。我很快就把 MCP Server 寫好了，在 Cursor 這個 IDE 上測試，一切都超級順利。連線正常、功能正常、匯入題目也沒問題。
興高采烈地把同樣的設定套用到 Antigravity 上，結果...
設定頁面顯示「綠燈」 ✅ - 看起來連線成功！ 實際調用時 ❌ - 不斷噴出 EOF (End of File) 錯誤
正常連線MCP-Server
這種「假性正常」才是最讓人崩潰的！明明連線狀態顯示正常，但實際上根本不能用。我甚至把功能簡化到只剩下讀取（Hello World 級別），在 Antigravity 依然無法成功通訊。
就像你以為門開了，結果走過去發現只是一面畫了門的牆。
深入排查
既然問題這麼詭異，我開始認真排查：
檢查日誌和設定
- 詳細檢查了 Server 的 Log
- 比對 Antigravity 和 Cursor 的 config 設定
- 確認了 MCP Server 的握手流程
測試簡化功能
- 把所有複雜邏輯都拿掉
- 只保留最基本的讀取功能
- 結果依然失敗
比對不同 IDE 的調用邏輯
我開始懷疑：會不會是 Antigravity 和 Cursor 對 MCP 的調用方式不一樣？經過一番深入研究後，我發現了關鍵：
Antigravity 和 Cursor 的運行環境（Runtime/Sandbox）並不一致
更具體來說：
- Antigravity 對於網路存取的限制更嚴格
- 標準流（Stdio）的處理方式不同
- 這導致 MCP Server 的握手過程失敗
簡單來說，就像你在兩個不同的國家開店，雖然賣的是同樣的東西，但因為當地的法律規範不同（環境限制），原本能順利營業的模式到了另一個地方就行不通了。
終極解法：Bridge 模式來救場
既然 Antigravity 的環境限制這麼嚴格，那我何不繞過它？
Bridge 模式：Stdio 橋接 HTTP
我的解決方案其實很巧妙：利用 Antigravity 允許的 stdio（標準輸入輸出）通訊方式，搭配一個輕量的 Bridge 腳本來轉接。
實際的工作流程
- Antigravity 透過 stdio 與 Bridge 通訊
- MCP 設定檔指定執行
mcp-bridge.ts（使用 Node.js） - Antigravity 把 JSON-RPC 訊息寫到 Bridge 的 stdin
- Bridge 從 stdout 回傳結果給 Antigravity
- MCP 設定檔指定執行
- Bridge 扮演轉接角色
- 接收 stdin 的訊息後，透過 HTTP POST 轉發到本地伺服器（
localhost:3000） - 透過 SSE (Server-Sent Events) 接收伺服器的即時回應
- 將回應寫回 stdout 給 Antigravity
- 接收 stdin 的訊息後，透過 HTTP POST 轉發到本地伺服器（
- 本地伺服器處理實際業務邏輯
- NestJS 後端在正常環境運行，不受 IDE 限制
- 可以自由存取資料庫、網路等資源
MCP 設定範例
"mcpServers": {
"praxis-question-bank": {
"command": "/Users/xxx/.nvm/versions/node/v22.22.0/bin/node",
"args": ["/path/to/mcp-bridge.ts"],
"env": {
"MCP_API_KEY": "your_api_key",
"PORT": "3000"
}
}
}
可以把整個架構想像成這樣：
Antigravity AI (受限環境)
↓ stdin/stdout (JSON-RPC)
mcp-bridge.ts (輕量轉接腳本)
↓ HTTP POST (轉發請求)
↓ SSE (接收回應)
localhost:3000 NestJS Server (正常環境)
↓
資料庫 / MCP 實際功能
為什麼這樣可行？
- Stdio 是 Antigravity 允許的通訊方式 - 不會觸發環境限制
- Bridge 只做簡單的輸入輸出轉換 - 不需要複雜的網路操作或握手流程
- 實際的 MCP Server 跑在本地正常環境 - 不受 IDE 沙盒限制，可以自由存取所有資源
- SSE 提供即時雙向通訊 - 確保 AI 與後端能順暢互動
Bridge 的關鍵優勢
這個方案最聰明的地方在於：它不是試圖在受限環境內做更多事，而是把「做事」的部分移到外面，只在受限環境內做最簡單的轉發。
就像你不能直接從辦公室連到外網，但可以透過一個簡單的 proxy 腳本來轉發請求一樣。
最終成果
透過這個 Bridge 模式，我成功做到了：
✅ 在 Antigravity 內使用 AI 額度自動產題 ✅ 不用額外開發後台匯入頁面 ✅ 完全避開環境限制的問題 ✅ 節省了 API Key 的成本
總結與建議
這次的經驗讓我學到了幾個重要的經驗：
關鍵經驗
- 「連線正常」不等於「功能正常」 - 綠燈只是表象，實際測試才是王道
- 不同 IDE 的運行環境差異可能很大 - 不要假設所有工具的行為都一樣
- 遇到環境限制，換個角度思考 - Bridge 模式就是一個很好的例子
- 簡化問題來定位根因 - 從 Hello World 開始測試，逐步排除問題
如果你也遇到類似問題
如果你也在開發 MCP Server，或是遇到「此處可行，彼處不行」的詭異問題：
- 先確認環境差異 - 不同工具的沙盒限制可能不同
- 檢查網路和標準流的權限 - 這通常是最容易被限制的部分
- 考慮使用 Bridge 模式 - 輕量轉發比直接突破限制更實際
- 詳細記錄 Log - 錯誤訊息往往藏著關鍵線索
開始行動：如果你也想要節省 API 成本，又剛好有訂閱支援 MCP 的 IDE，不妨試試這個方法。雖然過程中可能會踩到一些坑，但解決後的成就感絕對值得！
有任何問題或建議，歡迎留言討論！ 🚀
