DeepSRT already does these things: plays a video, produces a summary, fetches a transcript. So — what happens if it also turns into an MCP server that serves nothing but this machine?
It means Claude Code, Kiro, Codex, Cursor — any agent that speaks MCP — can get a summary or a transcript for any YouTube video through DeepSRT. And it can drive DeepSRT itself, and put a video on your screen for you.
Hey, find Big Bang's newest video this week and just play the most popular one.
Hey, check every Fox News story today and tell me what the top five are about.
At the end of the note about having no servers we wrote one line that was really a promise: private MCP support is on the way, so your AI agents can talk to DeepSRT directly.
It's built. It arrives in the next version.
What it actually looks like
You add DeepSRT to your agent's MCP configuration once. After that, the agent can do this:
Those two are what we were aiming for. These two are transcripts of what actually ran.
Search YouTube for "swift 6 strict concurrency", pick the most relevant result, check whether it has captions, and if it does, summarize it in bullet mode.
Three tool calls, thirty-six seconds, and a summary whose bullets carry timestamps that point at the exact moment in the video. Or, more bluntly:
Play the latest video from that channel.
The agent lists the channel's uploads, takes the newest one, and the video opens on your screen. Nothing about that request mentions a URL.
Six tools
| Tool | Required | Optional | What it does |
|---|---|---|---|
| search_videos | query | limit (1–50, default 20) | Search YouTube by keyword. Free and fast. Returns video id, title, channel, duration. |
| list_channel_videos | channel(URL, @handle, or UC… id) | limit (1–50, default 30) | A channel's recent uploads. Returns the resolved channel title — check it, handles can mislead. |
| get_video_info | video(URL or 11-char id) | — | Title, channel, and which caption languages exist, without downloading any captions. Free. |
| get_transcript | video | lang | Full timed transcript as sentence-merged blocks, each with start time and duration. |
| open_in_app | video | t (start seconds, default 0) | Opens the video in the DeepSRT window and brings the app to the front. |
| summarize_video | video | lang, mode (narrative / bullet) | AI summary from the captions; bullet mode carries [MM:SS] timestamps. Uses your AI key, 10–30s on long videos. |
Five of those are free and fast. One of them spends your AI credits. That asymmetry turned out to be the most important design decision in the whole feature.
Teaching a model to be cheap
Left to its own instincts, a model asked to "find videos about X and tell me what they say" will call the expensive summarizer on every single search hit. That's your money.
So the server ships explicit guidance for the model: work cheap-to-expensive, narrow down with the free tools first, and summarize only what survived. get_video_info exists largely so an agent can ask "does this video even have captions, and in what language?" before committing to read them. In practice the agents do exactly that — one of them volunteered "this video has no captions, so a summary would fail" before we asked.
The endpoint is authenticated from day one
DeepSRT already ran a small local API on the loopback interface for its browser extension. Adding agent tools to it changes the stakes: these tools spend your AI credits, so an unauthenticated endpoint would let any program on your Mac bill you.
So the MCP endpoint requires a bearer token, minted into your macOS Keychain, from the very first request. Settings shows it with a one-click copy of the whole configuration block, so nobody has to hand-assemble JSON.
There's a second rule that costs nothing and closes a real hole: the endpoint refuses any request that carries an Origin header at all. Real MCP clients are not browsers and never send one. A request that does is a web page probing your loopback port — the DNS-rebinding attack the MCP specification explicitly tells servers to defend against. Rejecting the whole class is cleaner than maintaining a list of exceptions.
The specification moved six days before we shipped
MCP's 2026-07-28 revision landed a week before this work: it makes the protocol stateless, deletes the initialize handshake, deletes protocol-level sessions, and deletes the long-lived server stream. Good news for an implementer — much less to hold.
The specification's own compatibility guidance suggests telling the eras apart by whether a request carries the MCP-Protocol-Version header. We built it that way. It was wrong, and the way it failed is worth writing down.
That header has existed since 2025-06-18. So a client from the 2025 era sends it and still uses the old handshake, and still omits the per-request metadata the 2026 rules require. We tested against a real agent that opens with an unheadered initialize and then stamps MCP-Protocol-Version: 2025-11-25 on everything afterwards. Our server classified those requests as modern, rejected them for missing fields — and the client reported zero tools, with no error message anywhere. It connected successfully and simply had nothing.
The fix is one line of judgement: the era follows the version value, never the presence of the header. Both eras are served, and unknown versions are refused before an era is chosen at all — otherwise they quietly fall through to the legacy path. Regression tests now replay that exact client sequence.
Reality is messier than handles
One more thing the agents taught us. Ask for "that creator's latest video" and a model will guess the channel handle from the creator's display name. That guess is often wrong in a way nobody notices: one handle we tried belongs to an entirely different channel with no videos at all, and the obvious second guess turned out to be the creator's secondary channel.
The tool used to return only a channel id, which made a wrong resolution invisible. Now it returns the resolved channel's name, and when a listing comes back empty it explains both possibilities instead of leaving the agent to retry the same call forever. Small change; the difference between a tool that fails and a tool that tells you why.
Why this belongs here
DeepSRT has no servers. Everything it can do, it does on your machine with your own key. That was always framed as a privacy and reliability argument, but it has a consequence we like more: because everything runs locally, everything is reachable by your own tools.
There's no API to apply for, no rate limit tier, no data leaving your Mac to be summarized somewhere else. Your agent gets the same access you have — which is the whole point of it running on your side of the wire.
Coming in the next update.