AutomateSocials

Generate a video

generate_video

Destructive

Makes a short video with its own audio and stores it, ready to attach to a post. It takes a few minutes: over MCP or the API it may answer with status "processing" and a jobId instead of a mediaId; then call get_video_status with that jobId until it gives the mediaId, and only then save the draft. Say what it will cost first; video is the most expensive thing here and is charged by the second. Pass imageId to animate a picture the project already has - a product photo or one you generated - and it becomes the first frame. Structure the prompt with [VISUAL], [SPEECH], [SOUNDS] and [TEXT] sections; English is the language the model is validated in.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>"
    },
    "name": "generate_video"
  }
}

Input Schema

Name	Required	Description
`model`	No	A model from list_video_models.
`prompt`	Yes	What happens, what is said, what is heard. E.g. "[VISUAL] a hand lifts the jar... [SPEECH] Three plants, one minute. [SOUNDS] quiet kitchen".
`imageId`	No	A picture in this project to animate; it becomes the first frame.
`seconds`	No	How long. Shorter is cheaper and usually better.
`audioUrl`	No	Narration or music to build the visuals around.
`imageUrl`	No	A public picture to animate, if it is not one of ours.
`resolution`	No	Defaults to 720p, which is right for a phone screen. Higher costs several times more; list_video_models has the rates.
`aspectRatio`	No	16:9, 9:16 for reels, TikTok and YouTube Shorts, 1:1, 4:3, 3:4, or auto to let the model choose.
`negativePrompt`	No	What to keep out of it.
`ignoreProjectStyle`	No	Make exactly this prompt, without the project's video template. Only when the user asks for something outside their usual look.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations flag it as destructive, open-world, and non-idempotent, but the description adds the crucial behavior they cannot express: it is asynchronous, may return a jobId instead of a mediaId, and must be polled via get_video_status before saving. It also discloses that it takes minutes and is billed by the second, which is the most consequential runtime behavior here.

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-loaded with the operation and its cost, then the async workflow, then parameter guidance; nearly every sentence carries actionable information. It is dense rather than bloated, though the long middle sentence about jobId/mediaId could be tightened.

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

Completeness5/5

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

For a 10-parameter, expensive, asynchronous generation tool with no output schema, the description covers the async polling contract, the cost warning, language constraints, and the key optional parameters. Combined with the destructive/open-world annotations, an agent has everything needed to invoke it correctly and safely.

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

Parameters4/5

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 still adds value by explaining that imageId becomes the first frame, that the prompt should be structured with [VISUAL]/[SPEECH]/[SOUNDS]/[TEXT] sections, and that English is the validated language. That is real semantics beyond the schema text, though much of the parameter explanation overlaps with existing field descriptions.

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 and resource ('Makes a short video with its own audio') plus the outcome ('stores it, ready to attach to a post'), which cleanly separates it from generate_image and the draft/save tools. An agent can identify the operation 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.

Usage Guidelines5/5

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

It gives an explicit operating sequence ('may answer with status "processing" and a jobId ... then call get_video_status ... and only then save the draft'), an explicit cost prerequisite ('Say what it will cost first'), and a conditional for imageId and ignoreProjectStyle ('Only when the user asks for something outside their usual look'). When-to-use, prerequisites, and follow-up tools are all named.

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

All AutomateSocials tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?