# MCP server for video: four different things that phrase can mean > 'MCP server for video' covers at least four unrelated jobs: making video, cutting video, handling video files… Canonical URL: https://vivu.ai/guide/mcp-server-for-video "MCP server for video" covers at least four unrelated jobs: making video, cutting video, handling video files, and finding something inside video you already have. They share a protocol and almost nothing else. Naming the verb you want narrows the choice faster than reading any feature list, because a server built for one of those jobs will not do the other three badly, it will not do them at all. ## The four kinds Generation servers turn a prompt into new footage. The input is text, the output is a file that did not exist before. Editing and clipping servers act on a video you give them: cutting, reformatting, captioning, assembling short versions of long ones. The input is a file and instructions, and the output is a different file. File and storage servers give an assistant access to where video lives. They list, move, rename, and fetch. They work on the container, so they know a file is called panel_final_v3.mp4 and know nothing about what happens in it. Retrieval servers answer questions about the contents of footage you already have. The input is a description, and the output is a location inside a video. This is the category most people mean when they search for the phrase and do not find much, which matches what happens if you ask an assistant to find one in its own connector directory. ## Three questions that sort them Does it see the picture and the audio, or only the file name? This single question separates the storage category from the retrieval category, and it is the one most product pages blur. The mechanics of matching a description against what is actually in a frame are set out in [how search against picture and sound works](https://vivu.ai/guide/how-does-multimodal-video-search-work). Where does the video have to be for it to work? Some servers act on a file you hand over in the conversation. Some read a location you have already given the assistant access to. Retrieval servers need the footage to have been ingested and indexed in advance, which is a commitment rather than a connection. Whether a connector of that kind exists for private libraries at all is the question behind [looking for a connector that searches footage you own](https://vivu.ai/guide/is-there-an-mcp-connector-for-searching-a). What comes back? A file, a block of text, or a time range you can open. That answer determines what the next step in your workflow can be, and it is worth deciding before you shop. Teams that want programmatic output rather than conversational output are usually better served by the options in [the indexing and search services built for developers](https://vivu.ai/guide/what-apis-exist-for-video-indexing-and-search). ## Search recordings you have already uploaded, from an assistant [Vivu](https://vivu.ai/mcp) is a remote MCP connector at `https://mcp.vivu.ai/mcp`, and any assistant that supports remote MCP adds it the same way, Claude and ChatGPT included. Videos are uploaded to a Vivu project through a secure upload page the assistant opens for you, and indexed in the cloud once. A search runs inside a single project, so the project is the unit you plan around rather than the archive as a whole. What comes back is a set of time ranges you can open and preview with a line of reasoning attached to each, and the results you keep can be exported as the original clip. ## Where a retrieval connector stops Description-based search reads your verbs literally. Ask for a moment where one speaker corrects another and you may get back a single range where somebody corrected a small procedural mix-up, which is a correction in the plainest sense and not the substantive disagreement you were after. Writing what the disagreement is about, rather than naming the act, tends to produce ranges closer to what you meant. The other limits are structural. Footage must be uploaded and indexed before any of this works, which rules out the arrangement where a server reads an existing drive in place. Searching draws on an allowance, and the free and paid tiers are listed on Vivu's pricing page. Results are ranges you open rather than frame-exact points, so they are a starting position for an edit and not an edit decision list. And the whole thing works one project at a time, which means the separation between projects is something you design rather than something you query across. If the verb you want is find, the retrieval category is the one to look at, and the question to ask any candidate is what it does with your video before you ever type a query. If the verb is make or cut, you are in a different aisle entirely, and a retrieval server will disappoint you no matter how well it works. ## FAQ ### Is there one MCP server that does everything with video? Not in a useful sense. The four jobs pull in opposite directions, since generation needs models that produce frames, editing needs a render path, storage access needs credentials to your drive, and retrieval needs an index built ahead of time. Assistants are designed to hold several connectors at once, so the normal arrangement is one server per job rather than one server for everything. ### Can an MCP server search video sitting in our existing cloud storage? A storage connector can list and fetch those files, but listing is not searching by content. Anything that answers a question about what happens inside a video needs an index, and building one means the video is processed by whatever service holds that index. Assume that any product promising content search without ingestion is doing filename matching. ### What does the assistant actually receive when a video search runs? It receives structured results rather than video. For a retrieval connector that means locations inside specific videos, each with the reasoning for why it matched, which the assistant can list, group, or write up. Watching still happens in a browser, because the assistant cannot see the footage itself. ### How do we keep two different sets of footage from mixing? Put them in separate projects and search them one at a time, since a search that runs inside one project cannot reach another. This is worth deciding before ingesting anything, because moving footage between projects later is another upload rather than a setting.