Generate images, video, speech, music and text with 450+ AI models, one API key and one balance.
Scored across 7 tools
Each tool maps to a distinct modality or lifecycle step: text, image, music, speech, video creation, video polling, and model discovery. The async pair create_video/get_video is explicitly delineated in the descriptions, and no two tools could plausibly be confused for the same job.
All names are snake_case verb_noun and readable, but the verb convention splits: four tools use generate_* while the video pair uses create_video/get_video. That deviation is defensible (create/poll lifecycle) but an agent might briefly wonder whether a generate_video also exists.
Seven tools is tightly scoped to the domain: one generator per media type, one async poller, and one discovery tool. Nothing feels redundant or missing at the count level.
The generation surface is broad (video, image, music, speech, text/website/svg, model listing) and the async video flow has both start and poll. Minor gaps exist: no cancel/abort for in-flight renders, no way to list or retrieve past generations, and no job-status tool for anything but video.
Start generating a video from a text description with GenMagic (or animate an image: pass 'image' as the opening frame), with any text-to-video model, clip length, resolution and sound the model supports (list_models with category "video" shows them and the per-second price). Video is asynchronous, so this returns a job id immediately (nothing is charged yet). Poll it with the get_video tool every few seconds until the status is "completed" to get the hosted video URL. A failed render is never charged. On-brand automatically when the account has brand personalization on.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Optional image (an https URL or a data:image URL) the clip opens on: image-to-video. The prompt then describes the motion. list_models shows each model's frame_images, and in its video prices image_input_usd or image_to_video_usd_per_second where a model bills image-to-video apart. | |
| model | No | Optional GenMagic model id for the video (call list_models with category "video" for the ids and prices). Omit it to let GenMagic choose its default. | |
| prompt | Yes | A description of the video to create. | |
| duration | No | Clip length in seconds, one of the lengths the model supports (list_models shows durations_seconds). Omit for the model's default. | |
| last_frame | No | Optional image (an https URL or a data:image URL) the clip ends on, for models whose frame_images include last_frame. | |
| references | No | Optional reference images (https URLs or data:image URLs) of characters, objects or a look the clip keeps consistent, none of them a frame of it: reference-to-video. Name what each shows in the prompt. Not combined with image or last_frame. list_models marks the models made for it with references: true. | |
| resolution | No | Output resolution the model supports, e.g. 720p or 1080p (list_models shows resolutions). Omit for the model's default. | |
| aspect_ratio | No | Aspect ratio: 16:9 (landscape), 9:16 (portrait), or 1:1 (square). Defaults to the opening image's shape when 'image' is portrait or landscape, otherwise 16:9. | |
| generate_audio | No | Generate sound with the clip on models that support it (list_models shows audio_supported; a model with audio_always makes sound on every clip). Omit for the model's default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that nothing is charged at submit time, that failed renders are never billed, that the call returns a job id rather than a video, and that brand personalization applies automatically when enabled. These are exactly the cost/asynchrony facts an agent needs and that no structured field carries.
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?
Front-loaded with the core action, then the async/polling rule, then billing. Dense and purposeful, though the opening sentence is long and chains several qualifiers that could be split for faster scanning.
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 9-parameter, non-idempotent, open-world generation tool with no output schema, the description covers the full lifecycle: submission, job id return, polling contract, billing edge cases, and where to look up model capabilities. Nothing essential is missing.
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% and each parameter already documents itself thoroughly (including frame_images, references exclusivity, and aspect_ratio defaulting). The description largely restates that information at a high level rather than adding new semantics, so the baseline 3 is appropriate despite the strong prose.
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?
Opens with a specific verb+resource ('Start generating a video from a text description with GenMagic') and immediately covers the image-to-video variant, which distinguishes it from generate_image and the other generators. The model/pricing pointer to list_models tells the agent exactly where to resolve downstream choices.
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 states the async contract and the required follow-up ('Poll it with the get_video tool every few seconds until status is completed'), names list_models as the source of valid models/lengths/prices, and gives the condition for using the image path. Very little is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text description with GenMagic. Pass 'image' (an https or data URL) to transform THAT image instead of generating from scratch (image-to-image), and type "logo" to make a brand mark. Returns the image inline plus a hosted URL. On-brand automatically when the account has brand personalization on.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Image size, e.g. 1024x1024 (square), 1792x1024 (wide), 1024x1792 (tall). | |
| type | No | Set to 'logo' to generate a brand mark instead of a picture. | |
| image | No | Optional reference image (an https URL or a data:image URL) to transform (image-to-image), e.g. a character to keep consistent. | |
| model | No | Optional GenMagic model id for the image (call list_models with category "image" for the ids and prices). Omit it to let GenMagic choose its default. | |
| prompt | Yes | A description of the image to create (or the edit to make when 'image' is given). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readonly, open-world, non-idempotent, non-destructive. The description adds real context beyond them: the return shape (inline image plus hosted URL) and an account-level side effect (output is on-brand when brand personalization is enabled). It omits cost/quotas, though it points at list_models for prices.
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?
Purpose and the default mode come first, then the two mode-switching caveats, then the return value. Dense and largely waste-free, though the trailing 'On-brand automatically...' clause is slightly compressed and reads as a run-on addition.
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?
No output schema exists, and the description compensates by stating what comes back (inline image plus hosted URL). With 5 params fully documented in schema, mode-switching explained, and model selection delegated to list_models, an agent has everything needed to call it correctly.
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 baseline is 3, but the description adds semantic framing the schema lacks: that 'image' switches the operation mode to image-to-image rather than being a mere optional field, and that 'type' controls logo vs picture. It does not restate size/model details, which the schema already covers.
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?
Specific verb + resource ('Generate an image from a text description with GenMagic') and it immediately distinguishes three modes: text-to-image, image-to-image (pass 'image'), and logo ('type "logo"'). An agent can tell this apart from generate_video/generate_music/generate_text by modality alone.
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?
Explicit conditional guidance: pass 'image' to transform an existing image instead of generating from scratch, and set type 'logo' for a brand mark. It does not name sibling tools to route away from, but the modality split across siblings makes that unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an original music track from a text description with GenMagic. Returns the audio inline plus a hosted URL. On-brand in mood automatically when the account has brand personalization on.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional GenMagic model id for the music (call list_models with category "audio" for the ids and prices). Omit it to let GenMagic choose its default. | |
| prompt | Yes | A description of the music to create (genre, mood, instruments, tempo). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true, non-idempotent and non-destructive, so the safety profile is covered. The description adds real value beyond that: the return shape (inline audio plus hosted URL) and the implicit brand-personalization behavior that changes output without any parameter. It stops short of noting that each call is a fresh, billed generation.
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 short sentences with the core action front-loaded and the return format immediately after; nothing is buried. 'with GenMagic' is slight branding filler, keeping it just under a perfect score.
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 two-parameter generation tool with no output schema, the description covers what matters most: the input is text, the output is audio plus a URL, and brand personalization can alter results. Cost and latency, hinted at by the list_models price reference in the schema, are the main omissions.
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 both prompt and model are already documented with examples of what to include. The description only echoes 'from a text description' and adds no syntax, length, or model-default guidance beyond the schema. Baseline 3 applies when the schema carries the parameter burden.
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?
States a specific verb and resource ('Generate an original music track from a text description') and names the provider, which cleanly separates it from the audio-adjacent siblings like generate_speech and generate_image. An agent can tell exactly what modality and output this produces without opening the schema.
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?
Usage is only implied by the modality contrast with siblings; the description never states when to prefer this over generate_speech or create_video, nor any exclusions or prerequisites. The only alternative-routing guidance (call list_models for model ids) lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn text into spoken audio with GenMagic. Returns the audio inline plus a hosted URL. The text is voiced verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The text to speak, read aloud verbatim. | |
| model | No | Optional GenMagic model id for the speech (call list_models with category "audio" for the ids and prices). Omit it to let GenMagic choose its default. | |
| voice | No | Optional voice name (e.g. alloy); list_models shows each speech model's voices. Defaults to a neutral voice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, non-idempotent, and open-world generation, so the safety profile is covered. The description adds useful context that the audio is returned inline with a hosted URL and that text is spoken verbatim, but it does not mention that calls are billed or that repeated calls yield different audio despite idempotentHint=false.
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 short sentences, front-loaded with purpose, then output, then the verbatim constraint. No filler and nothing redundant with the title.
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?
With no output schema, the description correctly compensates by describing the return (inline audio plus hosted URL). Fully documented parameters and annotations leave little else needed, though cost/billing and the non-idempotent nature of repeated generation are unaddressed.
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% and all three parameters document their own defaults and the list_models lookup path. The description adds nothing beyond the schema on parameters; 'voiced verbatim' merely restates the input field's own description, so the baseline 3 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?
States a specific verb and resource ('Turn text into spoken audio'), which unambiguously separates this tool from generate_text, generate_music, generate_image, and create_video without needing to name them. It also states the output shape (inline audio plus hosted URL) in the same breath.
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?
No explicit when-to-use or when-not-to-use guidance is given, and no prerequisites (credits, auth, model selection) are stated. The use case is strongly implied by the purpose, but the agent must infer that selecting a voice/model belongs to list_models rather than here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate text with GenMagic: copy, an answer, a draft, code, an SVG graphic, or a complete web page. Pass 'type' to make a specific artifact ("website" for a full self-contained HTML page, "svg" for a vector graphic, "code" for a code snippet, "writing" for prose); omit it for plain text. Attach files for the model to read via 'attachments' (PDF, Word/Excel/PowerPoint, CSV, text/code, images, audio); GenMagic converts anything a model cannot ingest natively. If the caller's account has brand personalization on, the output comes out on-brand automatically, and a website or svg also picks up the brand's palette and typeface.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | The kind of artifact to make. Omit for plain text. | |
| model | No | Optional GenMagic model id for the text (call list_models with category "text" for the ids and prices). Omit it to let GenMagic choose its default. | |
| prompt | Yes | What to write or produce. | |
| system | No | Optional system instruction to steer tone, role, or format. | |
| attachments | No | Files for the model to read. Each item is { name, mime, dataUrl } where dataUrl is a base64 data URL (data:<mime>;base64,...). Any type is accepted: PDF, docx/xlsx/pptx, csv, text/code, images, audio. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint=true and non-idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: account-level brand personalization silently alters output (palette and typeface for website/svg), and non-native file types are auto-converted. It stops short of stating latency, cost, or output shape, but list_models is named as the pricing path.
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?
Front-loaded with the core action and artifact options, then attachments, then brand behavior — a sensible order. It is one dense paragraph and re-enumerates the 'type' values already spelled out in the schema, which is mild waste but not distracting.
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?
No output schema exists, so the description carries the return-value burden; it does so implicitly (a self-contained HTML page, a vector graphic, a snippet, prose), though it never states the response envelope or where the artifact lands. For a five-parameter generative tool with full schema coverage and rich annotations, that is a small residual gap.
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 baseline is 3; the description earns above that by explaining the consequence of omitting 'type' (plain text) and by clarifying the attachment contract in prose — including that any file type is accepted and converted server-side. The restated enum values overlap with the schema rather than extend it.
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?
States a specific verb and resource ("Generate text with GenMagic") and enumerates the concrete artifact classes it can produce, which cleanly separates it from generate_image, generate_music, and generate_speech. An agent can identify the tool's job without opening the schema.
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?
Gives explicit selection logic for its own 'type' parameter (use "website"/"svg"/"code"/"writing", omit for plain text) and explains when to use attachments. It never routes to or excludes siblings, however — notably it does not clarify how "svg" here differs from generate_image, which is a plausible point of confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a video started with create_video. Returns "queued" or "processing" while it renders, "completed" with the hosted video URL when it is ready, or a terminal failure if the render failed. Poll every few seconds until it is either completed or failed (both are terminal: stop polling once you see one). The clip is charged once, on completion.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The video job id returned by create_video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real context beyond annotations: the enumerated return states, the terminal-state rule, and the fact that billing happens once on completion (which explains the readOnlyHint=false despite this being a status check). It doesn't say anything about how long queued jobs typically take or how to handle 404s on an expired job id, so the behavioral picture isn't fully closed.
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 tight sentences ordered by importance: what it checks, what it returns, then how to poll and when billing occurs. Every sentence carries information an agent needs to drive the loop correctly.
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?
No output schema exists, and the description compensates fully by enumerating the possible return states and their meanings. Nothing an agent needs to correctly poll and interpret a result is missing.
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% and the single parameter is already described as 'the video job id returned by create_video'; the description only repeats that provenance. Baseline 3 applies since the schema does the work for one param.
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?
States a specific verb and resource ('Check a video started with create_video') and names the sibling that produces the id, so it's immediately distinguishable from create_video and the generate_* family. The purpose is unambiguous without opening the schema.
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?
Gives explicit usage guidance: poll every few seconds, and stop once the status is completed or failed because both are terminal. It also rules out over-polling implicitly by stating the terminal conditions. No alternative tool competes for this role, so nothing more is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the AI models GenMagic runs, newest first, with each one's id, price and key details (context window and capabilities for text, voices for speech, resolutions, clip lengths and sound for video). Pass a model's id as 'model' to generate_text, generate_image, generate_speech, generate_music or create_video. Filter by category and search; the model marked default is the one that runs when no model is named (for generate_text, when no type is given either). Needs no API key and costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many models to return (1-100, default 25). | |
| search | No | Only models whose id or name contains this text, e.g. veo, flux, claude. | |
| category | No | Only models of this kind. audio holds both speech and music models. | |
| capability | No | Text models only: keep models with this capability. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description adds the genuinely non-obvious bits: no API key required, zero cost, and how the 'default' marker governs behavior when no model is named. It omits pagination/return-size behavior, but limit is schema-documented.
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 dense sentences, front-loaded with what is returned before the integration hint. Every sentence carries information, though the parenthetical about video fields (resolutions, clip lengths, sound) is slightly list-heavy.
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?
No output schema exists, and the description compensates by enumerating the return payload shape (id, price, plus category-specific details). Combined with the default-model semantics, an agent has everything needed to call and interpret it.
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 all four params are already documented, including the audio-holds-speech-and-music enum nuance. The description mainly restates filtering rather than adding new parameter mechanics, so baseline 3 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?
Specific verb + resource ('List the AI models GenMagic runs') with ordering ('newest first') and the returned fields spelled out per category. It also distinguishes itself from the generate_* siblings by explaining that ids from here are passed as 'model' to those 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?
Clear context for use: filter by category/search, and use the entry marked default when no model is named (including the text-type nuance). It names the sibling tools that consume the output but gives no explicit when-not-to-call guidance or caveats about calling it repeatedly.
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.
create_video3 fields changedInput schema / properties / aspect_ratio / descriptionPrevious value: -"Aspect ratio: 16:9 (landscape), 9:16 (portrait), or 1:1 (square). Defaults to 16:9."New value: +"Aspect ratio: 16:9 (landscape), 9:16 (portrait), or 1:1 (square). Defaults to the opening image's shape when 'image' is portrait or landscape, otherwise 16:9."Input schema / properties / audioRemoved value: -{
- "description": "Optional https URL of an MP3 or WAV voice line or track (2 to 30 seconds) the clip speaks or moves to, so one voice made once with generate_speech carries every clip of a character. Only for models that take audio (Wan 2.6 and 2.7); with no model named, one that does is chosen.",
- "type": "string"
-}Input schema / properties / generate_audio / descriptionPrevious value: -"Generate sound with the clip on models that support it (list_models shows audio_supported). Omit for the model's default."New value: +"Generate sound with the clip on models that support it (list_models shows audio_supported; a model with audio_always makes sound on every clip). Omit for the model's default."create_video1 field changedInput schema / properties / audioAdded value: +{
+ "description": "Optional https URL of an MP3 or WAV voice line or track (2 to 30 seconds) the clip speaks or moves to, so one voice made once with generate_speech carries every clip of a character. Only for models that take audio (Wan 2.6 and 2.7); with no model named, one that does is chosen.",
+ "type": "string"
+}create_video1 field changedInput schema / properties / referencesAdded value: +{
+ "description": "Optional reference images (https URLs or data:image URLs) of characters, objects or a look the clip keeps consistent, none of them a frame of it: reference-to-video. Name what each shows in the prompt. Not combined with image or last_frame. list_models marks the models made for it with references: true.",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 9,
+ "type": "array"
+}create_video1 field changedInput schema / properties / image / descriptionPrevious value: -"Optional image (an https URL or a data:image URL) the clip opens on: image-to-video. The prompt then describes the motion. list_models shows each model's frame_images."New value: +"Optional image (an https URL or a data:image URL) the clip opens on: image-to-video. The prompt then describes the motion. list_models shows each model's frame_images, and in its video prices image_input_usd or image_to_video_usd_per_second where a model bills image-to-video apart."create_video2 fields changedInput schema / properties / imageAdded value: +{
+ "description": "Optional image (an https URL or a data:image URL) the clip opens on: image-to-video. The prompt then describes the motion. list_models shows each model's frame_images.",
+ "type": "string"
+}Input schema / properties / last_frameAdded value: +{
+ "description": "Optional image (an https URL or a data:image URL) the clip ends on, for models whose frame_images include last_frame.",
+ "type": "string"
+}create_video4 fields changedInput schema / properties / durationAdded value: +{
+ "description": "Clip length in seconds, one of the lengths the model supports (list_models shows durations_seconds). Omit for the model's default.",
+ "type": "integer"
+}Input schema / properties / generate_audioAdded value: +{
+ "description": "Generate sound with the clip on models that support it (list_models shows audio_supported). Omit for the model's default.",
+ "type": "boolean"
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional GenMagic model id for the video (call list_models with category \"video\" for the ids and prices). Omit it to let GenMagic choose its default.",
+ "type": "string"
+}Input schema / properties / resolutionAdded value: +{
+ "description": "Output resolution the model supports, e.g. 720p or 1080p (list_models shows resolutions). Omit for the model's default.",
+ "type": "string"
+}generate_image1 field changedInput schema / properties / modelAdded value: +{
+ "description": "Optional GenMagic model id for the image (call list_models with category \"image\" for the ids and prices). Omit it to let GenMagic choose its default.",
+ "type": "string"
+}generate_music1 field changedInput schema / properties / modelAdded value: +{
+ "description": "Optional GenMagic model id for the music (call list_models with category \"audio\" for the ids and prices). Omit it to let GenMagic choose its default.",
+ "type": "string"
+}generate_speech2 fields changedInput schema / properties / modelAdded value: +{
+ "description": "Optional GenMagic model id for the speech (call list_models with category \"audio\" for the ids and prices). Omit it to let GenMagic choose its default.",
+ "type": "string"
+}Input schema / properties / voice / descriptionPrevious value: -"Optional voice name (e.g. alloy). Defaults to a neutral voice."New value: +"Optional voice name (e.g. alloy); list_models shows each speech model's voices. Defaults to a neutral voice."generate_text1 field changedInput schema / properties / modelAdded value: +{
+ "description": "Optional GenMagic model id for the text (call list_models with category \"text\" for the ids and prices). Omit it to let GenMagic choose its default.",
+ "type": "string"
+}list_modelscreate_videogenerate_imagegenerate_musicgenerate_speechgenerate_textget_videoOne API for 100+ AI video, image, music and speech models.
Image, video, audio, face-swap, talking avatars and chat across 300+ AI models, one balance.
500+ AI models in one account: find and price models, make images, video, speech and text.
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
Add one secure layer between your agents and this server.
