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.
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.
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.
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.
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":
list_models: looks for a model that does 9:16 at 5 seconds. get_model: reads that model's input contract (which fields exist, which are required, which durations are valid).estimate_cost: returns the credit cost 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:
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.
A few requests that work well in plain sentences:
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.
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?