The VicSee MCP server provides tools for AI agents to generate, edit, and upscale images and videos using the VicSee platform. Key capabilities include:
List models: Browse available AI models (image, video, music) with their credit costs and features.
Generate media: Create images or videos from text prompts or source media, supporting text-to-image/video, image-to-image/video, video editing, and reference-based generation using various models (e.g., Seedance, Veo, Kling).
Upscale media: Enhance image resolution up to 8× and video resolution up to 4×.
Monitor tasks: Poll asynchronous generation/upscale tasks and retrieve final media URLs.
Check credits: View current API key credit balance.
Upload files: Upload local images, videos, or audio to obtain public URLs for use in generation.
Inputs accept public URLs, local file paths, or base64 data. Tasks run asynchronously, requiring polling for status.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vicsee-mcp-server Create a 5-second video of a cat playing with yarn."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Generate, edit, and upscale AI video & images from any agent — VicSee as a set of MCP tools.
Works with Hermes Agent, Claude (Desktop / Code), Cursor, OpenClaw, and any MCP-compatible client.
Tool | What it does |
| List available models (Seedance, Veo, Kling, FLUX, Nano Banana, …) + their credit costs |
| Text/image → video or image with a chosen model |
| Poll a task and get the finished media URL |
| Upscale an image |
| Upscale a video |
| Check your credit balance |
Generation is asynchronous: vicsee_generate (or vicsee_upscale_*) returns a task id
immediately — your agent then polls vicsee_get_task until status is completed and reads the
URL from result.url.
Related MCP server: Agnes Video MCP Server
Get an API key at vicsee.com → Settings → API (starts with sk-).
API access requires a paid plan or credit pack.
Add the server to your MCP client config with that key:
{
"mcpServers": {
"vicsee": {
"command": "npx",
"args": ["-y", "@vicsee/mcp-server"],
"env": { "VICSEE_API_KEY": "sk-your-key-here" }
}
}
}That's the whole setup — drop in your key, and your agent can generate.
Claude Desktop: claude_desktop_config.json → mcpServers
Cursor: Settings → MCP → add server (same command/args/env)
Hermes Agent / OpenClaw: add to the MCP servers section of your agent config
Claude Code: claude mcp add vicsee -e VICSEE_API_KEY=sk-... -- npx -y @vicsee/mcp-server
VICSEE_BASE_URL — override the API base URL (defaults to https://vicsee.com/api/v1).
pnpm install
pnpm build
VICSEE_API_KEY=sk-... node dist/index.js # stdio server
# or run from source: VICSEE_API_KEY=sk-... pnpm devPoint your MCP client at the local build by using "command": "node", "args": ["/abs/path/to/dist/index.js"].
"Make me a 5-second video of a kitten chasing a laser."
vicsee_list_models (type: video) → pick e.g. seedance-2-5-text-to-video (up to 30s) or seedance-2-0-text-to-video (adds 1080p/4K)
vicsee_generate (model, prompt, duration: 5) → { id, status: "pending" }
vicsee_get_task (id) … poll … → { status: "completed", result: { url: "https://cdn.vicsee.com/…" } }
Result URLs are served from cdn.vicsee.com — stable VicSee CDN links.
Each generation costs credits; see vicsee_list_models for per-model costs and
vicsee_get_credits for your balance.
MIT
Create an AI image or video with VicSee. Generation is ASYNCHRONOUS: this returns a task id immediately, then poll vicsee_get_task with that id until status is "completed" (the result URL appears in result.url) or "failed". Use vicsee_list_models to pick a model and see its valid options. For image-to-video / image-to-image, pass source images in image_urls. For reference-to-video models (e.g. "seedance-2-0-reference-to-video"), pass references in reference_image_urls / reference_video_urls / reference_audio_urls and refer to them positionally in the prompt as @Image1, @Image2, … IMAGE inputs (image_urls, reference_image_urls) may be a public https URL, a local file path (this server reads and base64-encodes it for you), or a base64 data URI. VIDEO/AUDIO inputs (reference_video_urls, reference_audio_urls) must be public https URLs. For video-edit models (e.g. "happyhorse-video-edit"), pass the source clip in video_url and optionally set audio_setting ("auto" or "origin").
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model id from vicsee_list_models, e.g. "nano-banana-pro-text-to-image" or "seedance-2-0-text-to-video" | |
| prompt | No | Text prompt (required for most models) | |
| image_urls | No | Source image(s) for image-to-video / image-to-image. Each may be a public https URL, a local file path (this server reads and base64-encodes it for you), or a base64 data URI. | |
| reference_image_urls | No | Reference-to-video only: up to 7 reference images. Each may be a public https URL, a local file path (this server reads and base64-encodes it for you), or a base64 data URI. Refer to them in the prompt as @Image1, @Image2, … | |
| reference_video_urls | No | Reference-to-video only: up to 3 public https video URLs (2-15s each, ≤15s total). | |
| reference_audio_urls | No | Reference-to-video only: up to 3 public https audio URLs. | |
| video_url | No | Video-edit models (e.g. "happyhorse-video-edit") only: one public https video URL, 3-15s, to edit. | |
| audio_setting | No | Video-edit models only: "auto" (regenerate audio) or "origin" (keep the source audio). | |
| duration | No | Video length in seconds (e.g. 5, 6, 10, 15) — video models only | |
| aspect_ratio | No | e.g. "16:9", "9:16", "1:1", "landscape", "portrait" | |
| resolution | No | e.g. "1K", "2K", "4K", "720P", "1080P" | |
| output_format | No | Image output format, e.g. "png" or "jpeg" | |
| audio | No | Enable native audio (supported video models) | |
| extra | No | Any additional model-specific params (see the model's options from vicsee_list_models) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous generation, immediate task id return, polling needed for result, and input format rules (public URLs, local paths, base64). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with logical sections (async, model selection, input types). Concise but not terse; every sentence adds value. Could be slightly more compact but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a complex tool with 14 parameters: covers async behavior, polling, model selection, input formats, constraints for all model categories, and edge cases like video-edit audio settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds valuable context: positional referencing for references, constraints on video/audio URLs, and explanation of audio_setting options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create an AI image or video with VicSee.' and distinguishes from siblings by mentioning async behavior, polling, and model selection using vicsee_list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance for different model types (image-to-video, reference-to-video, video-edit) and input requirements. Does not explicitly list when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current VicSee credit balance for the configured API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, non-mutating operation. The description adds that it targets the 'configured API key', which is useful but does not disclose further behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the key action and resource. It contains no filler and is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should at least hint at the return format. It only says 'get...balance' without specifying response structure (e.g., numeric value, JSON object). This yields a moderate gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter semantics, and the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the current VicSee credit balance for the configured API key' with a specific verb (get) and resource (credit balance). It distinguishes from sibling tools like vicsee_generate or vicsee_list_models, which handle different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (checking credit balance). While no explicit exclusions or alternatives are given, the sibling tools are distinctly different, so the usage is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a generation or upscale task by its id. status is one of "pending" | "processing" | "queued" | "completed" | "failed". When "completed", the media URL is in result.url (videos/images) or result.songs (music). When "failed", details are in error. Poll every few seconds until completed or failed.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task id returned by vicsee_generate / vicsee_upscale_* |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral details beyond annotations: status enum values, result fields for completed/failed states, and polling recommendation. Annotations indicate read-only and open-world, which are consistent. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no waste: first states purpose, second lists statuses and result structure, third provides polling guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, annotations, and no output schema, the description covers all needed context: status values, result/error handling, and polling frequency. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description restates the parameter's origin (from generate/upscale) but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it polls a generation or upscale task by ID, specifies status values, and explains result/error fields. It distinguishes from sibling tools like vicsee_generate (creates tasks) and vicsee_upscale_* (creates tasks) by focusing on polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (after generation/upscale) and to poll every few seconds until done. It does not explicitly list alternatives or when not to use, but the context from sibling tools makes it clear it's for polling only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available VicSee models with their capabilities and credit costs. Call this first to find a model id to pass to vicsee_generate. Optionally filter by media type.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by media type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint and openWorldHint, so the agent knows the tool is safe and non-destructive. The description adds useful context by stating the output includes capabilities and credit costs, and reaffirms the read-only nature. No contradictions or missing behavioral traits for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first clearly states the purpose, and the second provides a crucial usage hint and optional filter. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema), the description adequately covers the tool's role and output. It mentions that the output includes model id, capabilities, and credit costs. No mention of pagination or error cases, but for a straightforward listing tool, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the only parameter 'type' is described in the schema as 'Filter by media type.' The description merely echoes this with 'Optionally filter by media type,' adding no new meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists available VicSee models with their capabilities and credit costs. It also explicitly indicates that this should be called first to obtain a model ID for vicsee_generate, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to 'Call this first to find a model id to pass to vicsee_generate,' which is a strong when-to-use instruction. It also mentions optional filtering by media type, but does not provide explicit when-not-to-use or alternative tool scenarios, though sibling context makes alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a LOCAL file (image, video, or audio) from this machine and get back a public https URL. Use the returned url as an input for vicsee_generate — e.g. drop it into reference_image_urls for a reference-to-video storyboard, or image_urls for image-to-video. PREFER this over inline base64 for references: large base64 strings get truncated in tool-call output and the model rejects them. The file uploads directly to storage; only its public URL comes back.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to a local file (image/video/audio) on this machine. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that file uploads directly to storage and only public URL returns, plus warns about base64 truncation. Could add file size limits or supported formats, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a recommendation. No unnecessary words, front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple upload tool with one parameter, description covers purpose, usage pattern, and behavior. Integrates well with sibling tools and explains return value (public URL) despite no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (file_path). Description adds no additional semantic detail beyond the schema's 'absolute path' description, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly describes uploading a local file (image, video, audio) and returning a public URL. Distinguishes from siblings by mentioning usage in vicsee_generate for reference_image_urls or image_urls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring this tool over inline base64 due to truncation risks, and specifies how the returned URL is used in vicsee_generate, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale a publicly accessible image (JPEG/PNG/WebP). Asynchronous: returns a task id — poll vicsee_get_task until completed. upscale_factor defaults to "2".
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | Publicly accessible image URL | |
| upscale_factor | No | Upscale factor (default "2") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds asynchronous behavior beyond annotations (readOnlyHint=false indicates mutation; description clarifies it returns a task id). However, it does not disclose what happens to the original image or any side effects, and lacks authentication/rate limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information. Front-loaded with the core action and essential details about async behavior and default parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the key aspects: input format, async nature, default factor. It could elaborate on what the task response contains, but it directs to poll vicsee_get_task which suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage but description adds value by stating the default value for 'upscale_factor' ("2") which is not in the schema. The description also reinforces the 'publicly accessible' constraint for image_url.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool upscales publicly accessible images, specifying supported formats (JPEG/PNG/WebP) and mentions asynchronous behavior, which distinguishes it from sibling tools like vicsee_upscale_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage guidance: async operation returns a task id to poll, and upscale_factor has a default of '2'. However, it does not explicitly state when not to use this tool or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale a publicly accessible video (MP4/MOV/MKV, up to 60s). Asynchronous: returns a task id — poll vicsee_get_task until completed. upscale_factor defaults to "2".
| Name | Required | Description | Default |
|---|---|---|---|
| video_url | Yes | Publicly accessible video URL | |
| upscale_factor | No | Upscale factor (default "2") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations indicating readOnlyHint=false and openWorldHint=true, the description adds context about async behavior, polling requirement, and constraints (public URL, format, duration). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, constraints, async behavior, and default. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers essential aspects: input constraints, async flow, and parameter default. Does not mention error handling or rate limits, but those are less critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds the default value for upscale_factor ("2"), which provides additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upscale), resource (video), and constraints (publicly accessible, MP4/MOV/MKV, up to 60s). It effectively distinguishes from sibling tool vicsee_upscale_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the asynchronous nature and directs to poll vicsee_get_task for completion. It includes the default for upscale_factor, but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.3vicsee_generatevicsee_get_creditsvicsee_get_taskvicsee_list_modelsvicsee_uploadvicsee_upscale_imagevicsee_upscale_videoEach tool targets a distinct function: generation, credits, task polling, model listing, file upload, and upscaling (image/video). No overlap in purpose.
All tools follow a consistent 'vicsee_verb_noun' pattern in snake_case, making them predictable and easy to distinguish.
7 tools cover the core workflows (generation, upscaling, polling, listing, uploading, credits) without being excessive or sparse.
The surface covers generation, upscaling, and account operations. Missing a cancel/delete task endpoint, but the core async workflow is fully supported.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Create and manage cinematic AI video renders through the Future Video Studio Agent API.
AI image, video & audio generation tools for AI agents, powered by Varoriya.
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vicseeai/vicsee-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
