Vilva over MCP: Call Creative Agents and AI Generation From Any Tool

Most AI creative tools live behind a browser tab. You open the app, you make the thing, you download it, and the work stays there. That is fine until the work needs to happen somewhere else .. inside a script, a Slack bot, a CI step, or the coding agent you already talk to all day.

So we did the obvious thing. We exposed Vilva as a server you can call.

Vilva now runs as an MCP server at https://api.vilva.ai/mcp. One endpoint, one API key, and the same generation, workspace, and agent capabilities you use in the app become callable from any MCP client. Connect Claude, Cursor, Claude Code, or anything that speaks the protocol, and your creative pipeline stops being a place you visit and becomes something other tools can use.

What MCP actually is, briefly

MCP, the Model Context Protocol, is the open standard for handing tools to an AI client. Instead of every app inventing its own plugin format, a client like Claude or Cursor connects to a server and discovers what it can do. No SDK to install, no glue code. You drop a config block in, the client lists the tools, and the model can call them.

Vilva is a standard streamable HTTP MCP server with bearer auth. If your client supports MCP, it already supports Vilva.

One config block, every client

Create an API key in the app under Settings, then point your client at the endpoint:

{
  "mcpServers": {
    "vilva": {
      "type": "http",
      "url": "https://api.vilva.ai/mcp",
      "headers": {
        "Authorization": "Bearer vk_live_..."
      }
    }
  }
}

That is the whole setup. The same block works in Claude Code, Cursor, and any other MCP client, you just paste it where that client keeps its server config. The key is shown once when you create it, so copy it then. You can name keys, set them to expire, and revoke any of them from the same Settings tab.

24 tools, four groups

When a client connects, it gets 24 tools across four areas. You do not have to learn them, the model reads the list and picks what it needs. But it helps to know the shape of what is on the table.

Generation. The full model lineup, callable directly. generate_image, generate_video, generate_voiceover, generate_music, and process_image for background removal and upscaling. list_models tells you what is available and what each costs, check_generation polls a job, and get_asset hands back the finished file with a signed URL. Image and voice calls wait inline for a few seconds and return the result if it lands fast, video and music return a handle you poll. Same models as the app, same outputs.

Agent. This is the part that makes it more than an API. agent_create_run hands a brief to a creative agent and starts a run. list_agents shows which agents you can call, including your own custom ones. Then agent_get_run, agent_get_plan, agent_respond, agent_send_message, and agent_cancel_run let you watch a run, approve its plan, steer it, or stop it. More on this below, because it is the interesting bit.

Workspace. Every run lives in a real Vilva workspace, the same visual canvas you see in the app. list_workspaces, create_workspace, get_workspace_overview, get_node, update_node, and list_workspace_assets let an external tool read and write that workspace directly. So a script can seed a canvas, an agent can build on it, and you can open the exact same board in the browser to keep working by hand. The workspace is shared memory, not a hidden context window.

Account. get_credit_balance and list_api_usage so a program can check what it has to spend and see what it spent. Useful when automation is firing on its own and you want a ledger.

Agents as a service

Direct generation is handy, but the reason to wire Vilva into your stack is the agent handoff. You send a brief and get back a creative team member you can program against, not just a model endpoint.

The lifecycle is built to be safe to automate:

1. Brief. Call agent_create_run with what you want. Optionally name the agent, the workspace, and a credit budget. Leave the agent unset and it runs on the default.
2. Plan and estimate. The agent reads the brief, lays out the steps, and pauses with a plan and a cost estimate. You read it with agent_get_plan.
3. Approve, amend, or reject. agent_respond answers the pause. Approve it, change it, or kill it before a single credit is spent on generation.
4. Run and poll. Once approved, the agent executes on its own .. picking a model per step, generating, carrying each asset to the next stage, building the workspace. You poll with agent_get_run until it finishes.

Because the run is plan-first, you always see the cost before the work happens. And there is a budget circuit breaker underneath: set a credit ceiling on the run, and if it would cross that line, the agent pauses and asks instead of quietly burning through your balance. Automation that cannot run away is the only kind worth leaving unattended.

This is the difference between calling a model and delegating a job. You are not orchestrating every generation by hand from your own code. You hand off a brief the way you would to a person, get a plan back, approve it, and let the agent finish.

Billing draws on your plan, not a new bill

Vilva is a subscription. Each plan comes with a monthly pool of credits, and every generation, in the app or over MCP, spends from that one pool at the same rates. There is no separate API price book and no per-seat tax on automation. A generation fired over MCP costs exactly what it costs in the browser, and failed generations are refunded the same way. Your get_credit_balance over the API is the same balance you see in Settings.

When your monthly credits run low, the work does not hard-stop. You continue pay-as-you-go on overage at the same rates, so an automation running on its own keeps going instead of failing at the worst moment. The point is that the API is not a cheaper side door or a place to top up a few dollars and skip the plan .. it is the plan you already have, reachable from your code.

That matters more than it sounds. It means you can prototype a workflow in the app, see what it costs, and then automate it knowing the bill will not change shape when it moves from a tab to a script.

Who this is for

A few shapes we keep seeing:

• Marketing automation. A brief comes in, an agent drafts the visuals, a human approves the plan, the assets land in a workspace the team can review. The approval gate is the point, nobody ships on autopilot unless you tell it to.
• Inside the tools you already use. Call a Vilva agent from Claude or Cursor mid-task, the same way you call any other MCP tool. The creative step stops being a context switch.
• Pipelines and bots. A CI step that regenerates product shots, a Slack command that turns a line of text into a video, a nightly job that refreshes a batch of assets. Anything that can send an HTTP request can now make and edit media through Vilva.

The common thread is that the creative work no longer has to happen in front of you. It can happen wherever the rest of your work already lives.

Start in two minutes

1. On a paid plan, open Vilva, go to Settings, API Keys, and create a key. Copy it.
2. Paste the config block above into your MCP client.
3. Ask it to list Vilva's tools, then send a brief.

The full developer reference, with the complete tool list and integration examples, lives at vilva.ai/agents/api. If you want to understand the agents you will be calling, custom agents and the memory layer are the two pages worth reading next.

We built Vilva so a creative could go from brief to deliverable without thinking like an engineer. MCP is the same idea pointed the other way: now your engineering can reach the creative work without leaving the tools it already runs in.