MCP, API or web UI: picking a generation surface
One catalog, three ways in. Compared on iteration speed, batch scale, review flow and who can operate each, with a recommendation per role.
The three ways to reach the same model catalog are not tiers, and treating them as tiers is where teams go wrong. The web app is not the beginner version and the API is not the professional one. They are the same models, the same credit balance and the same output, reached through interfaces with genuinely different ergonomics, and the right choice changes per task rather than per person.
I have watched a marketer spend a week trying to learn an API for a job the chat surface does in four minutes, and I have watched a developer generate 300 product images by hand in a browser. Both were using a perfectly good surface for the wrong shape of work.
The three doors, concretely
MCP, inside a coding agent or chat client. Add a custom connector pointing at https://mcp.versely.studio/mcp, sign in with your account, and the generation tools appear inside the assistant you were already talking to. There is no key to store and no code to write. Full walkthrough on the MCP page. If you work in a terminal agent instead, the CLI wires the same connection across Claude Code, Cursor, Codex, Windsurf and others in three commands:
npm install -g @versely/cli
versely auth login
versely install
There is a third variant of this door worth knowing about. npx skills add AI-XLabs-Innovation/versely-skills pulls eight packaged skills into an agent, covering generation, slideshows, movies, UGC, music, social, analytics and full pipelines, so the agent gets procedures rather than only tools. The skills page covers what each one does.
REST API, inside your own service. Requests go to https://api.versely.studio/api/v1. You handle keys, job polling, retries, storage and error paths yourself, and in exchange you get generation as a function you can call from anything. The developer page is the entry point.
The web app. The agent chat, the editor, the library, share links and the publishing integrations. This is the only surface where a person who has never opened a terminal can do the entire job, and the only one with a real review flow attached.
Compared on the four things that actually differ
| MCP in an agent | REST API | Web app | |
|---|---|---|---|
| Setup | One connector URL, or three CLI commands | Key handling, polling, storage | Sign in |
| Iteration speed | Fastest. State and context carry between turns | Slowest per change, fastest per run | Fast, but each step is a click |
| Batch scale | Tens, comfortably | Thousands | Whatever your patience allows |
| Review flow | None built in | Whatever you build | Library, previews, share links |
| Who can operate it | Anyone who uses an AI assistant | Someone who writes code | Anyone |
| Fails at | Unattended overnight runs | Exploration and taste calls | Volume |
The row people underrate is iteration speed. Inside an agent, the previous generation, the prompt that produced it and your complaint about it are all still in context, so "same thing but warmer and in 9:16" is a complete instruction. That is a different activity from editing a JSON body, and it is why exploratory work belongs in an agent even when the eventual production run belongs in the API.
The row people overrate is batch scale. Most teams who think they need the API need thirty assets, not three thousand, and thirty is comfortably an agent's job, particularly since a single request can fan one prompt across several named models at once.
Where each one genuinely wins
MCP wins exploration. You do not know what you want yet. You are trying four visual directions, or comparing three models on the same prompt, or writing copy and generating against it in the same conversation. The agent holds the thread, and holding the thread is most of the value. This is also where the agent's task catalog is worth skimming once, because a lot of the operations people assume require the API, scheduled series, saved workflows, pipelines, are chat instructions.
The API wins volume and integration. Two shapes justify it. First, real scale: a product catalog, a per-customer render, anything where a human is not in the loop per asset. Second, embedding: generation triggered by something that happens in your own system, a signup, a new SKU, a support ticket. Neither of those is about capability, both are about who or what is initiating the request.
The web app wins review. This is the underrated one. Client work does not end at generation, it ends at approval, and approval needs a link someone can open without an account, a version they can point at, and a way to say "the third one". The editor is EDL-based, so the timeline is a description you re-render rather than a file you overwrite, and preview: true gives a free 480p pass, subject to a short per-user cooldown, before you spend anything on the export. The final export is charged once regardless of how many clips are on the timeline. That combination, cheap looks and one charge at the end, is what makes a real revision loop affordable. The AI video editor page covers the timeline model.
The arithmetic detail that surprises people
Credits are one currency at one price. Nothing about the credits you buy changes between surfaces. But the same job consumes half as many credits when you run it with an API key instead of in the app.
That is a consumption difference, not an exchange rate and not a bonus, and it is worth planning around rather than discovering. If a workload is genuinely repetitive, already specified, and running at volume, moving it behind an API key changes its credit footprint materially. If a workload is exploratory, moving it to the API to chase that will cost you more in wasted generations than it saves, because the surface that makes you iterate slowly makes you iterate worse. The published detail is on the API pricing page.
What does not change between surfaces: there is no API-only plan, no per-seat fee and no separate API wallet. One balance, topped up by the same subscriptions and credit packs.
Per role
| Role | Primary surface | Secondary |
|---|---|---|
| Solo creator | Web app | MCP once the routine is fixed |
| Marketer without code | Web app | MCP through a chat client |
| Developer embedding generation | REST API | MCP for prototyping the prompts |
| Agency with client approvals | Web app for review | API for the production run |
| Ops automating a recurring job | MCP with saved workflows | API when it needs to run unattended |
| Data or catalog work | REST API | Web app to spot-check output |
The pattern in that table is the actual recommendation: prototype in an agent, produce through whichever surface matches the volume, review in the app. Almost nobody should be single-surface. The agent is where you find the prompt, the API is where you run it four hundred times, and the app is where the client sees it.
One habit that pays for itself on every surface: ask for a cost estimate before dispatching a batch. The agent exposes an estimate call that returns per-item and total credits alongside your current balance, using the same pricing logic as the real charge. Checking a 200-item run before you fire it is the cheapest thing you will do all week.
FAQ
Is there a free tier for the API?
No. API calls consume credits from your balance exactly like in-app generations, and there is no free allowance on any surface. The cheapest model in the catalog still costs credits, so you need an active subscription or a credit pack before the first call will run.
Do I get different models on different surfaces?
No. Same catalog everywhere, and the same catalog on every plan. Plans differ only in how many credits you get and how often you are billed, not in which models unlock. If a model is in the catalog, you can call it from any of the three surfaces.
Should I use MCP or the CLI?
They reach the same place. The connector URL is the shorter path if you work in a chat client and want no local setup. The CLI is better if you work in a terminal agent, because one install wires auth and the MCP connection across every agent on the machine at once instead of per client. See the CLI page for what it configures.
When is it actually time to move a workflow to the API?
When the workflow stops changing. That is the real signal, not volume. A pipeline you are still adjusting weekly belongs in an agent, because adjusting it there costs a sentence and adjusting it in code costs a deploy. Once the prompts, models and post-processing have been stable for a few weeks and the only thing growing is the number of times you run it, it has become a job rather than a project, and jobs belong behind an API key. The chat-side patterns worth stealing before you get there are in Versely and Claude over MCP.