Visualizee MCP server
Connect Visualizee to Claude, Claude Code, Cursor, or any MCP client. Render images, video and 3D models by chat with your own account, plan and workspace.
Visualizee ships a hosted MCP (Model Context Protocol) server, so any MCP-capable assistant, including Claude, Claude Code, and Cursor, can render with your Visualizee account. Your assistant gets seven tools: it can generate images (with an inline preview right in the chat), video clips and textured 3D models, collect a render that is still processing, upload your local photos as references, look up the available models, and check your balance and plan limits. Everything runs against your own account, and every render is filed into your Visualizee workspace.
The server lives at a single URL:
https://visualizee.app/api/mcp
It speaks Streamable HTTP and authorizes with OAuth 2.1: the first time a client connects, you sign in at visualizee.app and approve access. There are no API keys.
Blog and marketing imagery generated straight from your writing tool, renders dropped into a proposal while you draft it in Claude, or agent workflows that produce visuals on a schedule. If your assistant can call tools, it can now render.
Connect from Claude Code
Add the server from your terminal:
claude mcp add --transport http visualizee https://visualizee.app/api/mcp
Then, inside a Claude Code session, run /mcp and pick visualizee to authenticate. Your browser opens visualizee.app; sign in and approve access. From that point the tools are available in every session.
If you prefer project-level config, add this to .mcp.json in your project root:
{
"mcpServers": {
"visualizee": {
"type": "http",
"url": "https://visualizee.app/api/mcp"
}
}
}
Connect from claude.ai and Claude Desktop
Open connector settings
Go to Customize → Connectors, click + Add and choose Add custom connector. Every Claude plan can add one; Free allows one custom connector.
Add the server
Name it Visualizee and paste https://visualizee.app/api/mcp as the URL.
Sign in
Click Connect. You will be sent to visualizee.app to sign in and approve access, then returned to Claude. Enable the connector in a chat and ask for a render. For a walkthrough with four real renders, see Can Claude generate images?
Connect from Lovable
Add the connector
Open the Connectors dashboard, scroll to the bottom of the All view, and
pick the Custom (MCP) card. Name it Visualizee and paste
https://visualizee.app/api/mcp as the server URL.
Authorize
Keep OAuth selected and click Add & authorize. Sign in at visualizee.app, approve access, and ask for a render in the Lovable chat.
Connect from Cursor
Add the server to .cursor/mcp.json (per project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"visualizee": {
"url": "https://visualizee.app/api/mcp"
}
}
}
Cursor will prompt you to authenticate on first use. Any other MCP client that supports Streamable HTTP and OAuth works the same way: point it at the URL and sign in when asked.
The tools
| Tool | What it does |
|---|---|
render_image | Generates an image, waits for it to finish (up to about 4 minutes), and returns an inline preview plus the final image URL and a link to the file in your workspace. Also the edit tool: pass a previous render as a reference to iterate on it. |
upload_image | Uploads a local photo or screenshot (up to 8 MB) to your workspace and returns a public URL
to use as a |
render_video | Generates a video clip, optionally animating reference images. Returns the clip, or a
|
render_3d_model | Turns one to four images of one object into a textured 3D model (GLB) on the Pro and Max
plans. Returns the GLB, a lighter copy for big files and a preview, or a |
get_render | Fetches a render by its |
list_models | Lists the available image, video and 3D models with their categories, costs, and supported parameters. |
get_credits | Reports the remaining balance and what the plan can render - image and video resolution ceilings, pro renders left this month, whether 3D models are included, and whether output is watermarked. |
You rarely call these by name. Ask for what you want ("render a 16:9 image of ...") and the assistant picks the right tool and parameters.
render_image parameters
| Parameter | Default | Notes |
|---|---|---|
prompt | required | Plain-language description of the image. |
modelId | best base model | An id from list_models. Only set it when you want a specific model. |
aspectRatio | 1:1 | For example 16:9, 4:3, 9:16. Must be supported by the model. |
resolution | 1024 | Long-edge scale, for example 1024 or 2048. |
ingredientUrls | none | Up to 4 reference image URLs for image-to-image: a previous render to iterate on, or a URL
from |
background | none |
|
projectName | Claude MCP renders | The Visualizee project the render is saved into, found or created by name. One project per workstream (a client, a campaign, "Blog posts"), shared by all the jobs inside it. |
chatName | none | The chat inside that project which groups this job's renders (a blog post title, "Kitchen", "Wheels"), found or created by title. Renders filed into a chat show up there as a conversation you can continue with Vizzy. |
folderName | workspace root | An optional folder path for the project, "/"-separated for nesting (for example "Clients/Acme"), found or created on the fly. |
Editing and iterating
There is no separate edit tool - editing is a render with the previous image as a reference. To change something about a result, ask for another render with the previous render's URL in ingredientUrls and an instruction that states what to preserve and what to change:
"Take the last render and change only the wheels to black 19-inch rims - keep the car, camera angle, and lighting exactly the same."
Two things make this reliable:
- State a preserve/change contract. A reference image alone drifts; naming what must stay identical ("keep the composition and materials, change only the sky to dusk") is what keeps a series consistent.
- Chain result URLs. Each result reports its URL; feed it into the next call to build a series of variations from the same base.
Your own photos work the same way. If the image lives on your machine ("here's a photo of my kitchen"), the assistant calls upload_image first, then uses the returned URL as an ingredient. Ingredient URLs are checked for reachability before a render starts, so a dead link fails fast and never costs anything.
Rendering video
render_video generates a clip, optionally animating reference images you pass in ingredientUrls. It defaults to Seedance 2.0 at 1080p (or the best resolution your plan allows), 16:9, the model's shortest duration, and audio on.
A clip is billed as roughly base cost x seconds x resolution multiplier. On Seedance 2.0 that means a 5-second 1080p clip costs about 3,400 credits, where a typical image costs 80 to 150. Higher resolutions multiply sharply (1080p is 2.25x the base, 4K is 5.12x). Your assistant is instructed to confirm duration, resolution, and audio with you - and to tell you the cost - before it renders.
Video parameters
| Parameter | Default | Notes |
|---|---|---|
prompt | required | A director's brief plus a beat timeline. See below. |
duration | model minimum | Seconds, from the model's supported list (Seedance 2.0: 4-15, Seedance 2.5: 4-30, Kling v4: 3-30, MiniMax H3: 5-15). Cost scales linearly. |
resolution | 1080p | 720p, 1080p, or 4K. Capped by your plan - see below. |
aspectRatio | 16:9 | For example 9:16 for vertical, 21:9 for cinematic. |
audio | true | Generates a soundtrack. Costs nothing extra on Seedance 2.0, and is ignored by Kling v4 and MiniMax H3, which always generate audio. |
ingredientUrls | none | Reference images to animate (up to 9 on Seedance 2.0 and MiniMax H3, 10 on Kling v4, up to 50 on Seedance 2.5). |
Video resolution is capped per plan: Hobby renders at the lowest rung (720p, or 768p on MiniMax H3), Pro up to 1080p (2K on MiniMax H3), and Max up to 4K (1080p on Kling v4 and Seedance 2.5, which stop there). Asking for more than your plan allows names the resolution you can use rather than silently downgrading the clip - the What your plan can render table under Cost and limits has the full picture.
Collecting a finished clip
Video takes noticeably longer than an image - commonly two to eight minutes. render_video waits about two and a half minutes; if the clip is not ready by then it returns a generationId and status pending. Your assistant then calls get_render with that id to collect the finished video. The clip is charged once, and the render completes in your workspace either way.
Prompting for video
Video models respond to plain-language directing, not parameter lists. A good prompt has two parts:
- The brief - what the subject and scene do (the reference images already show what things look like), one primary camera move, and the atmosphere.
- A beat timeline covering the whole clip, one line per beat:
[00:00-00:02] slow dolly forward begins, wind stirs the grass.
Every image you attach goes into one reference list tagged @Image1, @Image2, and so on. There is no first-frame/last-frame slot - several images are read as references to the same subject unless you explicitly ask for a transition between them.
When audio is on, describe the sound in the prompt: ambient tone, the diegetic effects the scene would make, and optionally music by character rather than by artist name. Ask for dialogue only if you want it, keep lines short, and say who is speaking. When audio is off, the prompt should not mention sound at all.
Making 3D models
render_3d_model turns one to four images of one object - a game prop, a character, a product, a piece of furniture - into a textured 3D model you can drop into Unity, Godot, Unreal, Blender or a web page. It is on the Pro and Max plans.
| Parameter | Notes |
|---|---|
images | 1 to 4 views, each |
quality |
|
modelId | A 3D model id from list_models, only when you want a specific model. |
summary | What the model is of, shown in the project chat. Optional. |
projectName, chatName, folderName | Where it is filed, as for render_image. |
There is no text-to-3D: every model starts from an image. Ask for a 3D model of something that has no image yet and your assistant renders a concept first with render_image - one object, whole, on a plain background - then builds the model from it. A whole room or scene is not one object, so the assistant renders the piece you want on its own first.
One view works, but the model has to guess every side it cannot see. A front, a side and a back view of the same object, at the same size and in the same light, give a model whose back matches what you drew. Your assistant can make those views from an accepted render with render_image before calling render_3d_model.
A model takes 2 to 4 minutes. The tool waits about 4 minutes; if the model is not ready by then it returns a generationId, and get_render collects it. The result has the full GLB (textures up to 4K on Pro), a lighter GLB with 2K textures when the full file is over 8 MB, and an inline preview. The model is also filed in your workspace, where you can turn it and check its shape in Clay.
Where renders end up
Every MCP render is saved into your Visualizee workspace, not just returned as a URL. The workspace nests folder > project > chat > renders, and three parameters control where a render lands:
projectNamepicks the project: one shared canvas per workstream, such as a client, a campaign, a car build, or "Blog posts". A project holds many unrelated chats, so your assistant should reuse one project for a whole workstream rather than creating a new one per job.chatNamepicks the chat inside that project: one per job, such as a blog post title, "Kitchen", or "Wheels". Every render and iteration for the same job goes into the same chat, and the project's chat list ends up reading like a table of contents. Each chat opens in the app as a conversation you can carry on with Vizzy.folderNameis an optional folder path for the project, nested with "/" (for example "Clients/Acme"). Folders only group projects, so most workstreams need none.
With no names given, renders collect in a project called Claude MCP renders at the workspace root. Names match case-insensitively and are created on the fly, so repeated renders for the same job always land in the same place, even when several run in parallel. The server tells your assistant this model up front, so it picks sensible names on its own when you do not spell them out.
Each result includes a direct link to the project, which opens on the chat the render was filed into, so you can jump from your assistant into the workspace and keep iterating there.
Cost and limits
- Renders count against your plan the same way as in the app; the cost and remaining balance are reported with every result. See plans and renders for what your tier includes.
- If a render fails or cannot start, its cost is refunded automatically.
- Pro-tier models respect your plan's monthly pro-render limit. Seedance 2.0, the default video model, is a pro-tier model.
- Video is billed per second and per resolution, so clips cost hundreds to thousands of credits where an image costs 80 to 400. Read the Rendering video section above before turning an assistant loose on it.
- 3D models cost a flat 900 credits on Pro and 300 on Standard, the same for one view or four, on the Pro and Max plans only.
- For scale: a 1K image costs 80 credits on Base, 150 on Pro and 300 on Ultra. Base costs 107 at 2K, Pro 300 at 4K, and Ultra 400 at 2K and 500 at 4K. Free starts with 400 credits; Hobby includes 7,500 a month, Pro 19,250 and Max 48,000.
What your plan can render
Every request is checked against your plan before anything is charged, and a request that exceeds it comes back with the nearest thing you can run rather than a bare refusal:
| Limit | Free | Hobby | Pro | Max |
|---|---|---|---|---|
| Image resolution | 1024 | 2048 | uncapped | uncapped |
| Video resolution | 720p (768p on MiniMax H3) | 720p (768p on MiniMax H3) | 1080p (2K on MiniMax H3) | 4K |
| 3D models | no | no | yes | yes |
| Pro renders / month | 1 | 15 | no separate cap | no separate cap |
So asking for a 2048px image on Free answers "the Free plan renders images up to 1024px - re-run with resolution 1024"; asking for 4K video on Pro points at 1080p; and exhausting the pro-render quota names a base model that does the same job without touching it. When a clip costs more than your balance covers, the reply names the largest clip your balance does cover - for example "the largest clip your balance covers is 6s 720p for 1,824 credits".
Call get_credits to read all of this up front - your balance, both resolution ceilings, pro renders left, whether 3D models are included, and whether output is watermarked - so an assistant can choose workable settings before spending anything.
render_image waits for the result and can take a few minutes at high resolutions. If a render times out but completes later, the image still appears in the target project in your workspace, and failed renders refund on their own. render_video waits a shorter window and hands back a generationId for get_render instead, because clips routinely outlast a single request. render_3d_model does the same when a model takes longer than about 4 minutes.
Example prompts
Things you can ask once the server is connected:
- "Render a 16:9 hero image of a Scandinavian living room at golden hour and save it in project 'Blog posts', chat 'Autumn palettes'."
- "List the Visualizee models and pick the cheapest one that supports 21:9."
- "Use this product photo as a reference and render it in a minimalist concrete showroom, 4:3."
- "Take the render you just made and change only the wall color to sage green - keep everything else identical."
- "Animate that render into a 5-second clip with a slow push-in and soft room tone - tell me what it will cost first."
- "Make a 3D model of that chest for Unity - render a side and a back view first so the back is right."
- "What can my plan still render this month?"