DeepSRT 已經會做這些事了：播放影片、產生摘要、取得逐字稿。那麼——如果它搖身一變，變成一個只服務本機的 MCP server，會怎麼樣？
那就變成 Claude Code、Kiro、Codex、Cursor，任何支援 MCP 的 agent，都能透過 DeepSRT 拿到任何 YouTube 影片的摘要和逐字稿。甚至可以讓 agent 直接操作 DeepSRT，幫你把影片播出來。
嘿！幫我找 Big Bang 這週的最新影片，直接播放最熱門的那支！
嘿！幫我查一下 Fox News 今天所有新聞，最熱門的五條在講什麼。
在〈為什麼 DeepSRT 沒有伺服器〉的最後，我們寫了一句其實是承諾的話：私有 MCP 支援即將登場，讓你的 AI agent 直接跟 DeepSRT 對話。
做好了。下一版就到。
實際用起來是什麼樣子
你只需要把 DeepSRT 加進 agent 的 MCP 設定一次。之後它就能做這種事：
上面那兩句是我們想達成的樣子。下面這兩個，是實際跑出來的紀錄。
搜尋 swift 6 strict concurrency，挑最相關的一支，確認有字幕，有的話用條列模式摘要。
三次工具呼叫、三十六秒，得到一份條列摘要，每一條都帶著能跳回影片那一刻的時間戳。或者更直接一點：
播放那個頻道最新的影片。
Agent 列出該頻道的上傳、取最新那支，影片就在你螢幕上打開了。整句話裡沒有出現任何網址。
六個工具
| 工具 | 必填 | 選填 | 說明 |
|---|---|---|---|
| search_videos | query | limit（1–50，預設 20） | 關鍵字搜尋 YouTube。免費且快。回傳 video id、標題、頻道、時長。 |
| list_channel_videos | channel（URL、@handle 或 UC… id） | limit（1–50，預設 30） | 某個頻道最近的上傳。會回傳解析到的頻道標題——請確認它，handle 可能誤導。 |
| get_video_info | video（URL 或 11 碼 id） | — | 標題、頻道，以及有哪些字幕語言，而且不下載任何字幕。免費。 |
| get_transcript | video | lang | 完整逐字稿，句子已合併的區塊，每塊帶起始時間與長度。 |
| open_in_app | video | t（起始秒數，預設 0） | 在 DeepSRT 視窗中打開影片，並把 app 帶到前景。 |
| summarize_video | video | lang、mode（narrative / bullet） | 用字幕做 AI 摘要；bullet 模式帶 [MM:SS] 時間戳。使用你自己的 AI 金鑰，長片約 10–30 秒。 |
其中五個免費而且很快，只有一個會花你的 AI 額度。這個不對稱，結果成了整個功能裡最重要的設計決定。
教模型節省
如果放任模型自己來，你叫它「找幾支講 X 的影片然後告訴我它們在說什麼」，它會對每一筆搜尋結果都呼叫那個貴的摘要工具。那是你的錢。
所以伺服器會明確告訴模型：從便宜的做到貴的，先用免費工具收斂範圍，只對留下來的那幾支做摘要。get_video_info 存在的主要理由，就是讓 agent 能先問「這支到底有沒有字幕、是什麼語言」再決定要不要讀。實際上它們真的會這樣做——有一次我們還沒問，agent 就主動補上「這支影片目前沒有字幕，所以要摘要會失敗」。
這個端點從第一天就要驗證
DeepSRT 本來就在 loopback 上跑一個小小的本機 API 給瀏覽器擴充功能用。把 agent 工具加上去之後，風險的性質變了：這些工具會花你的 AI 額度，沒有驗證的端點等於讓這台 Mac 上任何程式都能記在你帳上。
所以 MCP 端點從第一個請求起就要求 bearer token，權杖存在 macOS 鑰匙圈裡。設定畫面可以一鍵複製整段設定，沒有人需要自己手拼 JSON。
還有第二條規則，成本是零但補掉一個真實的洞：任何帶著 Origin 標頭的請求，一律拒絕。真正的 MCP 客戶端不是瀏覽器，永遠不會帶這個標頭。帶了就代表有網頁在探你的 loopback 埠——那正是 MCP 規格明文要求伺服器防範的 DNS rebinding 攻擊。整類拒絕，比維護一份例外清單乾淨得多。
規格在我們動工前六天改版
MCP 的 2026-07-28 版本在這件事開工前一週定案：協定變成無狀態，拿掉了 initialize 握手、拿掉協定層的 session、也拿掉了長連線的伺服器串流。對實作者來說是好消息——要維護的東西少很多。
規格自己的相容性指引建議用「請求有沒有帶 MCP-Protocol-Version 標頭」來區分新舊世代。我們照著做了。那是錯的，而且它失敗的方式值得寫下來。
那個標頭從 2025-06-18 就存在了。所以 2025 世代的客戶端會帶它，同時還是用舊的握手流程，也還是不附上 2026 規則要求的逐請求 metadata。我們拿一個真實的 agent 來測，它先發一個沒有標頭的 initialize，之後每個請求都蓋上 MCP-Protocol-Version: 2025-11-25。我們的伺服器把那些請求判成新世代、因為欠缺欄位而拒絕——結果客戶端顯示零個工具，而且任何地方都沒有錯誤訊息。它連線成功，然後什麼都沒有。
修法只是一個判斷：世代要看版本值，絕不能看標頭有沒有出現。兩個世代都服務，而且不認識的版本必須在「選世代」之前就擋掉——否則它們會安靜地掉進舊世代那條路。現在有回歸測試重播那個客戶端的完整序列。
現實比 handle 混亂
Agent 還教了我們一件事。你說「那位創作者最新的影片」，模型會從創作者的顯示名稱去猜頻道 handle。那個猜測經常錯，而且錯得沒人會發現：我們試過的一個 handle 屬於完全不同的頻道，而且那個頻道連影片都沒有；再猜第二個，結果是那位創作者的副頻道。
這個工具原本只回傳 channel id，所以解析錯了完全看不出來。現在它會回傳解析到的頻道名稱，而列表為空的時候會把兩種可能都說清楚，而不是讓 agent 一直重試同一個呼叫。改動很小，但那是「一個會失敗的工具」和「一個會告訴你為什麼的工具」之間的差別。
為什麼這件事屬於這裡
DeepSRT 沒有伺服器。它能做的一切，都是在你的機器上、用你自己的金鑰做的。這件事我們一直是用隱私和可靠性來論述，但它還有一個我們更喜歡的後果：因為一切都在本機，所以一切都能被你自己的工具取用。
沒有要申請的 API、沒有速率限制的分級、沒有任何資料離開你的 Mac 跑去別處被摘要。你的 agent 拿到的存取權跟你一樣——而這正是「它跑在你這一側」的全部意義。
下一版更新見。