Give your AI agent local eyes on your footage

An AI agent is only as useful as the tools it can reach. Give one a calendar and it schedules; give it a shell and it writes code. But point it at “the folder with 300 hours of interviews” and it's helpless — it can't watch video, and it certainly can't remember which clip mentioned the pricing change.

MediaFind already turned that folder into something an agent can use: a timestamped, embedded, searchable index built entirely on-device. The MCP server is the last mile — it exposes that index to your agent as callable tools, so the assistant you already talk to can now answer questions about your own footage.

What MCP actually is

The Model Context Protocol is an open standard for connecting AI applications to outside tools and data. A client — Claude Desktop, Claude Code, Cursor, or any MCP-capable agent — launches a server, discovers the tools it offers, and calls them mid-conversation. Think of it as the USB-C of agent tooling: one protocol, many tools, no bespoke glue per app.

Crucially, an MCP server can run on your machine and talk to the client over stdio — no network hop, no hosted endpoint. That's the property that lets MediaFind join the agent ecosystem without giving up the thing it exists to protect.

It's a facade, not a rewrite

Here's the part that made this cheap to build: MediaFind's engine already backs two front-ends — the desktop app and the mediafind CLI — through the same core modules. The MCP server is a thin third face over that same engine. Each tool is a few lines that call the exact function the app and CLI already call. No second copy of the index, no re-implemented search, no divergence to keep in sync.

The MCP server is one more face on an engine that already had two. Tools call the same functions the app and CLI use — so search means the same thing everywhere, and there's only ever one index.

The tools your agent gets

The server exposes a small, sharp set of tools — each wrapping a real engine call, not a re-implementation:

search_media — natural-language, multimodal search over the library; returns the matching clips with timestamps.
ask_library — a grounded answer to a question, stitched from your own transcripts with citations to the exact second (how that works).
get_transcript — the transcript and summary for one indexed file.
library_status — index size, entitlement, and trial state.
list_people — the clustered people/faces roster (a Pro tool).
memory_save — saves conversation turns in a named memory library, creating it if needed. Give your agent a library of its own, such as assistant.
memory_search — recalls stored turns from a memory library as a bounded context block.
memory_reset — deletes a memory library the agent filled with memory_save. A library holding any conversation saved another way, such as chats you imported, is refused and left as it is.

Because the tools share the engine, they also share its license gate. A free user whose agent calls a Pro tool gets the same structured upgrade nudge the app shows — the paywall lives in one place, not re-litigated per surface.

Where the privacy line sits — and why we say it out loud. Every tool runs on your machine, but whatever a tool returns lands in your agent's context — and from there it goes to whatever model your agent runs. library_status carries no library content, just counts and entitlement. ask_library and get_transcript return on-device text — an answer, a transcript — and by default so does search_media: its hits carry text about each match, such as a transcript line, a summary, on-screen text, a matched note or chapter title, entity names, and labels like speaker or person. memory_search returns the conversations stored in the memory library it names, including chats you imported, and the Pro list_people tool returns people's names. That's your trust boundary, and the tool descriptions state it plainly so you choose it deliberately. To keep that text on your machine, set MEDIAFIND_MCP_ALLOW_CONTENT=0 in the server's environment: ask_library, get_transcript, memory_search and list_people then refuse with content_disabled, and search_media returns only where each hit is and how well it matched — file path, timestamp, score. memory_save and memory_reset keep working, and memory_reset only clears a memory library the agent filled itself: one holding a conversation you imported is refused and left as it is. The media itself never moves; only what a tool returns is exposed to that agent's model.

This is the honest version of “private.” We're not going to pretend a transcript handed to a third-party agent stays on your Mac — it doesn't, and you should know that. What we can promise is that nothing happens implicitly: the recordings stay put, every tool runs locally, and content crosses the line only in the results of a tool you invoked on purpose — search snippets included, unless you switch them off.

Setting it up

The packaged app serves its own MCP server, so there's no separate install. Open Settings → Connect to AI agents, hit Add to Claude Desktop, and it writes the config for you (or copy the one-line command for Claude Code / Cursor). Nothing else to download.

An earlier version of this post also offered pip install "mediafind[mcp]" and a one-click .mcpb Claude Desktop bundle. Neither is available yet: MediaFind isn't on PyPI (the mediafind package there is a placeholder that holds the name), and the bundle only wraps a Python install of MediaFind.

Add a folder in the app once and your agent has something to search. If you already use MediaFind, that index is already built; the MCP server reads the very same one.

What a call looks like

From the agent's side, your library is just another tool. Ask Claude “find the moment we discussed the January price increase” and it calls:

search_media(query="January price increase discussion", k=3)

→ [{ "media_path": "mtg-q3.mp4", "timestamp": "11:48",
     "text": "…we agreed to push the price increase to January…",
     "score": 0.83 }, … ]

The agent gets a path and a timestamp it can cite back to you — the same grounded, checkable result the app would show, delivered into the conversation you were already having.

Why local-first is the whole point

A cloud connector can't reach a folder on your laptop, and the usual fix — upload your footage so a service can index it — surrenders exactly the privacy MediaFind exists to protect. A local MCP server is the one integration that gives an agent full reach over your library while the library stays on your disk. You can check the boundary the same way you can for the rest of the app:

$ mediafind audit
✓ core path opened 0 external sockets.

Search and status ride that same local path. The agent reaches your media; your media doesn't reach the cloud.

MCP is the smallest possible bridge between a capable local engine and the agents people already use. Same index, same license gate, same privacy story — just one more face on the engine. If your assistant can already do half your job, it might as well be able to search the footage too.

Point your agent at your own footage

Free trial. No account, no API keys, and nothing uploaded to make search work.

Download for macOS Set up MCP →

Keep reading

Ask your library: local RAG over your own media, with citations · Ask Search by meaning: embeddings, CLIP and a local vector index · Search Secure by design: how MediaFind stays local by default · Security

Give your AI agent local eyes and ears on your footage