Skip to main content
Glama
veniceai

Venice MCP Server

Official
by veniceai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Venice Video Queue

venice_video_generate

Queue video generation from text, images, or video with selectable AI models; returns a queue ID to poll generation status.

Instructions

Queue a video generation. Supports Sora 2, Veo 3.1, Kling, Wan, LTX 2, Seedance, Runway Gen-4, and others. Pick a specific id like "veo3.1-fast-text-to-video", "veo3.1-fast-image-to-video", "kling-2.6-pro-text-to-video", "wan-2.6-text-to-video", "seedance-2-0-r2v" etc. Uncensored: NSFW prompts allowed where the model permits. Supports x402 wallet auth (no Venice account needed) and API key. Returns { model, queue_id }; poll with venice_video_status. NOTE: 'duration' is a model-specific string enum like '4s' / '6s' / '8s'; inspect it with venice_model_details. Current public Seedance models may reject detectable persons outright. Consent flags are defensive compatibility support, not a policy bypass; set them only after showing a returned policy to the user and receiving explicit confirmation.

Input Schema

NameRequiredDescriptionDefault
seedNo
audioNoEnable or disable audio generation for models that support it. Defaults to true.
modelYesRequired. Full model id, e.g. "veo3.1-fast-text-to-video".
promptYes
consentsNoDefensive compatibility support for a returned Seedance needs_consent flow. Current public models may reject detectable persons outright. All three flags must be true after explicit user confirmation and cannot bypass content policy.
durationYesDuration as model-specific string enum, e.g. "4s", "6s", "8s". See venice_model_details.
elementsNoFor Kling O3 R2V and similar: up to 4 character/object elements. Reference in prompt as @Element1, @Element2, etc.
audio_urlNoFor models that support audio input: background music. URL or data URL. Supported: WAV, MP3. Max 30s, 15MB.
image_urlNoFor image-to-video models: starting frame. URL or data URL.
video_urlNoFor video-to-video models (e.g. seedance-2-0-r2v): input video. URL or data URL. Supported: MP4, MOV, WebM.
resolutionNoOutput resolution, e.g. "720p", "1080p", "4k". Model-specific; see venice_model_details.
aspect_ratioNoOutput aspect ratio, e.g. "16:9", "9:16", "1:1", "4:5", "9:21". Model-specific; see venice_model_details.
end_image_urlNoFor models that support end frames or transitions. URL or data URL.
upscale_factorNoFor upscale models only: 1 = quality enhance, 2 = double resolution, 4 = quadruple.
negative_promptNoNegative prompt (what to avoid). Supported by Seedance and other models.
scene_image_urlsNoFor models with advanced element support: up to 4 scene reference images. Reference in prompt as @Image1, @Image2, etc.
reference_audio_urlsNoFor Seedance 2.0 R2V and similar: up to 3 reference audio clips for vocal timbre, narration, or sound effects. Per-clip 2–15s, WAV/MP3; aggregate ≤15s. Must be paired with at least one reference image or video. Each a URL or data URL.
reference_image_urlsNoFor models with reference image support: up to 9 images for character/style consistency. Each a URL or data URL.
reference_video_urlsNoFor Seedance 2.0 R2V and similar: up to 3 reference video clips to inherit subject motion, camera movement, and style. Per-clip 2–15s, MP4/MOV, ≤50MB; aggregate ≤15s. Each a URL or data URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.3.0
    • addedInput schema / properties / aspect_ratio / description
      Added value: +"Output aspect ratio, e.g. \"16:9\", \"9:16\", \"1:1\", \"4:5\", \"9:21\". Model-specific; see venice_model_details."
    • removedInput schema / properties / aspect_ratio / enum
      Removed value: -[
-  "16:9",
-  "9:16",
-  "1:1",
-  "2:3",
-  "3:2",
-  "3:4",
-  "4:3",
-  "21:9"
-]
    • addedInput schema / properties / consents
      Added value: +{
+  "additionalProperties": false,
+  "description": "Defensive compatibility support for a returned Seedance needs_consent flow. Current public models may reject detectable persons outright. All three flags must be true after explicit user confirmation and cannot bypass content policy.",
+  "properties": {
+    "seedance": {
+      "additionalProperties": false,
+      "properties": {
+        "confirmed_legal_right": {
+          "const": true,
+          "description": "Set true only after the user confirms legal rights/consent for every depicted person and all submitted media.",
+          "type": "boolean"
+        },
+        "confirmed_screening_acknowledged": {
+          "const": true,
+          "description": "Set true only after the user acknowledges automated media screening.",
+          "type": "boolean"
+        },
+        "confirmed_terms_and_privacy": {
+          "const": true,
+          "description": "Set true only after the user confirms the returned policy text and Venice terms/privacy.",
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "confirmed_terms_and_privacy",
+        "confirmed_legal_right",
+        "confirmed_screening_acknowledged"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "seedance"
+  ],
+  "type": "object"
+}
    • changedInput schema / properties / duration / description
      Previous value: -"Duration as model-specific string enum, e.g. \"4s\", \"6s\", \"8s\". See GET /v1/models/:id/card."New value: +"Duration as model-specific string enum, e.g. \"4s\", \"6s\", \"8s\". See venice_model_details."
    • changedInput schema / properties / resolution / description
      Previous value: -"Output resolution, e.g. \"720p\", \"1080p\", \"4k\". Model-specific; see model card."New value: +"Output resolution, e.g. \"720p\", \"1080p\", \"4k\". Model-specific; see venice_model_details."
    • changedInput schema / required
      Previous value: -[
-  "prompt",
-  "model"
-]New value: +[
+  "prompt",
+  "model",
+  "duration"
+]
  2. First observedv0.2.0

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: it discloses the return shape { model, queue_id }, the polling workflow, that x402 wallet auth works without a Venice account, the NSFW/uncensored posture, and that Seedance may reject detectable persons outright. It also clarifies that consent flags are defensive compatibility, not a policy bypass—material behavioral context the minimal annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and model list, then layers auth, return shape, and the consent caveat. The final consent NOTE is dense but earns its place given the nested const-true schema; a small amount of model-name listing is redundant but tolerable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 19-parameter, no-output-schema tool, the description supplies the missing return contract and polling flow, which the schema cannot. Combined with 89% parameter coverage, an agent has enough to call it, though cost/quote routing (venice_video_quote) and sync-vs-queue alternatives are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 89%, so the schema already documents nearly every parameter including duration enums, consents nesting, and URL fields. The description largely restates the duration-format and consent guidance found in the schema, adding little syntax or format meaning beyond it. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Queue a video generation") and immediately names the poll counterpart venice_video_status, so the agent can distinguish it from the status/complete siblings. Enumerating the supported model families and example ids makes the scope concrete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational routing: poll with venice_video_status and inspect model-specific duration via venice_model_details, plus explicit sequencing for consent flags. It does not say when to prefer this over venice_video_complete or other generation siblings, so it stops short of full when/when-not coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools