Let your own AI make videos in your AIVideo.day account. It can price a video, start a 2D video or a 3D film from a written brief, and read back the finished MP4's address. It spends your credits only up to the limit it names and the daily limit you set, and it cannot buy credits, change your plan, or delete or publish anything. Sign in with OAuth, or use a token. Part of the Pro and Business plans. Guide: https://aivideo.day/mcp/
Scored across 4 tools
Each tool maps to a distinct action on the video resource: price (quote_video), create (make_video), poll one (get_video), enumerate all (list_my_videos). The descriptions explicitly cross-reference each other (quote before make, get_video after make), leaving no realistic chance of misselection.
All four names follow a uniform snake_case verb_noun pattern (get_, list_, make_, quote_). 'make_video' deviates from 'create_video' in verb choice but the convention itself is perfectly consistent and readable.
Four tools is a tight, well-scoped surface for a video generation pipeline where each tool clearly earns its place. It sits at the low end of comfortable, with no room for ancillary operations like cancel or delete.
The core loop is fully covered: quote cost/balance, create a job, poll status, and list history. Gaps are minor but real — there is no cancel or delete for a credit-spending job, and no way to retry a failed render, though agents can work around these by simply starting a new video.
Returns where one of the user's videos stands (writing, needs_browser, rendering, ready or failed), its render_url until the file exists, and video_url when the MP4 is ready. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | The video_id from make_video or list_my_videos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavioral context by listing the full status set and explaining that render_url is present only until the file exists while video_url appears once the MP4 is ready. The 'Free' note also discloses that calls consume no credit, which matters for a polling tool. Minor gaps remain (no rate limits, no behavior on an invalid or expired video_id).
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?
One dense sentence, front-loaded with the return contract and status values, ending with the cost note. Every clause conveys information an agent needs; nothing is padding.
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?
There is no output schema, so the description carries the burden of describing return values, and it does so well by naming the statuses and both URL fields with their conditions. It falls slightly short on edge behavior — what a failed status implies, whether statuses are terminal, and what an unknown video_id returns.
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 the single video_id parameter is already documented in the schema, including its provenance. The description adds only the implicit ownership constraint ('one of the user's videos'), which is useful but marginal; baseline 3 is appropriate when the schema carries the parameter documentation.
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 ('Returns where one of the user's videos stands') and enumerates the exact status values plus the URL fields returned. An agent can immediately tell this is a single-video status check, distinct from the sibling list_my_videos (bulk listing) and make_video (creation).
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: the schema note that video_id comes 'from make_video or list_my_videos' suggests this is the polling step after creation, and 'Free' signals it is cheap to call repeatedly. However, the description never explicitly says when to use this versus list_my_videos or quote_video, and gives no guidance on polling cadence or terminal states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the user's latest videos, newest first: id, title, when it last changed, and the MP4's address once it has one. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many, up to 20. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: sorted newest-first and an enumerated set of returned fields (notably the MP4 address appearing only once it exists), which matters because there is no output schema. It says nothing about maximum result count or absence of a pagination cursor.
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?
A single front-loaded sentence: the action, the ordering, and the returned fields come before the cost note. Nothing is redundant with the annotations 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 one-parameter list tool with no output schema, the description covers the important return-shape questions (fields, ordering, conditional MP4 address) and cost. The only gap is result-set behavior such as truncation or how to page beyond the limit, which the schema does not cover either.
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 the single limit parameter already documents its range (1–20) and default (10). The description adds no meaning beyond the schema, so the baseline of 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 names a specific verb and resource ("Lists the user's latest videos") and adds scope details: newest-first ordering and the returned fields. It does not explicitly contrast with the sibling tools, but the plural/list framing makes it distinguishable from get_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?
Usage is only implied: the agent can infer this is the discovery call for a user's videos, and "Free" hints it is a cheap first step before get_video or make_video. No explicit when-to-use, when-not-to-use, or named alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a video in the user's AIVideo.day account from a written brief: script, voices, pictures or 3D characters. Spends the user's credits, at most max_credits, so get the price from quote_video and the user's agreement first. Returns video_id and render_url. The server writes the video; the MP4 file is made when render_url is opened in a browser. Read the result with get_video.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | "2d" is an animated or narrated video; "3d" is a film with 3D characters. | |
| brief | Yes | What the video is about, in the user's words and language. | |
| title | No | Optional project name. | |
| format | No | Shape: 9:16 vertical (default), 16:9 wide, 1:1 square, 4:5 portrait. | |
| seconds | Yes | Length in seconds. 2D: 60-3600. 3D: 10-3600. | |
| max_credits | Yes | The most this call may spend. A video that costs more is refused and nothing is charged. | |
| request_key | No | Optional key for this request. Sent again, it returns the same video instead of making and charging for another. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark this as a non-read-only, non-destructive, non-idempotent call; the description goes well beyond that by disclosing credit spend, hard capping via max_credits, the refuse-and-don't-charge failure mode, and the return payload. It also explains the unusual async behavior: the server writes the video but the MP4 only materializes when render_url is opened in a browser. Minor nuance: idempotentHint=false yet request_key yields deduplication — the description clarifies this is conditional rather than contradicting the annotation.
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?
Four dense sentences with zero filler, front-loaded with the action and the cost warning before the mechanics and the follow-up. The browser-render quirk is placed after the primary description rather than burying the lede.
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 credit-spending mutation with 7 parameters and no output schema, the description covers what is produced (video_id, render_url), how to retrieve the finished artifact, and how to read state afterward with get_video. Nothing an agent needs to call this safely and correctly 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 description coverage is 100%, so every parameter including the kind enum, seconds ranges, and request_key dedupe is already documented in the schema. The description adds only marginal framing around max_credits (price first, agreement first) and repeats the video_id/render_url outputs. Baseline 3 is appropriate 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 ("Starts a video in the user's AIVideo.day account from a written brief") and immediately scopes the input domain (script, voices, pictures, 3D characters). It is clearly distinguishable from the siblings quote_video and get_video, which it names.
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 an explicit prerequisite chain: get the price from quote_video and the user's agreement first, because the call spends credits. It also names the follow-up tool ("Read the result with get_video"), so an agent knows both the gate before and the step after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the credits a video of this kind and length costs and the account's balance. Free, and nothing starts. Needs a Pro or Business plan. A 3D film is priced per started minute, so the answer's seconds is the longest it may run for that price (15 s asked = up to 60 s).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | "2d" is an animated or narrated video; "3d" is a film with 3D characters. | |
| seconds | Yes | Length in seconds. 2D: 60-3600. 3D: 10-3600. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/destructive annotations by disclosing that the call is free, that nothing is launched, and that a Pro or Business plan is required — the kind of auth/cost context annotations cannot convey. It also explains the 3D pricing rule and what the returned seconds value means, which materially affects how the result is interpreted.
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?
Four tight sentences, each carrying a distinct fact: what it returns, that it's free/no-op, the plan gate, and the 3D rounding rule. The phrasing 'the answer's seconds is the longest it may run for' is slightly awkward but still unambiguous.
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 properly names what comes back (credit cost plus account balance) and explains the semantics of the seconds value. It stops short of naming the response fields or format, which is the only remaining gap for a two-parameter pricing tool.
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 real meaning the schema lacks: 3D is billed per started minute, so the returned seconds is the maximum runtime covered by the quoted price (15 s asked = up to 60 s). The 2D vs 3D distinction for pricing is clarified beyond the enum text.
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 ('returns the credits a video of this kind and length costs and the account's balance') and immediately separates itself from make_video with 'Free, and nothing starts' — the agent knows this prices, it doesn't render.
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 preconditions ('Needs a Pro or Business plan') and a strong no-side-effect guarantee ('Free, and nothing starts'), which tells the agent this is a safe pre-flight call. It never explicitly says 'call this before make_video', so the sequencing guidance is implied rather than stated.
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.
get_videolist_my_videosmake_videoquote_video
Add one secure layer between your agents and this server.