Generate short videos from a text prompt. Pay per clip by card, no account needed.
Scored across 3 tools
Each tool maps to a distinct step in a single async workflow: start a render, poll a render's state, and enumerate past renders. The generate_video description explicitly hands off to get_video_status, so the boundary between the two is unambiguous. No two tools could plausibly be confused.
All three names are snake_case verb_noun constructions (generate_video, get_video_status, list_videos) sharing a common 'video' resource noun. The verbs differ because the actions differ, which is the correct use of a convention rather than a deviation from it.
Three tools is lean but genuinely well-scoped for a single-purpose paid video-rendering service; nothing is redundant or padded. It sits at the thin end of the ideal range, though the async polling pattern justifies splitting generation from status rather than merging them.
The core lifecycle (submit, poll, enumerate) is covered end to end, so an agent can always reach a file URL. However there is no delete or cancel operation for abandoned or failed renders, and no way to check pricing or spend before incurring a $1.00 charge per call.
Generate a short video from a text prompt. Costs $1.00 per 5-second 540x960 clip, payable by card over the Machine Payments Protocol -- no account needed. Returns immediately with a video id; rendering takes 30-90 seconds, so poll get_video_status until it is READY or ERROR.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed for reproducibility | |
| image | No | Optional https URL or base64 photo. When set, the clip is that photo animated for one purchase: duration and resolution are locked to the clip offer. | |
| prompt | Yes | Text prompt describing the video you want to generate | |
| duration | No | Duration of the video in seconds (5-60) | |
| resolution | No | Quality tier key (540x960 or 720x1280). These are tier identifiers, not the output size. On the Wan backend 540x960 renders at 480x832 and is stored upscaled to 540x960, and 720x1280 produces 720x1280 portrait. Read output_width/output_height on the video for the actual dimensions. Omitting the field selects 540x960. The 180x320 and 360x640 tiers are retired: they produced the same 480x832 file as 540x960 and are no longer accepted. | 540x960 |
| negative_prompt | No | Negative prompt to avoid certain content | |
| payment_credential | No | Machine Payments Protocol credential answering the challenge from an earlier payment_required result. Omit it when calling with an API key that has credits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say this is a non-read-only, non-destructive mutation; the description adds the details an agent actually needs: a real monetary cost of $1.00 per clip, an out-of-band card payment flow, an immediate non-blocking return with a video id, and a 30-90 second render window requiring polling.
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, each carrying distinct load: what it does, what it costs and how it is paid, and what the agent must do next. The asynchronous lifecycle is front-loaded right after the capability statement, with no filler.
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 7-parameter paid mutation with no output schema, the description covers the critical unknowns: pricing, payment, latency, and the required polling loop. It leaves minor gaps, such as what happens to a charge on an ERROR result or where the finished video file is retrieved, which the agent must infer from get_video_status.
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 economic meaning to the duration and resolution parameters by pricing the default 5-second 540x960 clip explicitly, letting an agent reason about cost tradeoffs. It does not discuss seed, negative_prompt, or the image parameter, which the schema already documents well.
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 and resource ("Generate a short video from a text prompt") and immediately scopes the artifact (5-second 540x960 clip). It also distinguishes itself from the sibling tools by naming get_video_status as the follow-up rather than a competing generation path.
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 clear operational guidance: call this to create, then poll get_video_status until READY or ERROR, and note that no account is needed because payment is by card via MPP. It stops short of explicit exclusions (e.g. when to instead use list_videos to reuse an existing clip) but the create-then-poll routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the state of one video you started. Returns PENDING, PROCESSING, READY or ERROR, and the file URL once it is READY. Requires the API key that owns it.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | The id generate_video returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive profile. The description adds genuinely new behavioral context: the exact state values returned (PENDING, PROCESSING, READY, ERROR), the fact that the file URL only appears at READY, and the ownership/auth requirement. It stops short of stating rate limits or whether repeated polling is expected.
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 no waste: purpose first, then return values, then the auth prerequisite. Every sentence carries information an agent needs.
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 takes on the burden of describing return values and the READY-only URL. The auth requirement is stated. Only polling behavior and terminal-state handling are left unaddressed for what is otherwise a simple one-parameter read.
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 documented as "The id generate_video returned." The description reinforces the ownership constraint ("the API key that owns it") but adds no format or validation detail beyond the schema, 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?
The description opens with a specific verb and resource: "Read the state of one video you started." The singular "one video" implicitly separates it from the sibling list_videos and the id linkage separates it from generate_video, but neither sibling is named explicitly.
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?
"One video you started" and the schema note that video_id comes from generate_video imply this is a post-generation polling call. There is no explicit statement of when to use this versus list_videos, nor any guidance on polling frequency or when to stop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the videos belonging to the calling API key, newest first. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many videos to return. | |
| status | No | Keep only videos in this state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts: results are scoped to the calling API key (no cross-key visibility), returned newest first, and an API key is required. It omits what happens at the limit boundary and whether any total count is returned.
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 short sentences with zero filler, and the most important facts (scope and ordering) are front-loaded before the auth prerequisite. Nothing is repeated from the title or schema.
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 read-only listing tool with fully described parameters and safety annotations, the description covers scope, ordering, and auth adequately. The remaining gap is that with no output schema, an agent learns nothing about the shape of returned video objects or pagination beyond the limit parameter.
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%, with both limit and status fully documented including enum values and bounds, so the schema does the heavy lifting and baseline 3 applies. The description adds no extra semantics for the filters — it does not say, for example, how status filtering interacts with the newest-first ordering.
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 ("List the videos") plus the scope ("belonging to the calling API key") and default ordering ("newest first"). It does not explicitly contrast with the siblings generate_video or get_video_status, though those are distinct enough operations that confusion is unlikely.
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 name and verb — an agent can infer this is the enumeration tool versus generate_video (create) and get_video_status (single-item status). There is no explicit when-to-use/when-not-to-use statement or guidance on choosing between listing and polling status.
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.
generate_videoget_video_statuslist_videosGenerate images and videos with frontier AI models. Pay per use; credits never expire.
Restore old video and turn images into clips with sound. Pay from a capped balance, by card or USDC.
Text, image and reference-to-video across many AI video models. Musevate account required.
Create videos with prompts, and use Rendley’s video editor to adjust anything you need.
Add one secure layer between your agents and this server.
