Give your AI assistant a video studio over MCP (and the tool pattern that keeps it from burning your credits)

Most MCP demos read files or query databases. Those tools are cheap and reversible. The interesting design problem starts when a tool spends money: generating a video can cost real credits, and an assistant that calls it in a loop can empty a balance before you notice.

This post does two things. First, a five-minute setup that gives Claude Code or Cursor video, image and voice generation over a remote MCP server. Second, the tool design that makes it safe to hand an assistant a paid tool. The pattern works for any MCP server that costs money to run, not just this one.

Disclosure: the server in the examples is Vidofy's, which is our own product. The setup steps and the pattern are general.

Remote vs. local MCP servers

A local MCP server is a process you install and run next to your client, usually with an API key in an environment variable. A remote server is just a URL. You add the URL, your client opens a browser sign-in, you approve it, and the client holds the permission. There is nothing to install and no key to paste into a config file or leave in a chat log.

That second part matters more than it sounds. A key in mcp.json ends up in dotfiles repos and screenshots. A permission you approved in the browser can be revoked per client, and the other clients keep working.

Setup in Claude Code

claude mcp add --transport http vidofy https://vidofy.ai/mcp-app 

Then, inside Claude Code, run /mcp, pick vidofy, and approve the sign-in in the browser that opens. After that, ask for an image or a video in the same session.

Setup in Cursor

Add this to ~/.cursor/mcp.json, or .cursor/mcp.json in your project:

{ "mcpServers": { "vidofy": { "url": "https://vidofy.ai/mcp-app" } } } 

Enable it in Cursor's MCP settings and approve the sign-in. Claude.ai, Claude Desktop, ChatGPT, VS Code and Codex have the same flow with their own menus.

Some clients cannot complete a browser sign-in because they expect to register themselves. For those, the same package runs locally against a personal token:

{ "mcpServers": { "vidofy": { "command": "npx", "args": ["-y", "@vidofy/mcp"], "env": { "VIDOFY_TOKEN": "vmt_..." } } } } 

You create that token once in your account settings. Same account, same balance.

The pattern: estimate first, generate second

Here is what an assistant sees when you ask for "a 9:16 clip of a cyclist riding through neon-lit rain, about 5 seconds, and tell me what it costs first":

1. list_models: looks for a model that does 9:16 at 5 seconds.
2. get_model: reads that model's input contract (which fields exist, which are required, which durations are valid).
3. estimate_cost: returns the credit cost before anything runs.
4. You approve, or ask for something cheaper.
5. generate, then get_status, then get_result: run it, follow it while it renders, return the file.

The important part is step 3. Generation is slow and costs money, so the server separates deciding from doing:

• A separate read-only tool prices the job. The assistant asks "what would this cost?" and gets a number. It is the same calculator the web studio uses, so there is no second price list to drift.
• The input contract is a tool too. get_model returns what a model accepts, so the assistant reads the real fields and valid values instead of guessing parameter names.
• Status is polled, not awaited. Rendering takes a while. get_status lets the assistant report progress instead of holding a request open until a timeout.
• The surface is small and closed. The server exposes nine tools in total, and the assistant can do nothing outside them.

If you are building an MCP server around anything metered (GPU time, API calls, SMS, renders), copy that split: one tool to look up what is possible, one to price a specific request, one to commit. You give up one round trip and get back a spending limit the user can see.

What it is good for in practice

A few requests that work well in plain sentences:

• Restyle a product shot. Point it at an image already in your account and ask for a cleaner background.
• Turn a still into motion. It looks for an image-to-video model that accepts your aspect ratio and duration.
• A voice-over. Text in, speech out in the voice and language you name, then reuse it as the audio for a clip.
• A set instead of one file. The same idea in four aspect ratios, run together.
• A revision without re-uploading. A finished result can be the input to the next generation, because the file is already in your account.

On clients that support MCP Apps, such as Claude, the result arrives as a live card that updates while the clip renders. On a text-only client the same information comes back as text.

Try it

The connector page lists every client's exact steps, the model catalogue and the nine tools: vidofy.ai/en/mcp. New accounts start with free credits, so you can run the flow above without paying anything first.

If you build MCP servers yourself, I would like to hear how you handle paid tools. Do you price first like this, or cap spend some other way?