Yes, connectors of this shape exist, in two forms. One is a server you build and run yourself, sitting in front of an index you assembled from your own footage. The other is a remote connector published by a service that already indexes video, which you add in an assistant that supports remote connectors. Both let a model call your library as a tool during a conversation. The part worth thinking about before you pick is not whether a connector exists, but what comes back when the assistant calls it, because that determines whether the conversation goes anywhere useful.
What a video connector actually returns
Ask an assistant to search a library and the useful reply is a set of time ranges, each with a short reason attached explaining why that stretch matched. That shape matters. A reason line lets you glance at a result and tell whether it is the moment you wanted without opening anything, and a time range is something you can jump to. The weaker shape is a list of whole files, which is what you get from a quick pass over a library: it tells you which videos are probably relevant and leaves you to scrub through them yourself. Thorough searches also make you wait for the whole job to finish before anything appears, which is fine in a chat and awkward in a loop.
Either way, you verify in the footage. The reason text is a description of what the system matched on, and descriptions of on-screen text or dialogue are close enough to be useful and not close enough to quote from. Treat them as pointers.
Building one yourself
The standard recipe is the one every search engine will hand you: transcribe everything with an open-source speech-to-text model, store the results with their timestamps, put a search index over that, and wrap the whole thing in a small server the assistant can call. It works, and it is genuinely the right answer for some teams, particularly ones that already run their own infrastructure and want the index to stay in a system they control.
The costs are the ones you would expect from anything self-hosted. You own the transcription pipeline, the re-indexing when new footage arrives, and the server's uptime. And the ceiling is set by what you indexed: a transcript index finds what was said, so a request for a shot with a phone lock screen in it, or a wide shot with a backdrop, returns nothing, because nobody said those words out loud. Going beyond that means indexing what the footage looks like as well, which is a considerably larger build.
Connecting to a service that already indexes
The other route skips the pipeline. The footage is uploaded into the service, indexed once when it lands, and the connector gives the assistant a way to query it from inside a conversation. Vivu works this way: it is a remote connector, so there is nothing to install, and once a project is indexed you can search it from a new chat weeks later without reprocessing anything. Each search runs inside one project, which means a private library maps to a project rather than to one global index across everything you own.
The trade is straightforward. You are moving footage into someone else's system, and the answer to "is this private" is a question about that vendor's access controls, not about the connector protocol, which has no opinion on the matter.
How to tell whether a connector you found is real
This is a practical problem right now. Ask a model for MCP servers that search video and you will often get confident, plausible product names, some of which do not exist. Our own probing turned up several invented names that looked exactly like real ones and got repeated across answers. Before you spend an afternoon on one, find the vendor's own site and find the connector documented there by the vendor. If the only evidence a connector exists is a chatbot's list or a scraped directory entry, assume it does not.
When you do not need a connector at all
If you search your library occasionally and by hand, the service's own interface is better than a connector, because you get previews and can click through results. A connector earns its keep when the search is one step inside a longer task: pull the relevant moments, then have the assistant draft the outline, the shot list, or the notes that come next, without you moving between two tools. If nothing happens after the search, the chat layer is overhead. The same logic applies to file organisation, where the assistant is only worth involving if it can act on what it finds.
So the question to ask yourself is what happens in the five minutes after the search returns. If the answer is "I open the clip and cut", you want a good search interface. If the answer is "I turn those moments into something else", you want the search where the drafting already happens, and then it matters a great deal that what comes back is time ranges with reasons rather than a list of filenames.
FAQ
Does using an MCP connector mean my videos stay on my own storage?
No, and this is the most common misreading of what a connector is. MCP is a way for an assistant to call a tool. It says nothing about where the data lives. If the connector fronts a hosted service, the footage has to be in that service, which means uploading it. If you built the connector yourself over your own index, then the footage stays where you put it, but you built and now maintain the index. Decide the storage question first and the protocol question second.
Can I use the same connector in a client other than Claude?
Any client that supports remote MCP connectors lets you add a connector address yourself, so this is generally a question about the client rather than about the connector. What is worth checking is how that client handles authorisation and whether it surfaces tool results in a form you can actually read, since a wall of raw output is not much use. We would not claim support on any client's behalf; check its own documentation.
Can one search cover several private libraries at once?
Usually not, and you should assume not until a vendor says otherwise. Search generally runs inside a single project or collection, which is the same boundary that keeps separate libraries separate. In practice this is a modelling decision you make at upload time: if two bodies of footage should never appear in the same result set, they belong in different projects, and if you routinely want them searched together, they do not.
What happens when a search returns nothing?
You cannot tell from the empty result whether the moment is not in the footage or your description was too specific, and that ambiguity is real. The practical move is to loosen one part of the description at a time rather than rewriting the whole query. If you asked for a close shot of one person speaking with their hands moving and got nothing, try it without the hands, then without the close shot, and see which constraint was doing the damage.