/tags/mcp/林協霆醫師 (MCP)Hugo -- gohugo.iozh-twhttps://htl.physician.tw/favicon-32x32.pnghttps://htl.physician.tw/3232https://htl.physician.tw/favicon-32x32.pnghttps://htl.physician.tw/android-chrome-512x512.png5bbad5Sat, 09 May 2026 00:00:00 +0000/blog/openevidence-mcp-2026-05-09/Sat, 09 May 2026 00:00:00 +0000/blog/openevidence-mcp-2026-05-09/<h2 id="introduction引言" > <div> <a href="#introduction%e5%bc%95%e8%a8%80"> # </a> Introduction（引言） </div> </h2> <p>OpenEvidence 為近年備受關注的醫學文獻 AI 問答平台，能在臨床問題上整合即時文獻並提供出處連結。然而 OpenEvidence 並未開放官方 MCP 介面，使其結果難以直接接入現代 AI Coding 助手如 Claude Code、Codex 與 Gemini CLI 的對話流。對於日常需要在醫學書寫與研究中即時查證文獻的醫師而言，這形成顯著的工作流斷層：使用者必須在瀏覽器與 IDE 之間切換，並手動處理引用格式。</p> <p>本專案提出一個非官方但可重現的 MCP 伺服器實作，將 OpenEvidence 的問答能力以工具呼叫的方式暴露給 LLM 客戶端，並在輸出端整合 BibTeX 匯出與 Crossref 驗證，使每一筆引用都能被自動追溯與重新核實。</p> <h2 id="methods方法" > <div> <a href="#methods%e6%96%b9%e6%b3%95"> # </a> Methods（方法） </div> </h2> <p>伺服器以 Python 標準函式庫為主撰寫，避免複雜外部相依以簡化部署。驗證採用 <code>cookies.json</code> 機制：使用者於瀏覽器登入 OpenEvidence 後匯出 Cookie，伺服器讀取後以同一 session 呼叫後端 API。MCP 工具介面提供至少一個查詢函式，回傳 OpenEvidence 的答案與引用列表；引用會進一步被傳入 Crossref API 比對 DOI 與標題的一致性，標記出可能的幻覺或錯誤匹配。</p> <p>伺服器另外附帶針對 Claude、Codex、Gemini 的安裝協助腳本，自動將設定寫入各客戶端的 <code>mcp.json</code> 或對應設定檔，降低非工程背景使用者的配置門檻。輸出可選 BibTeX 格式，方便直接導入 Zotero 或學術寫作管線。</p> <h2 id="results結果" > <div> <a href="#results%e7%b5%90%e6%9e%9c"> # </a> Results（結果） </div> </h2> <p>藉由將 OpenEvidence 包裝為 MCP 工具，使用者可在 LLM 對話中直接以自然語言查詢臨床文獻，並在同一回應中取得可被 Crossref 驗證的 BibTeX 條目。此設計縮短了從「問題」到「可重現引用」的距離，並能搭配多客戶端使用，避免工作流被綁定於單一供應商。引文驗證模組進一步降低 LLM 幻覺帶來的風險。</p> <h2 id="discussion討論" > <div> <a href="#discussion%e8%a8%8e%e8%ab%96"> # </a> Discussion（討論） </div> </h2> <p>本專案展示了 MCP 作為「私域整合層」的價值：當官方未提供標準介面時，使用者仍能以最小成本將自己日常使用的工具納入 AI 對話流。限制方面，由於採用 Cookie 驗證，使用者需自行管理失效與更新；同時非官方 API 可能在後端變動時失靈。未來方向包括：以 Crossref 結合 PubMed 雙重驗證、加入引用評分機制，並探討於本地 LLM 上重現相同管線的可行性。</p> <h2 id="連結" > <div> <a href="#%e9%80%a3%e7%b5%90"> # </a> 連結 </div> </h2> <ul> <li>GitHub：<a href="https://github.com/htlin222/openevidence-mcp">htlin222/openevidence-mcp</a></li> <li>主要語言：Python</li> <li>最後更新：2026-05-09</li> </ul>/blog/openevidence-skill-2026-05-07/Thu, 07 May 2026 00:00:00 +0000/blog/openevidence-skill-2026-05-07/<h2 id="introduction引言" > <div> <a href="#introduction%e5%bc%95%e8%a8%80"> # </a> Introduction（引言） </div> </h2> <p>Claude 推出 Skills 機制後，使用者可將特定任務以「漸進式載入」的形式封裝為可重用模組，避免將所有工具一次性塞入 system prompt 而造成 context 浪費。<code>openevidence-mcp</code> 雖能提供完整 MCP 伺服器體驗，但仍需要本地進程管理與 stdio／HTTP 設定。對於僅需要在對話中偶爾查詢醫學文獻的使用者而言，將相同工具介面封裝為 Skill，可大幅降低安裝與維護門檻。</p> <h2 id="methods方法" > <div> <a href="#methods%e6%96%b9%e6%b3%95"> # </a> Methods（方法） </div> </h2> <p>本專案的設計原則是「1:1 鏡像」：完整對齊 <code>openevidence-mcp</code> 的工具呼叫名稱、參數與回傳格式，使既有的 prompt 與工作流可在不改寫的情況下切換到 Skill 模式。實作刻意僅依賴 Python 標準函式庫，避免額外的 <code>pip install</code> 步驟，使技能包可在任何具備 Python 的環境中執行。</p> <p>部署面則透過 <code>npx skills add htlin222/openevidence-skill</code> 一行指令完成安裝，將檔案複製到 Claude Skills 目錄下即可被 Claude Code、Claude Desktop 與其他相容客戶端讀取。技能包附帶必要的 metadata 與漸進式說明文件，以利 LLM 在判斷是否載入此能力時取得最少且必要的訊號。</p> <h2 id="results結果" > <div> <a href="#results%e7%b5%90%e6%9e%9c"> # </a> Results（結果） </div> </h2> <p>使用者可在不另外維護長駐 MCP 伺服器的情況下，於 Claude 對話中即時呼叫 OpenEvidence 工具。Skill 形式相較於 MCP 伺服器，啟動延遲更低、跨機器同步更容易；對於以個人筆電為主的醫師工作流尤其友善。1:1 介面亦使團隊能在 MCP 與 Skill 之間自由切換，依環境選擇最適合的部署方式。</p> <h2 id="discussion討論" > <div> <a href="#discussion%e8%a8%8e%e8%ab%96"> # </a> Discussion（討論） </div> </h2> <p>本專案展示了「同一能力、多種封裝」的工程實踐：當底層 API 穩定後，重點便轉移到如何降低使用者採用成本。限制方面，Skill 缺乏 MCP 完整的工具發現與互動協定，較不適合複雜長對話；標準函式庫的限制亦使網路重試與並發控制較為簡略。未來可進一步考慮以 WASM 化的方式分發，或建立 Skill 與 MCP 之間的自動轉換工具。</p> <h2 id="連結" > <div> <a href="#%e9%80%a3%e7%b5%90"> # </a> 連結 </div> </h2> <ul> <li>GitHub：<a href="https://github.com/htlin222/openevidence-skill">htlin222/openevidence-skill</a></li> <li>主要語言：Python</li> <li>最後更新：2026-05-07</li> </ul>