Claude can't watch a folder of videos on its own. Before Claude can search a video library, something has to turn the footage into data it can query, and then Claude needs a way to reach that data. There are three practical ways to do it. You can give Claude transcripts to read. You can build your own index and expose it to Claude as a tool. Or you can connect a hosted video search service through MCP (Model Context Protocol), which is the standard Claude uses to call outside tools. Transcripts are enough if you only care about what was said. If you need to find what's on screen, you need one of the other two.
What Claude can see without help
Claude reads what you put into the conversation: text, documents, images. Chat uploads aren't built to take in hours of footage. File-browsing tools that let an assistant list and open files get you a little further, but they only see the file system: names, folders, dates, sizes. If your clips have names like "IMG_4471.MOV", Claude learns almost nothing about what's in them. Sorting files with Claude can tidy up names and folders, but it still only sees the outside of each file.
So the real question is where the index lives.
Route 1: transcripts Claude can read
Transcribe each video, save the transcripts as text files with timestamps, and put them in a Claude project or attach them when you ask a question. After that, a question like "which video did I talk about switching cameras in" works well, and Claude can quote the timestamp back to you.
This route needs a transcription step for every video. It stops scaling once the transcripts are longer than Claude can hold in one conversation. It also finds nothing that wasn't spoken. B-roll, a shot of a whiteboard, a moment where you laugh and say nothing: none of that is in a transcript. There's more on the limits of spoken-word search in search-video-by-spoken-words.
Route 2: build your own index and wrap it in an MCP server
If you're comfortable with code, you can extract transcripts and frame descriptions, store them with embeddings in a vector database, and write a small MCP server that takes a query and returns matching timestamps. Claude then calls your server the same way it calls any other tool.
You get full control over where the data sits. You also own the chunking, the re-indexing every time you add videos, hosting the server, and fixing retrieval when it gets worse. For one person with a large library who likes engineering, that's reasonable. For most people it turns into a long side project.
Route 3: a hosted search service added as a connector
On this route you upload your videos to a service that indexes each one once when it arrives, and Claude reaches the service through a remote MCP connector. You ask in plain language, Claude calls the search, and you get back time ranges you can open. You don't get a list of files. What to check in a video search connector goes into the details.
The costs are the upload itself, a plan that usually meters both indexing and searches, and the fact that your footage now lives in a cloud project. Vivu is one service on this route: once your videos are in a Vivu project, Claude, ChatGPT, or any other assistant that supports remote MCP can ask something like "where do I talk about getting nervous before filming" and get back ranges from several different videos, each with a one-line reason for the match. It has a free tier and a paid tier, and the limits are listed on Vivu's pricing page.
What to expect in the results
Whichever route you pick, the results are candidates. A search on one topic tends to return the direct hits along with moments that are only related, like a passing remark where you expected the full discussion. That's useful, because scattered mentions across many videos are exactly what scrubbing misses. Someone still has to open each range and decide whether it's the right one. Plan on watching the results. Don't just trust the list.
When you don't need any of this
If you have a small number of videos and remember roughly when each one was made, sorting by date and scrubbing is faster than setting anything up. If your filenames and folders already describe the content, a file-browsing tool is enough. And if everything you'd search for was spoken, transcripts in a Claude project will cover it without uploading footage anywhere.
Which route fits you
Ask yourself two questions. Are you searching for words or for pictures? And is the library small enough to fit in Claude's context as transcripts? Words and a small library point to transcripts. If you're searching for pictures, or the library has grown past what you can remember, you need an index that does the watching for Claude. Then the only choice left is whether you'd rather build that index or pay for one.
FAQ
Can Claude watch a video file if I upload it to the chat?
Not in any practical way for a whole library. Chat uploads are built for documents and images, so hours of footage have to become a transcript first, or be indexed by a separate search tool that Claude calls.
Does the same setup work in ChatGPT?
If the search tool is exposed as a remote MCP connector, yes. Any assistant that supports remote MCP connectors can call the same tool. Each client adds connectors in its own way, so follow that client's instructions. Transcript files work in any assistant that accepts documents.
Do I have to upload my videos somewhere?
For a hosted search service, yes. The service indexes the copies you upload. With the transcript route, only the text leaves your machine. If you build your own index, the footage stays wherever you host it.
Can Claude search my YouTube channel directly?
Not by what's inside the videos. Claude doesn't watch YouTube videos. To search the content of your uploads, work from your original files or downloads of your own videos, and either transcribe them or index them with a search tool.