DeepSRT はすでにこれらをこなす:動画を再生し、要約を作り、文字起こしを取ってくる。では——これが姿を変えて、このマシンだけに応える MCP サーバーになったら、どうなるだろう?
Claude Code、Kiro、Codex、Cursor——MCP を話すエージェントなら何でも、DeepSRT 経由でどの YouTube 動画の要約も文字起こしも手に入る。さらに DeepSRT 自体を操作させて、動画を画面に出してもらうこともできる。
ねえ、Big Bang の今週の最新動画を探して、いちばん人気のあるやつをそのまま再生して。
ねえ、Fox News の今日のニュースを全部見て、上位5本が何の話か教えて。
「DeepSRT にサーバーがない理由」の最後に、実は約束だった一文を書いた。プライベートな MCP サポートを準備中で、AI エージェントが DeepSRT と直接やり取りできるようになる。
できあがった。次のバージョンで届く。
実際にはこう動く
エージェントの MCP 設定に DeepSRT を一度追加するだけ。あとはこんなことができる:
上の2つは、私たちが目指していた姿だ。下の2つは、実際に走った記録だ。
swift 6 strict concurrency を検索して、いちばん関連するものを選び、字幕があるか確認して、あれば箇条書きモードで要約して。
ツール呼び出し3回、36秒。返ってきた箇条書きには、動画のその瞬間を指すタイムスタンプが付いている。もっと素朴に言えば:
あのチャンネルの最新動画を再生して。
エージェントがそのチャンネルの投稿を一覧し、最新のものを取り、動画が画面に開く。この頼み方に URL は一切登場しない。
6つのツール
| ツール | 必須 | 任意 | 内容 |
|---|---|---|---|
| search_videos | query | limit(1–50、既定 20) | キーワードで YouTube を検索。無料で高速。video id、タイトル、チャンネル、長さを返す。 |
| list_channel_videos | channel(URL、@handle、UC… id) | limit(1–50、既定 30) | チャンネルの最近の投稿。解決されたチャンネル名を返す——ハンドルは当てにならないので必ず確認する。 |
| get_video_info | video(URL または11文字の id) | — | タイトル、チャンネル、そしてどの言語の字幕が存在するか。字幕自体はダウンロードしない。無料。 |
| get_transcript | video | lang | 文単位に整えたブロックごとの全文。各ブロックに開始時刻と長さが付く。 |
| open_in_app | video | t(開始秒、既定 0) | DeepSRT のウィンドウで動画を開き、アプリを前面に出す。 |
| summarize_video | video | lang、mode(narrative / bullet) | 字幕から AI 要約。bullet モードは [MM:SS] のタイムスタンプ付き。あなたの AI キーを使い、長い動画では10〜30秒。 |
このうち5つは無料で速い。1つだけがあなたの AI クレジットを消費する。この非対称性が、この機能でいちばん重要な設計判断になった。
モデルに節約を教える
放っておくと、「X について話している動画を探して内容を教えて」と頼まれたモデルは、検索結果のすべてに対して高価な要約ツールを呼ぶ。それはあなたのお金だ。
だからサーバーはモデルに明示的に指示する:安いものから高いものへ、まず無料のツールで絞り込み、残ったものだけ要約する。get_video_info が存在する主な理由は、読みに行く前に「この動画にそもそも字幕はあるのか、何語か」を尋ねられるようにするためだ。実際にエージェントはそうする——こちらが聞く前に「この動画には字幕がないので要約は失敗します」と自分から付け足したことがある。
このエンドポイントは初日から認証付き
DeepSRT はもともと、ブラウザ拡張機能のために loopback 上で小さなローカル API を動かしていた。そこにエージェント用のツールを足すと、risk の性質が変わる。これらのツールはあなたの AI クレジットを使うので、認証のないエンドポイントは「この Mac 上のどのプログラムでもあなたに請求できる」状態を意味する。
そのため MCP エンドポイントは最初のリクエストから bearer トークンを要求する。トークンは macOS キーチェーンに保存される。設定画面から設定ブロックごとワンクリックでコピーできるので、JSON を手で組み立てる必要はない。
もう一つ、コストゼロで実在する穴を塞ぐルールがある:Origin ヘッダーを持つリクエストは、すべて拒否する。本物の MCP クライアントはブラウザではないので、このヘッダーを送ることはない。送ってきたなら、それは web ページが loopback ポートを探っているということ——MCP 仕様がサーバーに防御を明文で求めている DNS リバインディング攻撃そのものだ。例外リストを維持するより、クラスごと拒否するほうが清潔だ。
仕様は着手の6日前に変わった
MCP の 2026-07-28 改訂は、この作業の1週間前に確定した。プロトコルはステートレスになり、initialize ハンドシェイク、プロトコルレベルのセッション、長時間のサーバーストリームが削除された。実装者には良い知らせだ——抱えるものがずっと少ない。
仕様自身の互換性ガイダンスは、MCP-Protocol-Version ヘッダーの有無で世代を見分けることを示唆している。私たちはその通りに作った。それは間違いで、しかもその失敗の仕方が書き留める価値がある。
あのヘッダーは 2025-06-18 から存在する。つまり2025年世代のクライアントはヘッダーを送り、同時に古いハンドシェイクを使い、2026年ルールが要求するリクエストごとのメタデータも付けない。実在のエージェントで試したところ、まずヘッダーなしの initialize を送り、その後のすべてに MCP-Protocol-Version: 2025-11-25 を刻んでいた。私たちのサーバーはそれを新世代と判定し、フィールド不足として拒否した——結果、クライアントにはツールが0個、しかもどこにもエラーが出ない。接続は成功し、ただ何もなかった。
修正は判断ひとつ:世代はバージョンの値で決める。ヘッダーの有無では決めない。両方の世代に応え、知らないバージョンは世代を選ぶ前に拒否する——さもないと静かに旧世代の経路へ滑り込んでしまう。今はそのクライアントの手順をそのまま再生する回帰テストがある。
現実はハンドルより雑だ
エージェントが教えてくれたことがもう一つある。「あの人の最新動画」と頼むと、モデルは表示名からチャンネルのハンドルを推測する。その推測はしばしば外れ、しかも誰も気づかない形で外れる。試したあるハンドルは全く別のチャンネルのもので、そこには動画が1本もなかった。2番目の推測は、その人のサブチャンネルだった。
このツールは以前、チャンネル id だけを返していたので、誤った解決は見えなかった。今は解決されたチャンネルの名前を返し、一覧が空のときは両方の可能性を説明する。エージェントが同じ呼び出しを延々と繰り返すことはもうない。小さな変更だが、「失敗するツール」と「理由を教えるツール」の差はここにある。
なぜこの話がここに載るのか
DeepSRT にはサーバーがない。できることはすべて、あなたのマシンで、あなた自身のキーで行われる。これはずっとプライバシーと信頼性の議論として語ってきたが、もっと気に入っている帰結がある:すべてがローカルで動くからこそ、すべてがあなた自身のツールから届く。
申請すべき API もなく、レート制限の階層もなく、どこか別の場所で要約されるために Mac を出ていくデータもない。エージェントはあなたと同じアクセスを得る——それが「あなたの側で動いている」ことの意味そのものだ。
次のアップデートで。